MQTT2 true->on und false->off

Begonnen von cberl, 22 Mai 2020, 18:40:24

Vorheriges Thema - Nächstes Thema

Beta-User

So, nachdem ich leider auch nicht rausgefunden habe, wie man das zum laufen bekommt, habe ich eben die "event-on-change-Variante" eingecheckt (unified und split).

Da ich da auch gleich eine Art "master-Template" mit reingebastelt habe, um diese "dumme Schreibarbeit" mit den Querverweisen zukünftig zu vermeiden, kann es sein, dass da noch irgendwo ein Hund begraben ist... (=Testen für das split wäre nett).
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

cberl

Super Arbeit!

Das Unified funktioniert:

defmod ADAM6060_00D0C9FC434C_uTest MQTT2_DEVICE
attr ADAM6060_00D0C9FC434C_uTest IODev MQTT2Client
attr ADAM6060_00D0C9FC434C_uTest devStateIcon disconnect:rc_STOP@red connect:rc_STOP@green 2.on:on:do2+off 2.off:off:do2+on 3.on:on:do3+off 3.off:off:do3+on 4.on:on:do4+off 4.off:off:do4+on 5.on:on:do5+off 5.off:off:do5+on 6.on:on:do6+off 6.off:off:do6+on
attr ADAM6060_00D0C9FC434C_uTest disable 0
attr ADAM6060_00D0C9FC434C_uTest event-on-change-reading .*
attr ADAM6060_00D0C9FC434C_uTest genericDeviceType switch
attr ADAM6060_00D0C9FC434C_uTest icon on
attr ADAM6060_00D0C9FC434C_uTest jsonMap do1:state c:0 q:0 s:0 t:0
attr ADAM6060_00D0C9FC434C_uTest model 6channel_ethernet_board_6input_unified
attr ADAM6060_00D0C9FC434C_uTest readingList Advantech/00D0C9FC434C/data:.* { $EVENT =~ s/true/"on"/g;;;; $EVENT =~ s/false/"off"/g;;;; json2nameValue($EVENT,'',$JSONMAP) }\
Advantech/00D0C9FC434C/Device_Status:.* { json2nameValue($EVENT) }
attr ADAM6060_00D0C9FC434C_uTest room 82.MQTT
attr ADAM6060_00D0C9FC434C_uTest setExtensionsEvent 1
attr ADAM6060_00D0C9FC434C_uTest setList on:noArg Advantech/00D0C9FC434C/ctl/do1:r {"v":true}\
  off:noArg Advantech/00D0C9FC434C/ctl/do1:r {"v":false}\
  do2:on,off {my $payload = $EVTPART1 eq "on" ? "true" : "false";;;; qq(Advantech/00D0C9FC434C/ctl/do2:r {"v":$payload})}\
  do3:on,off {my $payload = $EVTPART1 eq "on" ? "true" : "false";;;; qq(Advantech/00D0C9FC434C/ctl/do3:r {"v":$payload})}\
  do4:on,off {my $payload = $EVTPART1 eq "on" ? "true" : "false";;;; qq(Advantech/00D0C9FC434C/ctl/do4:r {"v":$payload})}\
  do5:on,off {my $payload = $EVTPART1 eq "on" ? "true" : "false";;;; qq(Advantech/00D0C9FC434C/ctl/do5:r {"v":$payload})}\
  do6:on,off {my $payload = $EVTPART1 eq "on" ? "true" : "false";;;; qq(Advantech/00D0C9FC434C/ctl/do6:r {"v":$payload})}
attr ADAM6060_00D0C9FC434C_uTest stateFormat status\
state\
2:do2\
3:do3\
4:do4\
5:do5\
6:do6\
<br>\
DigiIn\
di1\
di2\
di3\
di4\
di5\
di6
attr ADAM6060_00D0C9FC434C_uTest webCmd :

setstate ADAM6060_00D0C9FC434C_uTest connect\
off\
2:on\
3:off\
4:on\
5:off\
6:off\
<br>\
DigiIn\
on\
on\
on\
on\
off\
on
setstate ADAM6060_00D0C9FC434C_uTest 2020-05-30 14:04:39 attrTemplateVersion 20200529
setstate ADAM6060_00D0C9FC434C_uTest 2020-05-30 14:11:06 di1 on
setstate ADAM6060_00D0C9FC434C_uTest 2020-05-30 14:11:06 di2 on
setstate ADAM6060_00D0C9FC434C_uTest 2020-05-30 14:11:06 di3 on
setstate ADAM6060_00D0C9FC434C_uTest 2020-05-30 14:11:06 di4 on
setstate ADAM6060_00D0C9FC434C_uTest 2020-05-30 14:11:06 di5 off
setstate ADAM6060_00D0C9FC434C_uTest 2020-05-30 14:11:06 di6 on
setstate ADAM6060_00D0C9FC434C_uTest 2020-05-30 14:11:06 do2 on
setstate ADAM6060_00D0C9FC434C_uTest 2020-05-30 14:11:06 do3 off
setstate ADAM6060_00D0C9FC434C_uTest 2020-05-30 14:11:06 do4 on
setstate ADAM6060_00D0C9FC434C_uTest 2020-05-30 14:11:06 do5 off
setstate ADAM6060_00D0C9FC434C_uTest 2020-05-30 14:11:06 do6 off
setstate ADAM6060_00D0C9FC434C_uTest 2020-05-30 14:10:12 ipaddr 192.168.50.54
setstate ADAM6060_00D0C9FC434C_uTest 2020-05-30 14:10:12 macid 00D0C9FC434C
setstate ADAM6060_00D0C9FC434C_uTest 2020-05-30 14:10:12 name ADAM6060
setstate ADAM6060_00D0C9FC434C_uTest 2020-05-30 14:11:06 state off
setstate ADAM6060_00D0C9FC434C_uTest 2020-05-30 14:10:12 status connect



Das Schalten bei den do Split funktioniert, in der readingList des (ersten) Device fehlt noch die Abfrage von den di1 bis di6.


defmod ADAM6060_00D0C9FC434C_sTest MQTT2_DEVICE
attr ADAM6060_00D0C9FC434C_sTest IODev MQTT2Client
attr ADAM6060_00D0C9FC434C_sTest devStateIcon disconnect:rc_STOP@red connect:rc_STOP@green
attr ADAM6060_00D0C9FC434C_sTest disable 0
attr ADAM6060_00D0C9FC434C_sTest genericDeviceType switch
attr ADAM6060_00D0C9FC434C_sTest icon on
attr ADAM6060_00D0C9FC434C_sTest model 6channel_ethernet_board_6input_split
attr ADAM6060_00D0C9FC434C_sTest readingList Advantech/00D0C9FC434C/data:.* { $EVENT =~ m/do1":(true)/g;;;; my $newstate = $1 ? "on" : "off";;;; $newstate eq ReadingsVal($NAME,"state","unknown") ? undef : {"state"=>$newstate} }\
Advantech/00D0C9FC434C/Device_Status:.* { json2nameValue($EVENT) }
attr ADAM6060_00D0C9FC434C_sTest room 82.MQTT
attr ADAM6060_00D0C9FC434C_sTest setExtensionsEvent 1
attr ADAM6060_00D0C9FC434C_sTest setList on:noArg Advantech/00D0C9FC434C/ctl/do1:r {"v":true}\
  off:noArg Advantech/00D0C9FC434C/ctl/do1:r {"v":false}
attr ADAM6060_00D0C9FC434C_sTest stateFormat status\
state\
<br>\
DigiIn\
di1\
di2\
di3\
di4\
di5\
di6
attr ADAM6060_00D0C9FC434C_sTest webCmd :

setstate ADAM6060_00D0C9FC434C_sTest connect\
off\
<br>\
DigiIn\
di1\
di2\
di3\
di4\
di5\
di6
setstate ADAM6060_00D0C9FC434C_sTest 2020-05-30 13:54:42 attrTemplateVersion 20200529
setstate ADAM6060_00D0C9FC434C_sTest 2020-05-30 14:10:12 ipaddr 192.168.50.54
setstate ADAM6060_00D0C9FC434C_sTest 2020-05-30 14:10:12 macid 00D0C9FC434C
setstate ADAM6060_00D0C9FC434C_sTest 2020-05-30 14:10:12 name ADAM6060
setstate ADAM6060_00D0C9FC434C_sTest 2020-05-30 14:11:06 state off
setstate ADAM6060_00D0C9FC434C_sTest 2020-05-30 14:10:12 status connect


Fhem immer aktuell @win2016 und @ubuntu VM|7xFRM/ArduinoEthernet|Homematic|HMLan|CUNO|HarmonyHub|Modbus|Z-Wave|Milight-Hub|MQTT|OWX an ETH-UART|GoogleAssist,Alexa,Sonos|2nHelios IP Vario|Amad-Odroid|Telegram|Enigma2

Beta-User

Danke für die Rückmeldung, den rList-Eintrag bei dem split habe ich jetzt ergänzt (nicht wundern wg. der jsonMap/do1-6:0).

@Rudi: Irgendwie hadre ich immer noch damit, dass wir hier (und evtl. anderswo) diese vielen unnötigen Events haben (und mein Versuch nicht geklappt hat, das via Perl abzustellen, immer noch keine Ahnung, warum; vermutlich ändert der irgendwie im Hintergrund $1?).
Im Moment spukt mir im Kopf der Gedanke rum, ob es nicht Sinn machen würde, json2nameValue() um noch einen Parameter zu ergänzen (event-only-if-changed, default:0). (Wenn man gemischte JSON hat, die Messwerte enthalten (deren Aktualisierung man erfahren will), muß man halt zwei Aufrufe machen und einen Prefix setzen).
Was meinst du?
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

Ich verstehe das eigentliche Problem nicht.

"Zu viele Events" an sich ist kein Problem, hoechstens wenn das zu "FHEM ist nicht schnell genug" fuehrt.
Meine Meinung zu "event-on-change-reading .*" bleibt: ich finde es nur in Ausnahmefaellen gerechtfertigt.

Beta-User

Deine Meinung zu event-on-change-reading teile ich im wesentlichen (auch wenn z.B. martinp876 irgendwo mal die Meinung vertreten hat, dass man bei CUL_HM das Attribut grundsätzlich auf .* setzen solle...).

Hier ist es aber so, dass ich das Senden von allen Zuständen eigentlich für einen Designfehler der Hardware halte. Das Ding hat nur Taster- (oder Schalter-) eingänge und Relais. Daher sollte via MQTT (!) auch immer nur das kommen, was sich geändert hat, nicht immer alles. Alles würde ich nur auf explizite Anforderung senden. Sonst stimmen die Zeitstempel nicht usw. (was z.B. bei ASC Probleme machen kann, allerdings nicht mit einem einzelnen Relay-Zustand).
Das kann man auch hinterher in FHEM reparieren, ist schon klar, aber imo werden wir immer wieder - grade bei den JSON-sprechenden Geräten - mit solchen imo überflüssigen Komplett-Infos "beglückt" werden. Da dann gleich vorne die Schere anzusetzen und wegzuschnippeln, was wir nicht brauchen, ist imo die beste Variante und auch insbesondere "event-on-change-reading" vorzuziehen.

Aber vielleicht übersehe ich mal wieder was wesentliches?
(Wie vorhin geschrieben: Es geht hier nicht um Meßwerte, sondern um Schaltzustände).
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

Ok, jetzt verstanden.
json2nameValue kennt keine Readings, man koennte es hoechstens als neuen MQTT2_DEVICE Attribut definieren, aber dann ziehe ich die globale/fhem.pl event-on-change-reading Variante vor.

Ich frage mich, warum man vermeintliche design-Fehler in FHEM reparieren muss. Ich wuerde das Attribut-Setzen dem Benutzer ueberlassen, und nicht in AttrTemplate aufnehmen. Das ist aber meine private Meinung, und nichtmal als Vorschlag gemeint.

Beta-User

Hmm, an das mit dem "noch-nicht-readings-Status" hatte ich nicht gedacht; ginge aber vermutlich, wenn man als 4. Argument "$name" übergeben könnte. Da json2nameValue() wohl immer der Vorbereitung der Reading-Aktualisierung dienen dürfte, wäre das vermutlich nicht schädlich?

Hatte gestern morgen auch noch rumgetestet, ob ich den zurückgegebenen Hash nochmal in eine loop packen kann und dann prüfen, aber auf die Schnelle wollte mir das nicht gelingen, irgendwas ging da mit den Datentypen schief. (Also falls du statt der "$name"-Variante eine "Routinier-Lösung" für readingList-Perl aus dem Ärmel schütteln magst ;) ).

Und ja, man kann die Frage stellen, ob es Sinn macht, in FHEM die Unzulänglichkeiten diverser Firmwares zu kompensieren. Vermutlich könnte man den Hersteller kontaktieren, aber ob der dann reagiert ist eine andere Frage... Da hat man bei community-Projekten vermutlich eher Chancen, aber auch da nicht immer, denn was ein "Fehler" ist, liegt ja teils auch im Auge des Betrachters. Wie dem auch sei: das zugrundeliegende Thema ist so gelagert, dass es hin und wieder vorkommt (bei dem 8-Kanal-Ethernet-Ding war es ähnlich, allerdings ohne JSON, und auch die shelly sind " Kandidaten").

Was event-on-change... angeht, werde ich das vermutlich als Attribut rausnehmen und bei nächster Gelegenheit einen farewell-Hinweis dazu einbauen. Mal schauen, ob das auch noch an anderer Stelle Sinn macht.
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

ZitatHmm, an das mit dem "noch-nicht-readings-Status" hatte ich nicht gedacht; ginge aber vermutlich, wenn man als 4. Argument "$name" übergeben könnte. Da json2nameValue() wohl immer der Vorbereitung der Reading-Aktualisierung dienen dürfte, wäre das vermutlich nicht schädlich?

Moeglich waere es schon, bloss es gehoert meiner Ansicht nach nicht hin, es waere ein Hack.
Falls event-on-change-reading nicht funktioniert: kannst Du mir zeigen, wie ich das Problem nachstellen kann?

Beta-User

Wann man etwas als Hack bezeichnen kann, würde mich allg. mal interessieren, aber du hast recht, es wäre ggf. eine andere/weitere Funktion, die man explizit nutzen sollte. Ist transparenter.

event-on- funktioniert grundsätzlich so, wie es der Name auch impliziert: Es unterdrückt den event, den trigger. Nicht mehr, nicht weniger. Das ist für "normales Event-Handling" ausreichend. Aber die Reading-Aktialisierung findet trotzdem statt, was bedeutet, dass mind. ReadingsAge was "falsches" behauptet, weil es nicht den letzten Schaltzeitpunkt zurückgibt (das wäre optimal), sondern eben den Zeitpunkt der letzten Aktualisierung. Ob das SetExtensions-Timer "kaputtmacht" kann ich nicht sagen, aber evtl. cberl? (also: setze den Hauptkanal auf "on-for-timer" und drücke dann irgendeine Taste, die damit nichts zu tun hat.

Der Vollständigkeit wegen noch mein nicht funktionierender Schleifen-Test-Code; geht evtl. besser mit map?
defmod ADAM6060_00D0C9FC434C_unified MQTT2_DEVICE
attr ADAM6060_00D0C9FC434C_unified IODev m2server
attr ADAM6060_00D0C9FC434C_unified devStateIcon disconnect:rc_STOP@red connect:rc_STOP@green 2.on:on:do2+off 2.off:off:do2+on 3.on:on:do3+off 3.off:off:do3+on 4.on:on:do4+off 4.off:off:do4+on 5.on:on:do5+off 5.off:off:do5+on 6.on:on:do6+off 6.off:off:do6+on
attr ADAM6060_00D0C9FC434C_unified jsonMap do1:state c:0 q:0 s:0 t:0
attr ADAM6060_00D0C9FC434C_unified readingList Advantech/00D0C9FC434C/data:.* { $EVENT =~ s/true/"on"/g;; $EVENT =~ s/false/"off"/g;; my %rets = json2nameValue($EVENT,'',$JSONMAP);; my %cleaned;; for my $k (keys %rets) { if (ReadingsVal($NAME,$k,"unknown") ne $rets{$k}) { $cleaned{$k} = $rets{$k};;} };; return \%cleaned;;}\
Advantech/00D0C9FC434C/Device_Status:.* { json2nameValue($EVENT) }
attr ADAM6060_00D0C9FC434C_unified room Test
attr ADAM6060_00D0C9FC434C_unified setExtensionsEvent 1
attr ADAM6060_00D0C9FC434C_unified setList on:noArg Advantech/00D0C9FC434C/ctl/do1:r {"v":true}\
off:noArg Advantech/00D0C9FC434C/ctl/do1:r {"v":false}\
do2:on,off {my $payload = $EVTPART1 eq "on" ? "true" : "false";; qq(Advantech/00D0C9FC434C/ctl/do2:r {"v":$payload})}\
do3:on,off {my $payload = $EVTPART1 eq "on" ? "true" : "false";; qq(Advantech/00D0C9FC434C/ctl/do3:r {"v":$payload})}\
do4:on,off {my $payload = $EVTPART1 eq "on" ? "true" : "false";; qq(Advantech/00D0C9FC434C/ctl/do4:r {"v":$payload})}\
do5:on,off {my $payload = $EVTPART1 eq "on" ? "true" : "false";; qq(Advantech/00D0C9FC434C/ctl/do5:r {"v":$payload})}\
do6:on,off {my $payload = $EVTPART1 eq "on" ? "true" : "false";; qq(Advantech/00D0C9FC434C/ctl/do6:r {"v":$payload})}
attr ADAM6060_00D0C9FC434C_unified stateFormat status\
state\
2:do2\
3:do3\
4:do4\
5:do5\
6:do6\
<br>\
DigiIn\
di1\
di2\
di3\
di4\
di5\
di6
attr ADAM6060_00D0C9FC434C_unified webCmd :

Das reagiert aber gar nicht auf unterschiedliche publishes:
mosquitto_pub -h localhost -i test -m '{"s":1,"t":0,"q":192,"c":1,"di1":true,"di2":true,"di3":true,"di4":true,"di5":false,"di6":true,"do1":false,"do2":false,"do3":false,"do4":false,"do5":false,"do6":true}' -t Advantech/00D0C9FC434C/datamosquitto_pub -h localhost -i test -m '{"s":1,"t":0,"q":192,"c":1,"di1":true,"di2":true,"di3":true,"di4":true,"di5":false,"di6":true,"do1":false,"do2":false,"do3":false,"do4":false,"do5":false,"do6":false}' -t Advantech/00D0C9FC434C/data
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

ZitatWann man etwas als Hack bezeichnen kann, würde mich allg. mal interessieren
Hack fuer mich ist etwas, was jemand, der die Architektur eines Programmes kennt, nicht erwartet.
Es gehoert entweder nicht an dieser Stelle oder nicht so geloest.

ZitatAber die Reading-Aktialisierung findet trotzdem statt, was bedeutet, dass mind. ReadingsAge was "falsches" behauptet, weil es nicht den letzten Schaltzeitpunkt zurückgibt (das wäre optimal), sondern eben den Zeitpunkt der letzten Aktualisierung.

Dieses Problem koennte man mit timestamp-on-change-reading verarzten:
ZitatThe attribute takes a comma-separated list of readings. You may use regular expressions in that list. If set, the timestamps of the listed readings will not be changed if event-on-change-reading is also set and it would not create an event for this reading.

rudolfkoenig

ZitatDer Vollständigkeit wegen noch mein nicht funktionierender Schleifen-Test-Code; geht evtl. besser mit map?
json2nameValue liefert eine Referenz auf ein Hash zurueck und nicht ein Hash, ich kriege mit deinem Code "Reference found where even-sized list expected" in Log.

Die Loesung mit map ist etwas kuerzer, aber nicht "richtiger":

Advantech/00D0C9FC434C/data:.* { $EVENT =~ s/true/"on"/g;; $EVENT =~ s/false/"off"/g;; my $rets = json2nameValue($EVENT,'',$JSONMAP);; my %cleaned;; map { $cleaned{$_} = $rets->{$_} if(ReadingsVal($NAME,$_,"unknown") ne $rets->{$_}) } keys %{$rets};; return \%cleaned }


Die grep Variante spart nochmal ein paar Buchstaben:

Advantech/00D0C9FC434C/data:.* { $EVENT =~ s/true/"on"/g;; $EVENT =~ s/false/"off"/g;; my $rets = json2nameValue($EVENT,'',$JSONMAP);; my %cleaned = map { $_,$rets->{$_} } grep { ReadingsVal($NAME,$_,"unknown") ne $rets->{$_} } keys %{$rets};; return \%cleaned }


Beta-User

Doppeltes Danke!

timestamp-on... war mir irgendwie bisher völlig entgangen, aber eigentlich war es logisch, dass es sowas geben muß. (Shame on me!)

Was den Code angeht, hatte ich diverse Varianten ausprobiert und irgendwie mit dem letzten scheinbar gar keine Meldung im FHEM-log (gestern schon, aber mit anderen Varianten; evtl. ist da ein paarmal standby dazwischengekommen). Aber so langsam wird das mir Referenz auf Hash und direkt Hash wieder ein Stückchen klarer, auch wenn das vermutlich noch "ewig" dauern wird, bis ich das soweit intus habe, dass es halbwegs "automatisch" in die richtige Richtung geht mit der Syntax....
Von der Tendenz her würde ich jetzt die map/grep-Fassung einchecken, das sieht mir nach dem "richtigen" Weg hier aus. Oder würdest du alternativ eher den farewell mit (event|timestamp)-on-change-reading-Hinweis bevorzugen?
(Das läßt sich leichter auf ähnliche Fälle übertragen?)
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


cberl

Ich habe jetzt die grep Variante genommen - Funktioniert Bestens: Jetzt werden nur noch die Readings aktualisiert, wo auch was passiert.

Vielen Dank Euch Beiden!
Fhem immer aktuell @win2016 und @ubuntu VM|7xFRM/ArduinoEthernet|Homematic|HMLan|CUNO|HarmonyHub|Modbus|Z-Wave|Milight-Hub|MQTT|OWX an ETH-UART|GoogleAssist,Alexa,Sonos|2nHelios IP Vario|Amad-Odroid|Telegram|Enigma2

Beta-User

Hallo, Danke für die Rückmeldung; hatte diese Variante zwischenzeitlich eingecheckt und den Code gleich noch hier zum "recycling" vorgeschlagen: https://forum.fhem.de/index.php/topic,111711.msg1060727.html#msg1060727...

Vielleicht magst du bei Gelegenheit nochmal die jetzige split-Variante testen, da habe ich noch ein paar Kleinigkeiten geändert, die ggf. dann auch weiter ausgerollt werden.
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