[Modulidee] readingsChange2

Begonnen von Beta-User, 11 November 2021, 15:29:48

Vorheriges Thema - Nächstes Thema

Beta-User

Hallo zusammen,
hallo Rudi,

eher zu Übungszwecken hatte ich vor einiger Zeit mal ein Fragment für ein Modulchen entworfen, das ähnlich ticken sollte wie readingsChange.
Das ist an sich ganz nett, hat aber den Nachteil, dass man für jedes nachzuarbeitende Device und Reading je eine eigene Instanz braucht, was misslich ist, wenn man viele gleich gelagerte Fälle hat und/oder Devices mit vielen Readings.
Daher die Idee, das "übergeordnet" anzugehen, also nur einen zentralen Eventhandler zu haben und dann (User-) Attribute an die Devices zu verteilen, die man "nachbearbeiten" will.

Der "Rahmen" an sich ist ist auch ziemlich fertig, aber leider ist es mir nicht gelungen, das so in die Eventverarbeitung einzuhängen, dass die "nachbehandelten" Devices auch wieder sauber aus der Event-Loop entlassen werden (=> CHANGED-Array gelöscht usw.). Vermutlich hängt es nur an irgendeiner Kleinigkeit, vielleicht ist es auch was größeres, ich bin jedenfalls bis dato noch nicht dahintergekommen, was (schon bei einfachen Änderungen) das Problem ist...

Na jedenfalls beschäftigte uns ja neulich auch dieses neue Shelly-MQTT-JSON-Format, dass die Shelly2-API so mit sich bringt mit diversen "true" und "false"-Infos innerhalb des JSON, was irgendwie zum einen nach einer generalisierten Lösung ruft und andererseits bei einer sehr pauschalen search/replace-Lösung das Risiko birgt, dass früher oder später was seltsames passiert. Wie dem auch sei:
Hier mal der betreffende Modulcode mdB. da mal drüberzuschauen, an was es ggf. hängt und eventuell einer Rückmeldung, ob sowas ein möglicher Weg sein könnte, eine generische Lösung anzubieten.

Wer testen will braucht eine zentrale Instanz:
defmod readC2 readingsChange2

Und eben mind. ein Testgerät:
defmod rC2TestDummy dummy
attr rC2TestDummy readingList abc def temperature temp
attr rC2TestDummy readingsChange2 temp [-]?(\d+\.?\d*).* $1\
temperature (-?\d+\.?\d*).* { FHEM::readingsChange2::compareAbs("$name","$reading","$1",'25','10') }
attr rC2TestDummy setList temperature:slider,-300,1,200,1 temp:slider,-30,0.5,60,1
attr rC2TestDummy webCmd temp

Solange man alles "richtig" macht und den slider für temp im positiven Bereich bewegt, gibt es Events und alles ist gut, sobald man einmal unter 0 war, wird das CHANGED-Array nicht mehr gelöscht. Nach meinem bisherigen Verständnis macht das Modul in dieser einfachen Form doch auch nichts anderes als "das Original", aber vermutlich übersehe ich mal wieder eine Kleinigkeit...

Auf diese Weise könnte man jedenfalls "state"-like Readings "nachbearbeiten" und "härter" als bei eventMap den Reading-Inhalt selbst "FHEM-konform" für die nachgelagerte weitere Eventverarbeitung vorhalten. Kann aber natürlich auch sein, dass das ganze gar keine gute Idee ist. Das würde mich dann auch interessieren :) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

Zitathat aber den Nachteil, dass man für jedes nachzuarbeitende Device und Reading je eine eigene Instanz braucht [...]
Genauer: man kann nur dann mehrere devices und readings mit einem readingsChange-Instanz behandeln, wenn die Umwandlungs-Anweisungen fuer alle identisch sind.

ZitatAuf diese Weise könnte man jedenfalls "state"-like Readings "nachbearbeiten" und "härter" als bei eventMap den Reading-Inhalt selbst "FHEM-konform" für die nachgelagerte weitere Eventverarbeitung vorhalten.
Weiss nicht genau, was mit "härter" gemeint ist, die Event-Verarbeitungs-Reihenfolge ist
- userReadings
- eventMap
- notifyFns, sortiert nach NTFY_ORDER (falls nicht explizit gesetzt: 50-<InstanzName>)
readingsChange schummelt sich per NTFY_ORDER nach vorne in der notifyFns-Liste.

Beta-User

Zitat von: rudolfkoenig am 12 November 2021, 11:06:18
Genauer: man kann nur dann mehrere devices und readings mit einem readingsChange-Instanz behandeln, wenn die Umwandlungs-Anweisungen fuer alle identisch sind.
Hmm, stimmt, die Option, das via regex + passender Umwandlungsanweisung mehrere gleichartige Fälle zu behandeln, war mir nicht gegenwärtig. Das könnte ggf. schon mal weiterhelfen (auch wenn es nicht so einfach sein dürfte, das Usern zu erklären).

Zitat
Weiss nicht genau, was mit "härter" gemeint ist, die Event-Verarbeitungs-Reihenfolge ist
- userReadings
- eventMap
- notifyFns, sortiert nach NTFY_ORDER (falls nicht explizit gesetzt: 50-<InstanzName>)
readingsChange schummelt sich per NTFY_ORDER nach vorne in der notifyFns-Liste.
"härter" meint
- userReadings erlauben nicht die Manipulation des "auslösenden Readings". Über den Weg geht also "true"=>"on" nicht, man bräuchte eine indirekte Lösung wie mit dem batterymV (Millivolt) => batteryVoltage-Ding (z.B. bei zigbee2mqtt_human_body_movement_illuminance);
- eventMap ändert nicht den Reading-Inhalt, sondern "nur" das Event (und darüber ggf. STATE). eventMap ist das, was ich eine "weiche" Lösung nennen würde.

readingsChange2 hat sich das "nach vorne schummeln" von readingsChange abgeschaut, nur eben mit genau einer Stufe geringerer Priorität...

(Es ist im übrigen eine "Kreuzung aus MQTT_GENERIC_BRIDGE (genauer: der Event-Handling-Anteil in Richtung publish von geänderten Readings) und readingsChange, wobei nur der MGB-Teil so funktioniert, wie er soll...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files