Moin Andreas, denke auch dass die Einheiten nicht passen: das consumption tuple ist schon in Wh umgerechnet, aber $this->consumption erwartet an dieser Stelle mWs.
Grüße Frank Andreas Goetz <cpui...@gmail.com> schrieb am Di., 7. Apr. 2020, 08:30: > 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.richte...@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 <cpui...@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, r...@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-boun...@demo.volkszaehler.org >> <volkszaehler-users-boun...@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, <r...@nord-com.net> <r...@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-boun...@demo.volkszaehler.org >> <volkszaehler-users-boun...@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 r...@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> >> >> >> >
