Hallo Freunde,
ich habe mir eine 5 Kanal Steckdosenleiste gekauft (4 gang switch, with USB) und in ZigBee2MQTT angelernt. Funktioniert dort super. Dann wollte ich es in FHEM nachkonfigurieren und scheitere tewas.
Da es keinen Prototyp für diesen in FHEM giebt, habe ich mir den zigbee2mqtt_5channel_split genommen und angepasst. Die erste Steckdose funktioniert (Abgesehen davon, das bei associatedWith nur die ersten 2 Drinstehen, das kann aber durch meine manuelle Nachkonfigurierung passiert sein).
define zigbee_Steckdosenleiste_1 MQTT2_DEVICE zigbee_Steckdosenleiste_1
attr zigbee_Steckdosenleiste_1 comment Channel 1 for zigbee_Steckdosenleiste_1
attr zigbee_Steckdosenleiste_1 devicetopic zigbee2mqtt/Steckdosenleiste_1
attr zigbee_Steckdosenleiste_1 icon message_socket
attr zigbee_Steckdosenleiste_1 jsonMap state:availability state_l1:state state_l2:0 state_l3:0 state_l4:0 state_l5:0
attr zigbee_Steckdosenleiste_1 model zigbee2mqtt_5channel_split
attr zigbee_Steckdosenleiste_1 readingList $DEVICETOPIC:.* { my $ret=json2nameValue($EVENT,'',$JSONMAP);; $ret->{state}=lc($ret->{state}) if defined $ret->{state};; return $ret }
attr zigbee_Steckdosenleiste_1 room MQTT2_DEVICE
attr zigbee_Steckdosenleiste_1 setList on:noArg $DEVICETOPIC/set {"state_l1":"ON"}\
off:noArg $DEVICETOPIC/set {"state_l1":"OFF"}\
toggle:noArg $DEVICETOPIC/set {"state_l1":"TOGGLE"}
attr zigbee_Steckdosenleiste_1 setStateList on off toggle
# CFGFN
# CID zigbee_Steckdosenleiste_1
# DEF zigbee_Steckdosenleiste_1
# FUUID 69414d84-f33f-a76c-26b1-167e8d18b0fd754d
# IODev mqtt2s
# LASTInputDev mqtt2s
# MSGCNT 137
# NAME zigbee_Steckdosenleiste_1
# NR 317
# STATE off
# TYPE MQTT2_DEVICE
# eventCount 146
# mqtt2s_CONN mqtt2s_172.28.5.3_34200
# mqtt2s_MSGCNT 137
# mqtt2s_TIME 2025-12-16 13:35:20
# .DT:
# DEVICETOPIC zigbee2mqtt/Steckdosenleiste_1
# .attraggr:
# .attrminint:
# JSONMAP:
# state availability
# state_l1 state
# state_l2 0
# state_l3 0
# state_l4 0
# state_l5 0
# OLDREADINGS:
# READINGS:
# 2025-12-16 13:16:04 IODev mqtt2s
# 2025-12-16 13:17:14 associatedWith zigbee_Steckdosenleiste_1_CH2,zigbee_Steckdosenleiste_1_CH3
# 2025-12-16 13:17:14 attrTemplateVersion 20220913
# 2025-12-16 13:35:20 child_lock UNLOCK
# 2025-12-16 13:35:20 linkquality 255
# 2025-12-16 13:35:20 power_outage_memory_l1 restore
# 2025-12-16 13:35:20 state off
# hmccu:
#
setstate zigbee_Steckdosenleiste_1 off
setstate zigbee_Steckdosenleiste_1 2025-12-16 13:16:04 IODev mqtt2s
setstate zigbee_Steckdosenleiste_1 2025-12-16 13:17:14 associatedWith zigbee_Steckdosenleiste_1_CH2,zigbee_Steckdosenleiste_1_CH3
setstate zigbee_Steckdosenleiste_1 2025-12-16 13:17:14 attrTemplateVersion 20220913
setstate zigbee_Steckdosenleiste_1 2025-12-16 13:35:20 child_lock UNLOCK
setstate zigbee_Steckdosenleiste_1 2025-12-16 13:35:20 linkquality 255
setstate zigbee_Steckdosenleiste_1 2025-12-16 13:35:20 power_outage_memory_l1 restore
setstate zigbee_Steckdosenleiste_1 2025-12-16 13:35:20 state off
ABER .. alle anderen 4 Kanäle funktionieren nur in der Anzeige, d.h. ich kann nicht über FHEM schalten, es passiert überhaupt nichts. Hier mal die Definition der 2.
define zigbee_Steckdosenleiste_1_CH2 MQTT2_DEVICE
attr zigbee_Steckdosenleiste_1_CH2 comment Channel 2 for zigbee_Steckdosenleiste_1
attr zigbee_Steckdosenleiste_1_CH2 devicetopic zigbee2mqtt/Steckdosenleiste_1
attr zigbee_Steckdosenleiste_1_CH2 icon message_socket
attr zigbee_Steckdosenleiste_1_CH2 jsonMap state_l2:state state_l1:0 state_l3:0 state_l5:0 state_l5:0 state:0 consumption:0 linkquality:0 power:0 temperature:0
attr zigbee_Steckdosenleiste_1_CH2 model zigbee2mqtt_5channel_split
attr zigbee_Steckdosenleiste_1_CH2 readingList $DEVICETOPIC:.* { my $ret=json2nameValue($EVENT,'',$JSONMAP);; $ret->{state}=lc($ret->{state}) if defined $ret->{state};; return $ret }
attr zigbee_Steckdosenleiste_1_CH2 room MQTT2_DEVICE
attr zigbee_Steckdosenleiste_1_CH2 setList on:noArg $DEVICETOPIC/set {"state_l2":"ON"}\
off:noArg $DEVICETOPIC/set {"state_l2":"OFF"}\
toggle:noArg $DEVICETOPIC/set {"state_l2":"TOGGLE"}
attr zigbee_Steckdosenleiste_1_CH2 setStateList on off toggle
# CFGFN
# CID zigbee_Steckdosenleiste_1
# DEF
# FUUID 69414dc9-f33f-a76c-836c-460bfaf5b5f68068
# IODev mqtt2s_SSL
# LASTInputDev mqtt2s
# MSGCNT 144
# NAME zigbee_Steckdosenleiste_1_CH2
# NR 318
# STATE off
# TYPE MQTT2_DEVICE
# eventCount 151
# mqtt2s_CONN mqtt2s_172.28.5.3_34200
# mqtt2s_MSGCNT 144
# mqtt2s_TIME 2025-12-16 13:38:33
# .DT:
# .attraggr:
# .attrminint:
# JSONMAP:
# consumption 0
# linkquality 0
# power 0
# state 0
# state_l1 0
# state_l2 state
# state_l3 0
# state_l5 0
# temperature 0
# READINGS:
# 2025-12-16 13:17:14 IODev mqtt2s_SSL
# 2025-12-16 13:17:14 associatedWith zigbee_Steckdosenleiste_1,zigbee_Steckdosenleiste_1_CH3
# 2025-12-16 13:17:14 attrTemplateVersion 20220913
# 2025-12-16 13:38:33 child_lock UNLOCK
# 2025-12-16 13:38:33 power_outage_memory_l1 restore
# 2025-12-16 13:38:33 state off
# 2025-12-16 13:38:33 state_l4 OFF
# 2025-12-16 13:26:07 state_l5 OFF
# hmccu:
#
setstate zigbee_Steckdosenleiste_1_CH2 off
setstate zigbee_Steckdosenleiste_1_CH2 2025-12-16 13:17:14 IODev mqtt2s_SSL
setstate zigbee_Steckdosenleiste_1_CH2 2025-12-16 13:17:14 associatedWith zigbee_Steckdosenleiste_1,zigbee_Steckdosenleiste_1_CH3
setstate zigbee_Steckdosenleiste_1_CH2 2025-12-16 13:17:14 attrTemplateVersion 20220913
setstate zigbee_Steckdosenleiste_1_CH2 2025-12-16 13:38:33 child_lock UNLOCK
setstate zigbee_Steckdosenleiste_1_CH2 2025-12-16 13:38:33 power_outage_memory_l1 restore
setstate zigbee_Steckdosenleiste_1_CH2 2025-12-16 13:38:33 state off
Wie schon gesagt, unter der Oberfläche von ZigBee2MQTT kann ich die Dosen der Leiste komplett schalten und dort wird für die obige Dose angezeigt:
State (Endpoint: l2)
Probiere jetzt schon länger und irgendwie komme ich nicht weiter. Hat jemand eine Idee, wie ich das Problem gefasst bekomme und eventuell sogar, wie ich es löse?
Wenn mehr Daten und Infos gewünscht, liefere ich sie gerne, nur aktuell weiß ich nicht, was gewünscht sein könnte .....
Ich sehe gerade:
ich habe 2 mqtt-IO-Device, einmal mit und ein mal ohne SSL. Die Dose1 der Steckdosenleiste geht über das normale (mqtt2s), die anderen dagegen über die 2. (mqtt2s_SSL). ZigBee2MQTT ist bei mir aktuell (noch) über die ohne SSL angebunden, deshalb könnte es sein, das der Schaltbefehl über das falsche IO-Device rausgeht. Nur ... wie korrigiert man dieses?
Edit:
Ja über die attribute ... hätte ich drauf kommen können. leider war es nicht die Lösung, hier die korrigierte Config:
define zigbee_Steckdosenleiste_1_CH2 MQTT2_DEVICE
attr zigbee_Steckdosenleiste_1_CH2 IODev mqtt2s
attr zigbee_Steckdosenleiste_1_CH2 comment Channel 2 for zigbee_Steckdosenleiste_1
attr zigbee_Steckdosenleiste_1_CH2 devicetopic zigbee2mqtt/Steckdosenleiste_1
attr zigbee_Steckdosenleiste_1_CH2 icon message_socket
attr zigbee_Steckdosenleiste_1_CH2 jsonMap state_l2:state state_l1:0 state_l3:0 state_l4:0 state_l5:0 state:0 consumption:0 linkquality:0 power:0 temperature:0
attr zigbee_Steckdosenleiste_1_CH2 model zigbee2mqtt_5channel_split
attr zigbee_Steckdosenleiste_1_CH2 readingList $DEVICETOPIC:.* { my $ret=json2nameValue($EVENT,'',$JSONMAP);; $ret->{state}=lc($ret->{state}) if defined $ret->{state};; return $ret }
attr zigbee_Steckdosenleiste_1_CH2 room MQTT2_DEVICE
attr zigbee_Steckdosenleiste_1_CH2 setList on:noArg $DEVICETOPIC/set {"state_l2":"ON"}\
off:noArg $DEVICETOPIC/set {"state_l2":"OFF"}\
toggle:noArg $DEVICETOPIC/set {"state_l2":"TOGGLE"}
attr zigbee_Steckdosenleiste_1_CH2 setStateList on off toggle
# CFGFN
# CID zigbee_Steckdosenleiste_1
# DEF
# FUUID 69414dc9-f33f-a76c-836c-460bfaf5b5f68068
# IODev mqtt2s
# LASTInputDev mqtt2s
# MSGCNT 204
# NAME zigbee_Steckdosenleiste_1_CH2
# NR 318
# STATE set_off
# TYPE MQTT2_DEVICE
# eventCount 216
# mqtt2s_CONN mqtt2s_172.28.5.3_34200
# mqtt2s_MSGCNT 204
# mqtt2s_TIME 2025-12-16 13:50:33
# .DT:
# .attraggr:
# .attrminint:
# JSONMAP:
# consumption 0
# linkquality 0
# power 0
# state 0
# state_l1 0
# state_l2 state
# state_l3 0
# state_l4 0
# state_l5 0
# temperature 0
# OLDREADINGS:
# READINGS:
# 2025-12-16 13:49:46 IODev mqtt2s
# 2025-12-16 13:17:14 associatedWith zigbee_Steckdosenleiste_1,zigbee_Steckdosenleiste_1_CH3
# 2025-12-16 13:17:14 attrTemplateVersion 20220913
# 2025-12-16 13:50:33 child_lock UNLOCK
# 2025-12-16 13:50:33 power_outage_memory_l1 restore
# 2025-12-16 13:50:45 state set_off
# hmccu:
#
setstate zigbee_Steckdosenleiste_1_CH2 set_off
setstate zigbee_Steckdosenleiste_1_CH2 2025-12-16 13:49:46 IODev mqtt2s
setstate zigbee_Steckdosenleiste_1_CH2 2025-12-16 13:17:14 associatedWith zigbee_Steckdosenleiste_1,zigbee_Steckdosenleiste_1_CH3
setstate zigbee_Steckdosenleiste_1_CH2 2025-12-16 13:17:14 attrTemplateVersion 20220913
setstate zigbee_Steckdosenleiste_1_CH2 2025-12-16 13:50:33 child_lock UNLOCK
setstate zigbee_Steckdosenleiste_1_CH2 2025-12-16 13:50:33 power_outage_memory_l1 restore
setstate zigbee_Steckdosenleiste_1_CH2 2025-12-16 13:50:45 state set_off
Zwei MQTT2_DEVICES für die Steckdosenleiste anlegen und das jeweilige IODev zuordnen.
In der setList und der readingList nur die Befehle für die jeweils gewünschten Steckdosen angeben.
Das habe ich doch mittlerweile?
In der "setlist" steht doch für die 2. Dose der Leiste:
on:noArg $DEVICETOPIC/set {"state_l2":"ON"}
off:noArg $DEVICETOPIC/set {"state_l2":"OFF"}
toggle:noArg $DEVICETOPIC/set {"state_l2":"TOGGLE"}
Analog für alle anderen auch. Aber nur bei der ersten Funktioniert es. habe das IODev mittlerweile auch passend eingestellt.
Sorry wenn ich Dich falsch verstehe ... und ja, zigbee2mqtt ist für alle anderen Geräte normal erreichbar und funktioniert
Wer lesen kann ist klar im Vorteil, es gab auch ein 5Kanal Template und dort steht im Commend:
"NOTE: Might need a FHEM restart to work properly."
Und ja ... das wird benötigt. Warum auch immer .... jetzt funktioniert es.
Zitat von: Wernieman am 16 Dezember 2025, 15:09:04Und ja ... das wird benötigt. Warum auch immer .... jetzt funktioniert es.
Soweit ich mich erinnere, wird intern ein "copy" ausgeführt. Dadurch werden auch alle internen Datenstrukturen mit kopiert, und das macht dann Probleme...
D.h. bei solchen Geräten, welche gesplittet werden, sollte man bei Problemen immer an einen reboot denken?
Nach jedem copy-Befehl, der ein Gerät betrifft, das ein IODev hat, empfiehlt sich ein FHEM Neustart. Das ist nicht mqtt-spezifisch.
Zitat von: betateilchen am 16 Dezember 2025, 17:45:04Nach jedem copy-Befehl, der ein Gerät betrifft, das ein IODev hat, empfiehlt sich ein FHEM Neustart. Das ist nicht mqtt-spezifisch.
Jepp. Nur halt allgemein wenig bekannt.
Soweit ich mich erinnere, kann man das per defmod reparieren, was eventuell ein Teil der tasmota-templates macht ...
Nur das man bei einem Template ein copy macht ist eben nicht sofort ersichtlich. Das war der Hauptgrund.
Zitat von: Wernieman am 16 Dezember 2025, 19:00:22Nur das man bei einem Template ein copy macht ist eben nicht sofort ersichtlich. Das war der Hauptgrund.
Es sollte eigentlich vorher angezeigt werden, welche Befehle da abgearbeitet werden.
Bin unsicher, ob es "bessere" Optionen gäbe, aber man lernt nie aus...
Könnte man bei der Beschreibung, was gemacht wird, nicht eventuell auch ein Notwendiges Reboot reinschreiben? Nur so als Idee?
Ob man es liest, ist eine andere Frage, dann ist es aber aber ein User Fail (Was es eigentlich bei mir auch so war)
Na ja, falls (!) das bei den tasmota-templates mit defmod und ohne Neustart funktioniert, wäre es imo besser, das hier auch einzubauen.
Patches sind willkommen, ich komme leider grade nicht immer dazu, alles einzupflegen, was schön wäre...
Zitattasmota-templates mit defmod und ohne Neustart funktioniert, wäre es imo besser, das hier auch einzubauen.
Wenn ich das verstehen würde, könnte ich mich ja versuchen an
ZitatPatches sind willkommen
Allerdings musste ich aus der Vergangenheit lernen, das ich zwar Admin, aber kein Programmierer bin. Und von den Interne von FHEM verstehe ich noch weniger .... (Ja aktiv schon versucht)
Vorab: patches sind eigentlich auch nur unified Text-diffs:
diff -u <oldfile> <newfile>Sollte unabhängig von der konkreten Profession für "normale computeraffine Menschen" kein größeres Hindernis sein :P .
Zitat von: Wernieman am 17 Dezember 2025, 11:20:44Wenn ich das verstehen würde, könnte ich mich ja versuchen an
Habe mal den Quellcode nach defmod durchsucht (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template):
3335 # shelly4pro using original firmware
3336 name:shelly4pro_split
3337 filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
3338 desc:shelly4pro using original firmware <br>NOTE: for each of the second to fourth channel, a new device will be created
3339 order:A_14a1
3340 par:DEVNAME;Shelly device name in the topic;{ AttrVal('DEVICE','readingList','') =~ m,shellies/([^/]*)/, ? $1 : undef }
3341 set DEVICE attrTemplate shellyplug
3342 attr DEVICE getList \
3343 power0:noArg shellies/DEVNAME/relay/0/power power0\
3344 energy0:noArg shellies/DEVNAME/relay/0/energy energy0
3345 attr DEVICE model shelly4pro_split
3346 setreading DEVICE attrTemplateVersion 20220127
3347 set DEVICE attrTemplate set_associatedWith \CHANNELS=4 \MAKECOPIES=1
3348 defmod DEVICE_CH2,DEVICE_CH3,DEVICE_CH4 MQTT2_\DEVICE DEVICE_channels Die letzte Zeile ändert das define, und soweit ich mich entsinne bewirkt das auch, dass die ganzen Internals etc. neu aufgebaut werden, wodurch man im Ergebnis nach meiner Erinnerung eben gerade keinen Neustart mehr braucht.
Ob das wirklich so ist, müßte man testen - was passiert, wenn es nicht klappt, hast du ja gesehen...
Als nächstes wäre die Frage, warum man das nicht für alle MQTT2_DEVICEs direkt in diesem "set_associatedWith"-attrTemplate mit erledigt (und einfach die CID insgesamt für alle Kopien löscht). Das ist ein "generalUse"-attrTemplate aus einer anderen file, man müßte eine "option" einbauen (und das nur für TYPE=M2D zulassen) und vorab überlegen, ob das nicht an anderer Stelle irgendwas einreißt (ich _glaube_ nicht)...
Dann das m2d-template-file durchflözen, wo überall der Aufruf des "mache channels" drin ist, und diese Templates dann vereinfachen, wo es doppelt wäre (wie bei dem Auszug oben).
Im Ergebnis hat man nach dem ganzen Aufwand dann zwei alte und neue Files, die man vergleichen kann, oder eben im Original hier anfügt oder sonstwie publik macht, damit sie im svn eingepflegt werden.
Klarer?
Also .. wie man diff verwendet war mir vorher schon klar. Nur ...
Du möchtest das defmod mit in den set_associatedWith nehmen? Weißt aber nicht, ob es funktioniert?
Wird denn das defmod dann wirklich am Ende aufgerufen? Oder denke ich mal wieder viel zu kompliziert?
Wird aber frühestens Wochenende, das ich es mir tiefer anschauen könnte, bin gerade Arbeitsmäßig im Streß
Also ..ich habe jetzt länger darüber gebrütet:
ZitatAls nächstes wäre die Frage, warum man das nicht für alle MQTT2_DEVICEs direkt in diesem "set_associatedWith"-attrTemplate mit erledigt (und einfach die CID insgesamt für alle Kopien löscht). Das ist ein "generalUse"-attrTemplate aus einer anderen file, man müßte eine "option" einbauen (und das nur für TYPE=M2D zulassen) und vorab überlegen, ob das nicht an anderer Stelle irgendwas einreißt (ich _glaube_ nicht)...
Du schriebst ""generalUse"-attrTemplate", aber trotz mehrfacher Recherche weiß ich jetzt nicht, welches andere Template Du meinst. Und die CID wird doch gar nicht im Template gesetzt?
Sorry wenn ich zu kompliziert denke .. würde ja gerne helfen.
Etwas kurz, da mobil
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/general_use.template?rev=30609#L19
Das define von MQTT2_DEVICE kann die CID beinhalten, damit autocreate (iVm. M2S) "weiß", wo es neu eingehende Topics einsortieren soll.
Diese Angabe brauchen Channel-Devices aber gar nicht, werden aber mit kopiert...
Doing währe also:
- im General Use:
- bei den Changel Device die CID löschen
- nach dem Copy ein defmod oder die copy ganz auflösen (nur wenn ja, wie)?
- in Sämmtlichen Devices mit welche CHANNELS setzen, diese bereinigen
- laut aktuellem grep nur in mqtt2.template
Und mach Dir keine Hektik, wollte nur Dein Vorschlag zur Verbesserung von FHEM durchführen und .. scheitere etwas. Mein Problem (s.o.) ist ja gelöst ....
Genauer: in dem "General use" nach der copy-option noch eine option einfügen, die prüft, ob das ein M2D ist, und nur dann das defmod ausführt (und damit die CID ganz löscht).
Da bi9n ich leider nicht genug tief drin in FHEM. würde dann folgendes richtig sein? Ist eher "gerate", also Sorry fals es falsch ist:
defmod -q TYPE=M2D DEVICE_CH2 MQTT2_\DEVICE DEVICE_channels
Analog natürlich auch für die anderen Chanels
Ich würde es anders angehen und mich am vorhandenen Stil orientieren.
Vielleicht komme ich morgen Abend dazu, das general use umzustellen, dann muss man "nur noch" die m2d.template-file aufräumen...
Wenn Du einen "Fleiß Arbeiter" brauchst, gib mir einen ping.
Da meine 5-Fach Dose nicht produktiv ist, kann ich dann auch gerne testen.
Habe eben eine (ungetestete) neue "general_use" ins svn geschubst.
Die sollte jetzt bei allen mehrkanaligen MQTT2_DEVICE's die "erste Kopie" per defmod um die CID-Angaben "erleichtern" und die internen Datenstrukturen neu initialisieren.
Tja, jetzt wollte ich die Fleißaufgabe erläutern und stelle fest, dass das aktuelle attrTemplate für diese Steckdose bereits den defmod-Aufruf (anders umgesetzt) enthält - was demnach wirkungslos ist, aber an dieser Stelle deaktiviert...
Na ja, jedenfalls ist diese zentrale Stelle eigentlich besser als sonstwo, von daher werde ich das so lassen und bei Gelegenheit nach und nach die Umstellung machen. Was zu testen wäre: Ob das sauber durchläuft und am Ende wieder alle 5 Kanäle da sind...
Ich werde dazu (zum Testen) erst nach Weihnachten kommen. Sorry aber vorher kommt Familie, trotzdem danke für Deine Arbeit!
Und bevor ich es vergesse: Dir und Deiner Familie ein Gesegnetes und Friedliches Weihnachtsfest!
Sorry es Dir zu sagen, aber Deine Korrektur hat gar nichts gebracht. Nur diesmal hilft auch ein Restart von FHEM nichts, nur die erste Dose funktioniert. Komischerweise gibt es jetzt unter:
Probably associated with
zigbee_Steckdosenleiste_1_CH2
zigbee_Steckdosenleiste_1_CH2
zigbee_Steckdosenleiste_1_CH3
zigbee_Steckdosenleiste_1_CH3
zigbee_Steckdosenleiste_1_CH4
zigbee_Steckdosenleiste_1_CH4
zigbee_Steckdosenleiste_1_CH5
zigbee_Steckdosenleiste_1_CH5
Also alles verdoppelt. ABER .. die Device existieren jeweils nur ein mal. Habe versucht mich da durchzugucken, aber ich verstehe (scheinbar) zu wenig ...
Und um sicherzugehen mein Vorgehen am Ende:
Device gelöscht, save und sicherheitshalber FHEM restart (bzw. shutdown, starten tut bei mir docker). Nach Start FHEM Device angeschlossen und autocreate. Nun das Template zugeordnet und getestet (negativ). Save und FHEM restart und nochmals getestet. Wieder negativ.
So.
Testsystem mit z2m läuft, manche Effekte muss man "live" sehen, und da gab es einige :o .
Die gute Nachricht: der defmod scheint zu funktionieren. Die schlechte: er reißt "devicetopic" mit sich, so dass danach anscheinend "$DEVICETOPIC" in setList nicht mehr aufgelöst wird...
Fix ist eingecheckt, zu viel mehr in Sachen z2m hat es heute nicht gereicht :( .
Danke .. kann aber erst am nächsten WE testen (Sorry)