[vz-users] Frage zum Betriebsstundensensor

Di Apr 7 08:40:07 CEST 2020

Hi,

zum testen hätte ich ein script. Läuft auf meinen VZ. Gpio der gesteuert wird ist mit einer Brücke zum VZ-Eingang verbunden. Ist meine Überwachung für VZ.

Ieinen Zufallsgenerator für sich ändernden Daten müsste noch eingebaut werden.

Mit freundlichen Grüßen,

Thomas 

-----Ursprüngliche Nachricht-----
Von: Andreas Goetz <cpuidle at gmail.com>
Gesendet: Dienstag 7 April 2020 08:32
An: volkszaehler.org - users <volkszaehler-users at demo.volkszaehler.org>
Betreff: Re: [vz-users] Frage zum Betriebsstundensensor

Moin Frank!

Deine Lösungszeiten mitten in der Nach sind atemberaubend… Ich habe mit gearbeitet: https://github.com/volkszaehler/volkszaehler.org/pull/801

Test wäre gut- ich habe das Gefühl da fehlt irgendwo noch ein Faktor?

Viele Grüße, Andreas

On 6. Apr 2020, at 23:26, Frank Richter <frank.richter83 at gmail.com> wrote:

Hi zusammen,

ich glaub ich hab's gefunden:

$this->consumption += $tuple[1] * $delta_ts; (https://github.com/volkszaehler/volkszaehler.org/blob/master/lib/Interpreter/SensorInterpreter.php#L49) multipliziert immer mit dem Timestamp-Delta, auch wenn convertRawTuple im Consumption-Mode schon Energie (bzw. ein anderes Zeitintegral) zurückgibt (https://github.com/volkszaehler/volkszaehler.org/blob/master/lib/Interpreter/SensorInterpreter.php#L74-L75).

Also bräuchten wir entweder in generateData nochmal eine Fallunterscheidung oder wir schieben die Zeilen für die Verbrauchswerte gleich dorthin. Variante 2) fände ich klarer.

PR? Testen kann ich das allerdings nicht ohne weiteres, da keine passenden Daten.

Viele Grüße
Frank

Am Mo., 6. Apr. 2020 um 17:46 Uhr schrieb Andreas Goetz <cpuidle at gmail.com>:
Hi Alex,

kann gut sein, dass die MW das falsch macht. Da hilft nur die Analyse im Detail zu machen und den Fehler zu finden….
Mein Fokus liegt aktuell auf anderen Dingen, wenn Du Fragen zum debuggen hast kann ich gerne Tips geben.

Viele Grüße, 
Andreas

On 6. Apr 2020, at 14:00, rgb at nord-com.net wrote:

Hallo Andreas,
 Ich habe da noch mal reingeschaut. Die min, max und current Werte des Betriebsstundensensors scheinen in allen Modi (current, hourly, daily, monthly, yearly) zu stimmen, bestenfalls gibt es da ein paar Rundungsdifferenzen.
 Was in keinem Fall (ausser im current) stimmt, sind die Durchschnitts- und Verbrauchswerte. Diese werden aber bereits falsch von der Middleware geliefert, so dass ich nicht von einem Fehler im Frontend ausgehe…
 So gibt z.B. uuid.json?options=consumption&from=1577833200000&to=now&tuples=1&group=year 
die richtigen Werte für current, min und max (die 777 entsprechen in etwa dem was ich auch aus der Datenbank lesen kann (773)). Der Verbrauch müsste in allen Modi mit diesem Wert identisch sein.
 Wenn Du da einen Tipp für mich hättest, versuche ich gerne dem Problem auf die Spur zu kommen.
 Viele Grüsse,
Alex
 From: volkszaehler-users [mailto:volkszaehler-users-bounces at demo.volkszaehler.org] On Behalf Of Andreas Goetz
Sent: Friday, April 03, 2020 6:35 PM
To: volkszaehler.org - users
Subject: Re: [vz-users] Frage zum Betriebsstundensensor
 …ich hab grad zuviele andere Themen. Irgendwo in der wui.js oder plot.js fehlt eine Fallunterscheidung für den Modus bevor ausmultipliziert wird. Die Suche ist mühsam, sollte sich aber finden lassen.
 Hilfe wäre willkommen!
 Viele Grüße, Andreas

On 3. Apr 2020, at 18:15, <rgb at nord-com.net <mailto:rgb at nord-com.net> > <rgb at nord-com.net> wrote:
 Hallo Andreas,
 Ja, das könnte hinkommen… werde mich da mal einklinken. Ist ja auch nichts, was eine sofortige Lösung braucht… ich habe es nur nicht verstanden und schon an meinem Setup gezweifelt.
 Viele Grüße,
Alex
 From: volkszaehler-users [mailto:volkszaehler-users-bounces at demo.volkszaehler.org <mailto:volkszaehler-users-bounces at demo.volkszaehler.org> ] On Behalf Of Andreas Goetz
Sent: Thursday, April 02, 2020 8:08 PM
To: volkszaehler.org - users
Subject: Re: [vz-users] Frage zum Betriebsstundensensor
 Sieht aus wie https://github.com/volkszaehler/volkszaehler.org/issues/772?
 Hatte noch niemand Muße den Fehler zu suchen �
 Viele Grüße, Andreas 

Am 02.04.2020 um 18:43 schrieb rgb at nord-com.net:

Hallo liebe Volkszähler-Nutzer und -Experten,
 habe da gerade ein Fragezeichen auf der Stirn…
 Ich nutze (u.a.) zwei Betriebsstundensensoren, einen für die tägliche Laufzeit meiner Heizung und einer für die kumulierte Brennerlaufzeit. Meine Heizung liefert z.B. alle paar Sekunden eine 1, wenn sie im Heizbetrieb ist, eine 0 wenn in der Abschaltung, das schreibe ich 1:1 via Middleware-Aufruf in den VZ. Selbiges gilt für die Brennerlaufzeit.
 Ich bekomme damit eine schöne graphische Anzeige (states) sowie exakte Zahlen. Für meine Tabelle importiere ich den täglichen type=3 Aggregate-Wert, der noch mal 24 gerechnet werden muss, dann stimmt es exakt mit der Anzeige im Frontend (und den Tatsachen) zusammen.
 Wenn ich nun im Frontend die Heizzeit für’s Jahr ansehe, im Current-Modus, stimmt das in etwa mit dem überein, was ich auch aus der DB rauskitzeln kann, das sind vom 1.1.2020 bis jetzt z.B. 765 Stunden in der Spalte „Verbrauch“.
 Gehe ich vom „current“ in den „hourly“ mode, sind es plötzlich 903 Stunden, unter „monthly“ 541393h, unter „yearly“  1681297h. 
 Was genau berechnet der VZ denn da? Der Verbrauch sollte doch immer gleich bleiben...? Bei meinen Impulskanälen (Gas-S0 und Brennerstarts) ist das ja auch so… der Gesamtverbrauch bleibt unabhhängig ob Current oder Daily-Yearly beim gemessenen Maximum.
 Gerne kann ich Bilder posten oder einen Link zum Frontend, aber ich denke Ihr glaubt mir auch so… bitte um Eure Ideen wie das zustande kommen kann.
 Danke & Gruss,
Alex
 <workinghourssensor.png>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20200407/f16d2e9f/attachment-0001.html>
-------------- nächster Teil --------------
Ein eingebundener Text mit undefiniertem Zeichensatz wurde abgetrennt.
Name: gpio_puls.py
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20200407/f16d2e9f/attachment-0001.ksh>