[vz-users] Frage zum Betriebsstundensensor

[Frank Richter]

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 <cpuidle at 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.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
>> <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> <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
>> <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/ad812f15/attachment-0001.html>