[vz-users] Frage zu virtuellen Kanälen
Andreas Goetz
cpuidle at gmail.com
Fr Dez 20 11:27:05 CET 2019
Hi,
> On 20. Dec 2019, at 10:55, <rgb at nord-com.net> <rgb at nord-com.net> wrote:
>
> Hallo Thomas und Andreas,
>
> Ich habe mal versucht, auf Eure beiden Emails zusammen zu antworten… ich hoffe es wird nicht zu verwirrend.
Vorweg: Dein Quoting ist kaputt was es ziemlich schwierig macht der Maildiskussion zu folgen.
> Die virtuellen Kanäle haben ein paar Einschränkungen. Ganz vorne weg: sie funktionieren immer mit der Auflösung in der die Daten jeweils abgerufen werden. Das Ergebnis kann daher nach Zoomstufe im Frontend (oder api) variieren.
>
> Wenn ich es richtig verstehe, müsste der virtuelle Kanal doch die Eingaben für die Berechnung erhalten, die vom Frontend in der entsprechenden Auswahl und Zoomstufe des Eingabekanals auch angezeigt werden?
Genau.
> Das mit dem *60 ist verwirrend. Evtl. funktioniert hier links vor rechts nicht- das wäre ein Bug. Könntest Du mit Klammern testen.
>
> Das funktioniert soweit, dann bekomme ich eine Ausgabe.
>
> Was fehlt Dir denn? Soweit in Deinem Chart zu sehen (es würde helfen alle irrelevanten Kanäle auszublenden) funktioniert die Rechnung prinzipiell: Dein Ergebniskanal schwankt abhängig von den Brennerstarts. Evtl. hast Du noch die beiden Eingänge in1/in2 vertauscht.
>
> Nein, ist nicht vertauscht. Ja, der Ergebniskanal schwankt abhängig von den Brennerstarts, die Kurve zeigt zusätzlich zu der von Brenner ein/aus in der Breite fast identische Fast-Rechtecke, deren Höhe von den Laufzeit abzuhängen scheint.
>
> Was für Ergebnisse (Beispiele) erwartest du? Wie soll die Kurve dazu Aussehen?
>
> Optimal wäre eine Linie, je nach durchschnittlicher Brennerlaufzeit (sagen wir mal 4-5 Minuten im angezeigten Zeitraum) entsprechend schwankt, oder als Steps, so wie die Anzahl der Brennerstarts.
4-5 Minuten geht halt nicht. Es wird immer der nächste Wert verarbeitet falls in der Abfrage an die Middleware nicht irgendwo ein &group=hour oder ähnliches drin steht. Das ist prinzipbedingt und nicht änderbar.
Wenn Du da mehr Flexibilität brauchst Daten mit dbcopy nach InfluxDB exportieren und dort mit Grafana, InfluxQL oder Flux rumspielen. An der Stelle wird es bei VZ auch keine Weiterentwicklungen mehr geben.
> Wichtig wäre mir aber weniger der Graph, sondern dass die Zahlen stimmen, und da komme ich immer noch nicht dahinter…
Ggf. fehlt da eine Faktor von 3,6 um von Sekunden auf Stunden zu kommen.
> Das könnte der Denkfehler sein. VZ addiert nicht auf, das Frontend interpretiert die Daten im Zeitraum from= to=.
VZ addiert sehr wohl- nicht sicher was hier gemeint ist.
> Für deinen Betriebsstundensensor sind das Summe-N*f(Faktor), für die Brennerstarts nur Summe-N. In deiner Grafik siehst du max=1 für beide Sensoren. Ein weiteres Problem könnte die Einheit von Brennerstarts sein.
>
> Im angehängten Beispiel sieht man 4 mal Brenner ein/aus, gesamte Laufzeit 0,283, geteilt durch 4 Starts, mal 60 sind 4,245 Minuten durchschnittliche Laufzeit. So ermittle ich das momentan mit dem Taschenrechner, was ja korrekte Ergebnisse liefert.
Im Zweifel Rohwerte aus dem API holen und Rechnung mit den Werten in Excel aufmachen.
>
> Ich stehe da irgendwo auf dem Schlauch…
> Viele Grüsse, Alex
Viele Grüße, Andreas
>
>
>
>
> <testkanal-settings.png><testkanal-3.png>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20191220/a4b7eeaf/attachment.html>
More information about the volkszaehler-users
mailing list