Hast Du die Items entsprechend angelegt? WIE hast Du die Rule übernommen? Es gibt verschiedene Wege dafür, und das hat entscheidenden Einfluss darauf, ob die Rule unverändert oder angepasst übernommen werden muss.
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet
udo1toni hat geschrieben: ↑20. Okt 2021 23:41
Und das Quellitem Shelly3DDrucker_Verbrauchaktuell ist in der default Persistence drin?
Also ich habe keine spezielle .persist-Datei, was soviel heißt dass ich mit den Default-Einstellungen fahre. Ist mir bisher nicht abgegangen.
Sollte das das Problem sein: Was genau müsste ich wo eintragen?
Hab' den Fehler jetzt mal eingekesselt - bin aber nun auf eine Grundsätzliche Frage gestoßen:
Wenn ich die Watt-Anzahl eines Verbrauchers nur zu bestimmten Zeitpunkten ablese (z.B. unser Fernseher, der je nach Bild (hell/dunkel) mehr oder weniger Strom braucht [zwischen 80 und 200W]), dann muss die Messung ja ziemlich ungenau sein, wenn ich alle 15 Minuten nur die aktuellen Watt zur Berechnung des Gesamtstromverbrauches heranziehe.
Oder muss ich das Item "everySecond" persistieren, damit das einigermaßen passt? Und wäre sumsince nicht die bessere Wahl statt deltasince?
Boby hat geschrieben: ↑1. Nov 2021 23:09
Hab' den Fehler jetzt mal eingekesselt - bin aber nun auf eine Grundsätzliche Frage gestoßen:
Wenn ich die Watt-Anzahl eines Verbrauchers nur zu bestimmten Zeitpunkten ablese (z.B. unser Fernseher, der je nach Bild (hell/dunkel) mehr oder weniger Strom braucht [zwischen 80 und 200W]), dann muss die Messung ja ziemlich ungenau sein, wenn ich alle 15 Minuten nur die aktuellen Watt zur Berechnung des Gesamtstromverbrauches heranziehe.
Oder muss ich das Item "everySecond" persistieren, damit das einigermaßen passt? Und wäre sumsince nicht die bessere Wahl statt deltasince?
Danke!
Es wird nicht alle 15 Minuten die Watt für die Berechnung genommen, sondern das delta der kwh. Das heißt die Veränderung der letzten 15 Minuten wird ermittelt. Man kann die Zeit noch weiter verkürzen, aber wozu? Eine geringere Zeitspanne bedeutet mehr Zeit für Berechnungen, und das ganze um statt 0,02 kwh dann 0,0003 kwh zu ermitteln, halte ich für Übertrieben.
Ein "everyChange" bei der Persistenz reicht doch vollkommen zu, man braucht doch nur die Veränderung zu speichern. Ich hab am Anfang auch mit everUpdate gearbeitet, das braucht aber unheimlich CPU Zeit und der Zugriff auf deinen Speicher ist auch weit mehr. Du kannst ja mal spaßeshalber den logger für die Persistenzen einschalten und mal schauen wann er was schreibt, wenn du everySecond einstellt wirst du feststellen das deine CPU Auslastung ansteigen sowie dein Fesplattenzugriff ansteigen wird. Und das ganze wofür? Nur um den Wert 1000 mal statt nur einmal zu schreiben, jetzt stell dir vor das ganze passiert dann für 100 oder 1000 Items wie das sich summiert.
Jetzt aber noch eine Frage: Die Shellys haben ja die ungute Eigenschaft, dass sie nach einem FW-Update die kWh‘s verlieren und auf Null zurückgehen, wenn man MQTT verwendet.
Das „deltasince“ wäre dann -75 und würde mir meine Statistik wieder zusammenhauen, oder? Sprich: Ich müsste noch ein IF einbauen, ob das Delta negativ ist - und es nur im positiven Fall berücksichtigen…oder habe ich da wieder was falsch verstanden?
Richtig. Im Grunde ist das ganze eben dadurch geboren. Verstehe auch nicht warum die die Werte verlieren. Rein technisch ergibt das keinen Sinn. Ich bin bis jetzt noch zu faul gewesen diesen Fall des Reboots zu mathematisch zu ermitteln. Man kann bestimmt sich eine Formel zusammenbauen die auch da greift und auch da ein delta rausziehen. Aber eigentlich ist im Fall des Reboots der neue Wert 0, richtig ist, das Delta nach 15 Minuten wäre in dem Fall ein Minuswert. Man müsste jetzt quasi den Fall abgreifen wenn der neue Wert 0 ist und bis dahin das delta ermitteln, danach kann man dann ja wieder von 0 ausgehen. Aber wie gesagt, da hab ich noch keine Muse gehabt.