Userreading Trigger und Event-on-Change-Reading (oder Verzögerung?)

Begonnen von didy, 28 August 2022, 22:36:55

Vorheriges Thema - Nächstes Thema

didy

Hallo zusammen,

ich habe vom PV-Wechselrichter per Modbus die erzeugte Leistung, Netzbezug und Netzeinspeisung und möchte mit einem Userreading berechnen, wieviel das Haus derzeit verbraucht (P_Wechselrichter + P_Bezug - P_Einspeisung). Da sich aber quasi immer mindestens zwei Werte zusammen ändern, wird das Userreading dann immer zweimal berechnet, hat zwischendurch einen "falschen" Wert, was in Diagrammen blöd ist.

Die vorgesehene Lösung wäre wohl das Triggern auf nur einen der Werte (der, der als letztes kommt).
ABER:
Um nicht unnötiges zu loggen, habe ich auf alle drei "Quellwerte" ein Event-on-change-Reading. Es ist schließlich ziemlich sinnlos, Nachts ständig Einspeisung 0 zu loggen.
Damit geht das nicht mehr, denn wenn sich der Wert auf den ich triggere nicht ändert, aber einer der anderen beiden, bekomm ich kein Event und berechne das Userreading nicht neu.

Wie löst man das am elegantesten? Folgende Optionen fallen mir ein:

Variante 1: Daten zweimal auslesen
Ich lege zwei ModbusAttr-Devices in FHEM an, lese die Daten doppelt vom Wechselrichter. Bei Instanz A bekommen die Leistungen ein Event-on-change-Reading und werden geloggt. Bei Instanz B haben diese Leistungen *kein* Event-on-change-Reading, daraus berechne ich den Verbrauch als Userreading.
Gefällt mir nicht, unsauber, und auch keine Ahnung wie sehr der Wechselrichter das mag wenn man Dinge doppelt abfragt.

Variante 2: Reading per Userreading dupliizieren
Ich mache für das Reading, was als letztes kommt, ein Userreading, wo nochmal das selbe drinsteht, dupliziere quasi das Reading. Nur dieses duplizierte Userreading bekommt das Event-on-change-Reading und nur das wird geloggt. Das P_Verbrauch Userreading wird mit dem "Originalreading" getriggert.
Nachteil, man kann kein Event-on-change-reading .* machen sondern muss alle readings separat behandeln - Fehleranfällig.
Trotzdem vermutlich die beste Lösung?

Variante 2a: Ähnlich Variante 2, nur mit einem zusätzlichen Dummy-Device, sodass alle Werte die man loggen will in ein Dummy dupliziert werden, und man dort für das log wieder mit .* arbeiten kann.

Variante 3: Verzögertes berechnen
Was mir am besten gefallen würde, wäre, wenn ich das Userreading erst z.B. 3 Sekunden nach dem Event berechnen könnte. Bis dahin sind alle Werte stabil. Ich rechne es dann zwar auch immer (bis zu) 3 mal, aber es kommt 3 mal das selbe raus (und mit Event-on-change-Reading gibt es damit nur ein Event).
Hier https://forum.fhem.de/index.php?topic=100558.0 hat schon mal jemand das gefragt, dort hieß es das geht nicht.
Das Userreading ist ja perl code. Perl sleep darf man nicht nehmen das ist klar. Innerhalb vom perl code ein fhem-sleep aufzurufen (ohne "weitere" fhem-Befehle) geht auch nicht oder?


Hab ich eine Möglichkeit übersehen?


Grüße,
Didi

didy

Ich glaub der entscheidende Geistesblitz kam mir gerade selbst noch.

Variante 2 etwas modifiziert.

P_Einspeise (was das letzte ist) umbenannt zu Z_P_Einspeise. Ein Userreading P_Einspeise was dessen inhalt dupliziert.
Wenn man sonst keine Readings mit Z hat, kann man mit [A-Y].* arbeiten.

Event-on-change-Reading für [A-Y].*
Event-on-update-Reading für [Z_].*
Trigger für P_Verbrauch auf P_Einspeise
Loggen ebenfalls [A-Y].*

Erster Eindruck ist, dass das geht.
Sollte jemand noch andere Vorschläge haben, trotzdem gerne her damit.

DS_Starter

Ich würde einfach auf "state" triggern. Gehe davon aus das Device hat dieses Reading welches triggern kann.
Evtl. event-on-change-reading auf state setzen.

Außerdem event-on-change-reading auch auf das userreading setzen damit es nur einen Event bei Änderung wirft.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

didy

Der State dieses Modbus-Moduls ist leider einfach nur initialized :D Aber trotzdem Danke für die Idee.

Edit: Das Umbenennen des Readings geht deswegen, weil man bei dem Modul selbst definieren muss, welche der gefühlt unendlichen Modbus-Adressen als welches Reading verwendet wird.

DS_Starter

ZitatDer State dieses Modbus-Moduls ist leider einfach nur initialized
Ah ... ok. Naja wäre ja einfach gewesen.  ;)
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter