Stromverbrauch für Tag, Woche, Monat, Jahr berechnen

[Tobi_Koelle]

90€ und Cloud sprechen klar dagegen, allerdings läuft das Gerät mit Batterien vs. netzbetrieb bei dem Hichi was ein kleine Herausforderung darstellen würde. Aber ich gucke mal, wenn ihr sagt, dass das kein großes Gefrickel ist, versuche ich es vielleicht mal

[PeterA]

Hab mir ein kleines 5V Hutschienennetzteil in die Verteilung gesetzt.
Damit wird der Lesekopf versorgt.

[Tobi_Koelle]

Hab mir ein kleines 5V Hutschienennetzteil in die Verteilung gesetzt.
Damit wird der Lesekopf versorgt.

und mit dem WLAN-Empfang hast Du keine Probleme?

[PeterA]

Keine Probleme weil in der Nähe ein Repeater sitzt.

[EMaster]

Also, es liegt definitiv an der InfluxDB.
Ich habe es mal zum Testen auf rrd4j umgestellt und sofort werden die Werte berechnet.
Aber an was könnte es bei der Persistence mit InfluxDb scheitern? So viele Parameter kann man da ja nicht wirklich einstellen und das Schreiben funktioniert ja, da der Verbrauch ja da auch ankommt.

Nachtrag: Habe gerade gesehen, dass das InfluxDB-Binding noch die Version 3.2.15 aus der SmartHome/J trug. Habe auf die offizielle 3.41 upgedatet und es funktioniert!!! Das war sicher auch der Grund, dass die anderen Rules auch nie funktioniert haben.
Danke für Deine/Eure Unterstützung und Geduld!!!

Servus Zusammen,

seitdem ich gestern auf OH 4.0.1 upgedatet habe, funktioniert mein Skript nicht mehr.

Code: Alles auswählen

rule "Stromverbrauch Tag Woche Monat Jahr"                                                              // Deutscher Zeichensatz zulässig
when
    Item SM_DG_ges_Verbrauch changed                                                         // changed reicht.
then
    logInfo("countUpdate","Rule gestartet.")
    val ZonedDateTime zdt            = ZonedDateTime.now()                                              // jetzt
    val ZonedDateTime start_of_day   = zdt.with(LocalTime.MIDNIGHT)                                     // heute, Mitternacht
    val ZonedDateTime start_of_week  = start_of_day.minusDays(start_of_day.getDayOfWeek.getValue - 1)   // Montag 
    val ZonedDateTime start_of_month = start_of_day.withDayOfMonth(1)                                   // Erster Tag des Monats (1)
    val ZonedDateTime start_of_year  = start_of_day.withDayOfYear(1)                                    // Erster Tag des Jahres (1)
    logInfo("countUpdate","Daten definiert ")
    var Stromverbrauch_Heute = -1.0
    var Stromverbrauch_Woche = -1.0
    var Stromverbrauch_Monat = -1.0
    var Stromverbrauch_Jahr  = -1.0
    logInfo("countUpdate","Daten definiert jetzt {} heute {} woche {} monat {} jahr {}",zdt,start_of_day,start_of_week,start_of_month,start_of_year) // Nur für Logging aktivieren!
    if(SM_DG_ges_Verbrauch.deltaSince(start_of_day,"influxdb")  instanceof Number)
        Stromverbrauch_Heute = (SM_DG_ges_Verbrauch.deltaSince(start_of_day,"influxdb")   as Number).floatValue
    if(SM_DG_ges_Verbrauch.deltaSince(start_of_week,"influxdb") instanceof Number)
        Stromverbrauch_Woche = (SM_DG_ges_Verbrauch.deltaSince(start_of_week,"influxdb")  as Number).floatValue
    if(SM_DG_ges_Verbrauch.deltaSince(start_of_month,"influxdb") instanceof Number)
        Stromverbrauch_Monat = (SM_DG_ges_Verbrauch.deltaSince(start_of_month,"influxdb") as Number).floatValue
    if(SM_DG_ges_Verbrauch.deltaSince(start_of_year,"influxdb") instanceof Number)
        Stromverbrauch_Jahr  = (SM_DG_ges_Verbrauch.deltaSince(start_of_year,"influxdb")  as Number).floatValue
    logInfo("countUpdate","Variablen gesetzt. heute {} woche {} monat {} jahr {}",Stromverbrauch_Heute,Stromverbrauch_Woche,Stromverbrauch_Monat,Stromverbrauch_Jahr) // Nur für Logging aktivieren!
    logInfo("countUpdate","deltaSince (day) {}",SM_DG_ges_Verbrauch.deltaSince(start_of_day,"influxdb")) // Nur für Logging aktivieren!
    logInfo("countUpdate","deltaSince (day) {}",SM_DG_ges_Verbrauch.deltaSince(now.minusHours(1),"influxdb")) // Nur für Logging aktivieren!
    SM_Tag_VerbrauchStrom.postUpdate(Stromverbrauch_Heute)
    SM_Woche_VerbrauchStrom.postUpdate(Stromverbrauch_Woche)
    SM_Monat_VerbrauchStrom.postUpdate(Stromverbrauch_Monat)
    SM_Jahr_VerbrauchStrom.postUpdate(Stromverbrauch_Jahr)
end

Im LOG habe ich diese Meldungen.

Code: Alles auswählen

2023-07-29 10:51:04.445 [WARN ] [penhab.core.library.items.NumberItem] - Failed to update item 'SM_DG_L2_Strom' because '1.91 A' could not be converted to the item unit 'V'
2023-07-29 10:51:04.450 [WARN ] [penhab.core.library.items.NumberItem] - Failed to update item 'SM_DG_L3_Strom' because '0.62 A' could not be converted to the item unit 'V'
2023-07-29 10:51:07.503 [WARN ] [penhab.core.library.items.NumberItem] - Failed to update item 'SM_DG_L2_Strom' because '1.94 A' could not be converted to the item unit 'V'
2023-07-29 10:51:07.511 [WARN ] [penhab.core.library.items.NumberItem] - Failed to update item 'SM_DG_L3_Strom' because '0.66 A' could not be converted to the item unit 'V'
2023-07-29 10:51:10.589 [WARN ] [penhab.core.library.items.NumberItem] - Failed to update item 'SM_DG_L2_Strom' because '1.88 A' could not be converted to the item unit 'V'
2023-07-29 10:51:10.593 [WARN ] [penhab.core.library.items.NumberItem] - Failed to update item 'SM_DG_L3_Strom' because '0.61 A' could not be converted to the item unit 'V'

Das Ändern der Datenbank von influxdb auf rrd4j brachte dieses Mal keinen Erfolg.

Hat jemand eine Idee?

Danke

[udo1toni]

Na ja, es steht ja da, was das Problem ist. Vielleicht nur nicht so, dass man direkt drauf kommt...

Ich hole ja gerne etwas aus, deshalb...

bisher gab es in openHAB ein grundsätzliches Problem im Zusammenhang von Units of Measurement (UoM) und der Persistence. Die Persistence speichert grundsätzlich keine UoM mit, sondern ausschließlich den Zahlenwert.
Man hätte die Funktionalität zumindest für jdbc, influxdb und mapdb leicht nachrüsten können, bei rrd4j bin ich mir da allerdings nicht so sicher, und diese Änderung wäre sehr weitreichend gewesen, mutmaßlich hätte es auf jeden Fall einen kompletten Datenverlust bedeutet (im Sinne von: alle bisher persistierten Daten gehen bei der Umstellung verloren).
Nun ist aber die Frage, was denn bei einem UoM Item als Wert gespeichert wird, und die Antwort liegt auf der Hand: Wenn, dann halt der im Item enthaltene Zahlenwert.
Das Problem dabei: Bis einschließlich openHAB3.4.5 speichert ein UoM Item den Zahlenwert so, wie es den Wert anzeigt. Wenn ich nun in der Itemdefinition die anzuzeigende Einheit anpasse, werden die Werte plötzlich in einer anderen Einheit gespeichert, z.B. ändere ich von A nach mA, zack, sind die Werte um den Faktor 1000 größer. Und diese Werte werden dann einfach in die Persistence geschrieben... und ich wundere mich, dass meine Charts plötzlich einen Knick haben.

In openHAB4 hat man dieses Problem auf möglichst kompatible Art gelöst, und zwar, indem man den UoM Items eine zusätzliche Eigenschaft unit verpasst hat. Nun ist die Anzeige unabhängig vom enthaltenen Zahlenwert. Das Item kann z.B. in die Persistence die Temperatur als K schreiben, angezeigt wird aber °C (und vielleicht liefert der Sensor gar °F an - ist aber egal, die Anzeige ist immer korrekt).

Der "Pferdefuß" bei der Sache: Zum Umstellungszeitpunkt haben die Items die Eigenschaft noch nicht gesetzt. Deshalb muss ein Konvertierungsscript bei allen UoM Items die unit ergänzen.

Offensichtlich ist bei Deinen Items ein grober Schnitzer passiert, denn die Fehlermeldung

Code: Alles auswählen

Failed to update item 'SM_DG_L2_Strom' because '1.91 A' could not be converted to the item unit 'V'

besagt, dass das UoM Item SM_DG_L2_Strom die Einheit V trägt, aber versucht wird, eine davon unabhängige Unit A zu schreiben.
Entweder, weil es vom Typ Number:Electric Potential ist (statt korrekt Number:Electric Current), oder weil wegen eines Fehlers bei der Konvertierung in unit ein V gelandet ist, statt des dorthin gehörenden A.
Zum Glück sollte es aber kein Problem sein, die unit zu korrigieren - wichtig ist aber auch, dass der Typ korrekt auf Number:Electric Current steht.

[EMaster]

Danke, das war die Lösung. Das mir das nicht schon früher aufgefallen ist.

[starbright]

Möchte mir gern den Tagesverbrauch (Stromzähler) errechnen lassen und dann das als Diagramm (flexible Zeit, z.B. 1 Woche) anzeigen um den Trend zu sehen. Bin nach fast einem Jahr Wiedereinsteiger auf niedrigem Level, hab bisher noch nichts komplexes gemacht mit openHAB. Deswegen die Frage: Gehe ich in die richtige Richtung?
* Mein Strommesser liefert den aktuellen Stand mit "sm_count_purchase"
* Ein neues Item erstellen sm_purchase_day
* Dessen Wert wird mit einem Script (oder Rule ?) errechnet (Wert von Jetzt - Start of day).
* Damit würde dann ja eine neue Datenbank rrd4j gefüllt, die aber sinnvollerweise nur einen Eintrag/Tag hat (geht das, wie?)
* Und dies dann als Diagramm anzeigen lassen.
Würde das funktionieren? (Läuft noch mit OH3).

[PeterA]

Hi,

im Grunde kannst Du so vorgehen.
Wichtig ist das Du zunächst das Item "sm_count_purchase" persistierst.
Dann kannst Du damit den ganzen Schabernack treiben
Als DB eignet sich hierzu natürlich rrd4j und darin wird dann bei jeder Änderung des Items gespeichert.
Dann kannst Du mit einer entsprechenden Abfrage das "sm_purchase_day" Item befüllen und dieses wiederum in der Datenbank persistieren
und damit einen Chart zeichnen lassen.
So sieht bei mir (noch unter OH 2.4) die Abfrage für den Tageswert aus:

Code: Alles auswählen

hitchi_in_heute.postUpdate(hitchi_in.deltaSince(now.withTimeAtStartOfDay) as Number )

Für Dein Item dann entsprechend so:

Code: Alles auswählen

sm_purchase_day.postUpdate(sm_count_purchase.deltaSince(now.withTimeAtStartOfDay) as Number )

Gruß Peter

[udo1toni]

Allerdings, gerade bei dem Tageswert und rrd4j - ist noch zu bedenken, dass rrd4j zwingend eine Strategy everyMinute benötigt, sonst funktioniert rrd4j nicht. Grund hierfür ist die interne Funktionsweise von rrd4j, welches in mehreren Stufen jeweils Mittelwerte aus der nächsthöheren Stufe bildet. Das geht natürlich nur, wenn diese Werte auch zur Verfügung stehen.

Grundsätzlich braucht man gar keine eigenen Items für Tageswerte, die kann man ja bequem über die Persistence abrufen, vorausgesetzt, die Persistence speichert einen streng monoton wachsenden Zählerstand.