Umzug v. MQTT_DEVICE und XiaomiMQTTDevice nach MQTT2_DEVICE

[Blauhorn]

Guten Tag,

auf Anregung von Beta-User wende ich mich mal in diesen Bereich um Unterstützung für folgende Aufgabenstellung:

Ich habe recht viele Geräte im MQTT-Umfeld bei mir am laufen, aber alles reichlich durcheinander weil historisch gewachsen, das ich nun gerne entwirren möchte.
Randbedingung sind jedoch einige sensible Anwendungen, deren Ausfall über länger als wenige Stunden ich nicht so gerne riskieren würde.
Das Setup sieht folgendermaßen aus:

MQTT -> Server:mosquitto, localhost:1883
MQTT_DEVICE -> ca. 20 Sonoff-Funkschalter mit Tasmota-FW (unterschiedliche Release-Stände)
XiaomiMQTTDevice -> xbridge -> mosquitto->zigbee2mqtt -> CC2530
XiaomiMQTTDevice -> mosquitto->zigbee2mqtt -> 8 Temperatur und Feuchtesensoren, 12 Fensterkontakte,
XiaomiMQTTDevice -> mosquitto->zigbee2mqtt -> 8 Wandtaster, 2 Tradfri Remotecontrol
XiaomiMQTTDevice -> mosquitto->zigbee2mqtt -> 3 Tradfri dimmbare Bulbs
MilightBridge via sidoh-GW-> MilightDevice -> 5 RGBW-Bulbs

Meine Aufgabe besteht nun darin, all diese Geräte unterschiedlichen Typs auf MQTT2_DEVICE zu bringen, und das möglichst ohne das System für längere Zeit ausfallen zu lassen.
Die Sonoff-Aktoren steuern meine Fußbodenheizkreise über PWMR, daran sind ebenfalls Fensterkontakte und Temp.-Sensoren geknüpft.

Vielleicht hat von Euch jemand Ideen, dies möglichst reibungslos hin zu bekommen.


Vielen Dank für Anregungen

[TomLee]

Hallo,

hoffe sage nix falsches: einfach einen MQTT2_Server mit anderem als den Standardport 1883 zB. 1884 definieren und Stück für Stück auf die automatisch angelegten Devices das entsprechende Template anwenden.

Deine alten MQTT_DEVICE-Definition kannst du erstmal beibehalten, das klappt alles auch parallel.

Gruß

Thomas

[Beta-User]

Hallo Blauhorn,

was du vorab entscheiden solltest, wäre, ob du mittelfristig den mosquitto weiter am laufen halten willst oder nicht (=Umstieg auf MQTT2_SERVER).

Da du das vermutlich nicht entscheiden willst, bevor du Erfahrung mit MQTT2_DEVICE hast, solltest du das als erstes zunächst kennenlernen. Vorab empfehle ich die Lektüre der "Praxisbeispiele" im Wiki.

Zum Kennenlernen und zur Umstellung gäbe es zwei Ansätze, die man auch parallel verfolgen kann, ich schreibe das jetzt etwas länger, damit ggf. auch andere Hinweise finden, was jeweils zu beachten ist. Bitte nicht verwirren lassen, das klingt erst mal komplizierter, als es eigentlich ist:

- Der einfachste Einstieg ist immer mit MQTT2_SERVER, wie von Thomas auch vorgeschlagen. Der "kennt" die jeweilige Datenquelle ("CID") und bildet via autocreate auch (meistens) gleich sinnvolle Devices - Einschränkungen gibt es da nur bei den Interfaces, die wieder die Übersetzung in eine andere Technik machen (bei dir: zigbee2mqtt und die MiLight-Bridge). Bei dieser Art Device braucht man (meistens und sinnvollerweise) ein weiteres (MQTT2_DEVICE) Device, das diese "Brücke" darstellt, und kann leider nur immer den ganzen Zweig auf einmal umstellen (keine Sorge, es gibt workarounds: siehe unten).
Hier könnte man z.B. einzelne Tasmota-Devices einfach mit einem MQTT2_SERVER auf einem anderen Port "reden" lassen. Das Problem dabei ist aber, dass man sinnvollerweise ein attrTemplate anwendet, wenn das Device via autocreate angelegt wurde, und dieses dann die Einstellungen des Tasmota ändert. Dadurch wird z.B. aus "OFF" "off" und es wird immer POWER1 statt POWER verwendet. Das erschwert den Rückweg etwas, und du mußt uU. Eventhandler (notify/DOIF) ansehen, ob die mit der Kleinschreibung ein Problem haben.

Die Umstellung "Schritt für Schritt" sähe dann so aus (zur Empfehlung hier - wegen MiLight und zigbee2mqtt - s.u.!):

Vorbereitung:
-- MQTT2_SERVER definieren, z.B. auf Port 1884;
-- MQTT2_CLIENT definieren, der lauscht erst mal auf den mosquitto

Devices erstellen:
-- via autocreate durch MQTT2_SERVER, dabei einfach am Tasmota Port umstellen (die IP ist ja hier für Mosquitto und MQTT2_SERVER gleich, sonst würde die IP reichen und man könnte denselben Port nutzen);
-- erforderlichenfalls attrTemplate anwenden, dann ggf. den Tasmota auch mal neu starten und Schaltvorgänge/Meßdatenübertragungen usw. abwarten (damit die readingList vollständig wird);
-- Eventhandler checken, ob was zu ändern ist (v.a. on/off in Auswertung bzw. set-Anweisung)

Eigentliche Umstellung:
-- altes Device löschen, das neue so umbenennen, dass es heißt wie das alte, Eventhandler anpassen
-- Das Teil auf den MQTT2_CLIENT als IO umstellen und auf dem Tasmota wieder die 1883 eintragen, damit der Verkehr erst mal wieder über mosquitto läuft. (Den schalten wir dann ganz am Ende ab, wenn alle Devices als funktionierende MQTT2_DEVICES vorhanden sind...)


- Die andere Möglichkeit ist, das via MQTT2_CLIENT zu machen (und, sofern gewünscht, erst ganz am Schluss den Server auszutauschen).

-- autocreate: Das "Problem" dabei ist, dass man uU. mit einem unkontrollierten autocreate erst mal scheinbar "seltsame" Ergebnisse bekommt (erst landet alles in einem Device, wendet man das attrTemplate "A_00_MQTT2_CLIENT_general_bridge" an, bekommt man einzelne Devices, aber uU. stimmt die CID nicht mit dem überein, was der MQTT2_SERVER (korrekterweise) tun würde. Das kann dann später ggf. etwas Nacharbeitsbedarf verursachen: Neue Readings landen dann uU. nicht in dem Device, zu dem sie eigentlich gehören.(Man kann das beides ohne weiteres nachträglich korrigieren, v.a., wenn man mal verstanden hat, an welchen "Stellschrauben" man drehen muß).
-- hat man MQTT_GENERIC_BRIDGE im Einsatz, sollte autocreate entweder ausgeschaltet bleiben, oder die subscriptions am MQTT2_CLIENT entsprechend eng gewählt werden.
-- Macht man es "händisch", muß man "eigentlich" schon wissen, wo man hinwill, sonst gibt's dieselben Effekte .

-- Willst du den MQTT2_CLIENT-Weg gehen, würde ich ein Testsystem empfehlen, und darauf dann (mit demselben Namen, aber einer per Attribut manuell vergebenen anderen CID, bitte) ebenfalls einen MQTT2_CLIENT installieren, der auf den mosquitto auf dem Hauptsystem lauscht. Da kannst du dann einigermaßen gefahrlos mal austesten, wie sich autocreate iVm. A_00_MQTT2_CLIENT_general_bridge anfühlt und probeweise mal alle MiLight und zigbee2mqtt-Geräte simulieren bzw. die attrTemplates dazu austesten. (Die verändern - anders als die Tasmota-templates - nichts an den Einstellungen der Bridges oder Endgeräte...!)

-- Die RAW-Definitionen kannst du dann ohne weiteres (ggf. nach Anpassung des IO-Namens) auch vom Testsystem auf das Hauptsystem übertragen. Dann hast du ggf. beide Varianten (neu/alt) parallel und kannst dann die "Feinarbeiten" vollends vornehmen - Gerät für Gerät, so wie du dazu kommst.



OK, das war jetzt vermutlich ziemlich viel verwirrende Theorie?

Praktisch würde ich jetzt folgendes vorschlagen:
1. Ich _glaube_, dass die Umstellung des MiLight-Zweiges recht einfach sein sollte und eine gute Übung sein dürfte. Es sind nur 5 Devices, wie wichtig, weiß ich allerdings nicht. Definiere einen MQTT2_SERVER auf Port 1884, und stelle die Sidoh-Bridge so um, dass die dahin sendet (ganz wie oben zu Tasmota beschrieben), wende das Bridge-Template (X_01_esp_milight_hub_bridge) auf das von autocreate erstellte Device an und schalte dann (via FB oder am Hub direkt) alle Geräte mal durch, darauf dann die passenden templates anwenden.
Dann kannst du sehen, ob das für deine Zwecke so paßt und wie groß ggf. der Umstellungsbedarf im Umfeld ist (Eventhandler).
Hast du alle 5 als MQTT2_DEVICE (also 6, mit dem Bridge-Gerät), sollte auch die Rückumstellung auf Port 1883 (und MQTT2_CLIENT) kein Problem darstellen.
Geht was schief, kannst du jederzeit einfach auf Port 1883 umstellen und die alten Devices (parallel) nutzen und Gerät für Gerät umstellen (v.a. bzgl. der Eventhandler).

2. Ist dir das Prinzip bei den MiLights dann verständlich geworden, kannst du _dasselbe_ mit zigbee2mqtt machen: Port in der yaml auf 1884 ändern & Dienst neu starten, auf das erste entsprechende Device L_01_zigbee2mqtt_bridge anwenden, wieder etwas warten, bis ein paar/möglichst alle Devices angelegt wurden (dauert halt, manche senden nur 1x alle Stunde oder so, in jedem Fall die "devicelist" anfordern, damit du die vollständige Liste hast, was alles da sein sollte unter welcher CID). Dann einfach wieder yaml auf Port 1883 umstellen & zigbee2mqtt-Dienst neu starten, IO an den Devices auf den CLIENT umstellen. (Evtl. das autocreate am Bridge-Device auf 1 stellen, kann sein, dass dann auch weitere/neue Devices angelegt werden).
Auch da sollte dann eine Umstellung Gerät für Gerät kein Problem darstellen.

3. Ganz zum Schluß dann die ganzen Tasmota-Geräte (ggf. nach einem update, schadet in der Regel nicht...). Wenn es "weniger wichtige" darunter gibt, kannst du die natürlich vorziehen.

Hoffe, dich damit nicht zu sehr erschreckt zu haben. Du mußt auch nicht alles gleich und vorab verstanden haben, manches kann man erst verstehen, wenn man "sieht", was da passiert.

Viel Erfolg, und Fragen dazu sind ausdrücklich erwünscht; das soll schließlich nicht nur dir helfen...

Gruß, Beta-User

[Blauhorn]

Hallo Beta-User,

vielen Dank für diese sehr ausführliche Anleitung.
Erschreckt hast Du mich nur ein bisschen, ich denke ich werde ein ganze Menge lernen.
Ich werde mit etwas zittrigen Händen an die Arbeit gehen, den Einstieg mit den Milight-Devices machen und hier berichten.

Gruß Blauhorn

[Beta-User]

Zum Zittern besteht keine Veranlassung .

Trotz der Länge habe ich eine Sache "unterschlagen", auf die du aber evtl. auch selbst gekommen wärst :
Wie gesagt, MQTT2_SERVER und MQTT2_CLIENT haben uU. ein etwas verschiedenes Verständnis davon, was die CID eines Geräts angeht. Das schlägt sich nicht nur in der DEF nieder (das wurde bereits angerissen), sondern v.a. auch in der readingList...

Wenn du also dort Einträge hast, die mit "<irgendwas>:" beginnen, wirf' diesen ersten Teil (CID+":") bitte raus, bevor du Geräte zwischen den IO-Typen umhängst. Das sollte also jeweils immer direkt mit dem Topic beginnen.

(Und in die setList/getList-Einträge selbstredend keine "<CID>:"-Ergänzungen zu den Topics reinnehmen, aber auf den Gedanken kommt man in der Regel auch gar nicht erst... )

Gutes Gelingen,

Beta-User

[Blauhorn]

So, das erste Device ist umgestellt. Dazu habe ich folgendes getan:

Code Auswählen Erweitern


defmod MQTT2_Server MQTT2_SERVER 1884 global
attr MQTT2_Server autocreate simple
attr MQTT2_Server room MQTT2_DEVICE


Beim Milight-GW bin ich abgestorben, das will irgendwie nicht sniffen, so kriege ich auch keine device_ids aus der FB raus, muss ich morgen mal in Ruhe nochmal versuchen.
Ist das  in diesem Bild so richtig eingestellt?
Nächste Versuch ging gut mit einem Dual-Sonoff:
- Port auf 1884 geändert, Neustart, paarmal geschaltet und autocreate hat brav angelegt.
- template A_02_tasmota_2channel_split angelegt
und danach nur noch umbenannt und die zughörige LightScene neu bestückt. Danach lief alles gut.
Ich mach morgen weiter.
Frage noch: es werden immer automatisch zu jedem Gerät neue MQTT2_SERVER angelegt, mit hohen Portnummern. Wieso dies denn?

Dies vom Milight-hub

Code Auswählen Erweitern


defmod MQTT2_Server_192.168.178.30_64252 MQTT2_SERVER
attr MQTT2_Server_192.168.178.30_64252 room hidden

setstate MQTT2_Server_192.168.178.30_64252 Connected
setstate MQTT2_Server_192.168.178.30_64252 2019-09-16 18:35:25 state Connected


und dies vom Dual Sonoff

Code Auswählen Erweitern


defmod MQTT2_Server_192.168.178.72_5722 MQTT2_SERVER
attr MQTT2_Server_192.168.178.72_5722 room hidden

setstate MQTT2_Server_192.168.178.72_5722 Connected
setstate MQTT2_Server_192.168.178.72_5722 2019-09-16 21:53:00 state Connected



Gruß vom Blauhorn

[Beta-User]

  Schön, dass das mit dem Sonoff stressfrei geklappt hat.

Was die temporären weiteren MQTT2_SERVER-Devices angeht: das ist normal, für jede offene Verbindung legt FHEM da was an. Die verschwinden auch wieder, das Verhalten ist ansonsten auch bei anderen offenen Netzwerkverbindungen so, du kannst das auch z.B. bei FHEMWEB beobachten.

Der Server steht auch ohne explizit gesetztes Attribut auf "autocreate simple", das anzuschalten ist also hier unnötig (anders bei MQTT2_CLIENT).


Was das MiLight-GW angeht:
(- Vorab sicherstellen, dass die fw aktuell ist, derzeit also 1.10.1.)
Ich nutze folgende Einstellungen (muß mal nachsehen, ob das alles im Wiki enthalten ist):
- milight/:device_id/:device_type/:group_id für "topic pattern"- milight/updates/:hex_device_id/:device_type/:group_id für "update topic pattern"
- milight/states/:hex_device_id/:device_type/:group_id für "state topic pattern"
- milight/LWT für "Client Status Topic", "Detailed" mode
- senden lasse ich mir derzeit: "status, brightness, hue, color, mode, color_temp, bulb_mode, computed_color, hex_color" (da ist vermutlich zu viel drin, und bei einem Eventhandler muß man uU.
darauf achten, dass kurz hintereinander zweimal dasselbe Event kommen kann (für ON/OFF)).

Ohne dass zu states oder updates was eingetragen ist, wird es nicht klappen, und LWT ist erforderlich, wenn du z.B. den "online"-Status haben willst; außerdem wird dann (mit LWT-Angabe) das Device via autocreate angelegt, ohne dass irgendwas gesnifft würde.

Da du ein anderes Base-topic hast: Das ist kein Problem, das template sollte das erkennen und dann die bridgeRegexp auch auf "wbw22_milights" einstellen. Wenn da was anderes steht oder du ein Dialogfeld angezeigt bekommen solltest: bitte melden .

[Blauhorn]

So, bin gestern abend nun weiter voran gekommen und habe nun die ersten Aktoren für die Fußbodenheizung umgestellt. Das sind 4-CH-Sonoffs mit Tasmota. Dies Geschichte ging recht reibungslos, wenngleich die Nachbearbeitung der SVG-Graphen etwas mühsam war. Ich habe die Bezeichnungen der Aktoren verändert und die Schalt-Readings, die ich gerne direkt aus dem Sonoff anzeigen möchte (und nicht aus dem actorState der PWMR) heißen jetzt StateText1 bis StateText4.
Cooler Nebeneffekt: ich habe für 4 Heizkreise jetzt ein Device anstatt 4 Einzelnen, das macht die Darstellungen übersichtlicher.

Beim Milight-Zweig bin ich nur teilweise vorangekommen. Ich habe die Topic-Patterns nochmal verändert und auch richtig in die sidoh-Bridge Weboberfläche eingetragen, die Bridge wird autocreatet, das Template angewendet, usw. -> passt.
Jetzt habe ich zwei der Bulbs erstmal angelernt, und kann diese über die Weboberfläche der Bridge schalten. ->passt auch.
Die Bulbs werden aber nicht als MQTT2_DEVICE über autocreate angelegt. Woran kann das liegen? Die Bridge gibt beim schalten Readings in vielen Varianten, die alle auch die beiden DEVICE_ID enthalten.

Code Auswählen Erweitern


define MQTT2_milight_hub_1330194 MQTT2_DEVICE milight_hub_1330194
attr MQTT2_milight_hub_1330194 IODev MQTT2_Server
attr MQTT2_milight_hub_1330194 autocreate 1
attr MQTT2_milight_hub_1330194 bridgeRegexp milight/[^/]*at[^/]+/(0x....)/.*/([0-8])?.*:.* "milight_$1_$2"
attr MQTT2_milight_hub_1330194 devStateIcon connected:10px-kreis-gruen disconnected.*:10px-kreis-rot
attr MQTT2_milight_hub_1330194 model X_01_esp_milight_hub_bridge
attr MQTT2_milight_hub_1330194 readingList milight_hub_1330194:milight/LWT:.* { json2nameValue($EVENT) }\\nmilight_hub_1330194:milight/updates/0x3E9/rgbw/1:.* { json2nameValue($EVENT) }\\nmilight_hub_1330194:milight/states/0x3E9/rgbw/1:.* { json2nameValue($EVENT) }\\nmilight_hub_1330194:milight/updates/0x3EA/rgbw/1:.* { json2nameValue($EVENT) }\\nmilight_hub_1330194:milight/states/0x3EA/rgbw/1:.* { json2nameValue($EVENT) }\\nmilight_hub_1330194:milight/updates/0x3E9/rgb_cct/1:.* { json2nameValue($EVENT) }\\nmilight_hub_1330194:milight/states/0x3E9/rgb_cct/1:.* { json2nameValue($EVENT) }\\nmilight_hub_1330194:milight/updates/0x0/rgb_cct/1:.* { json2nameValue($EVENT) }\\nmilight_hub_1330194:milight/states/0x0/rgb_cct/1:.* { json2nameValue($EVENT) }\\nmilight_hub_1330194:milight/updates/0x3EA/rgbw/2:.* { json2nameValue($EVENT) }\\nmilight_hub_1330194:milight/states/0x3EA/rgbw/2:.* { json2nameValue($EVENT) }
attr MQTT2_milight_hub_1330194 room MQTT2_DEVICE
attr MQTT2_milight_hub_1330194 setStateList on off
attr MQTT2_milight_hub_1330194 stateFormat <a href="http://ip_address" target="_blank">\\nstatus\\n</a>Version: \\nversion


Woran kann das liegen?
Heut oder morgen geht es mit dem zigbee2mqtt-Zweig weiter.

[Beta-User]

(Grummel, hatte eben eine längere Antwort fertig, dann wollte hier das Forum gewartet werden...)

Daher jetzt kurz: Bitte im Wiki "Import von Code Snippets" beachten, das was du hier postest, sieht verdächtig nach fhem.cfg aus und dann noch einem ungeeigneten Editor...

Die ID's sollten 4-stellig sein, also z.B. so aussehen "0xF234". Bitte möglichst dieses Format verwenden, sollte die Bridge dafür verantwortlich sein, dass keine Nullen übermittelt werden, die bridgeRegex anpassen ("0x[0-9A-F]+" statt "0x....").

Die readingList bitte verkürzen zu

Code Auswählen Erweitern

attr MQTT2_milight_hub_1330194 readingList milight_hub_1330194:milight/LWT:.* { json2nameValue($EVENT) }

[Blauhorn]

Danke,

sorry, das mit dem Code-Snippet liegt daran, dass ich von unterwegs keinen direkten Zugriff auf mein System habe, nur die magere Kommandozeile über den TelegramBot mit den entsprechenden Ausgaben.
Okay, also die bridgeRegex überprüfen, und die Readinglist einschmelzen. Mach ich heute abend.
Verstehe ich das richtig, dass aus den weiter übermittelten Readings dann die Bulb-Devices generiert werden?

Noch eine Frage zur Erweiterung von den Sonoffs:
Falls ich Firmwareupdates auch aus FHEM heraus anschubsen will, dann müsste ich wahrscheinlich das Attribut setList des Devices um

Code Auswählen Erweitern


UPGRADE: cmnd/sonoff/upgrade 1

erweitern.Richtig?
... wobei "sonoff" gerade default für das eine Geräte ist, das ändere ich noch in eindeutige Topics für dann alle Geräte.

[Beta-User]

Verstehe ich das richtig, dass aus den weiter übermittelten Readings dann die Bulb-Devices generiert werden?

Genau. (Aber nur, wenn es nicht schon "Abnehmer" gibt).

Noch eine Frage zur Erweiterung von den Sonoffs:
Falls ich Firmwareupdates auch aus FHEM heraus anschubsen will, dann müsste ich wahrscheinlich das Attribut setList des Devices um

Code Auswählen Erweitern


UPGRADE: cmnd/sonoff/upgrade 1

erweitern.
Richtig?

Kann ich nichts zu sagen, ich habe wenig Tasmota-Erfahrung und kenne die fast nur wegen der templates . Sowas würde ich eher über die Web-Oberfläche machen, die IP ist ja jeweils angezeigt, und die firmware-Version wird auch mitgeschickt, oder?

[Blauhorn]

Jetzt steckts bei den milight-dingern fest. Ich kürze die readingList aber wenn ich hernach die bulbs über WEB-UI schalte, wird das wieder erweitert.  Neue Devices legt das nicht an.

Was kann falsch sein?

[Beta-User]

Du verwendest ID's die m.E. ungültig sind. Die sollten in Hex so aussehen, "0xAB34", aber deine sind einstellig oder 3-Stellig (hinter dem 0x für Hex).

Wenn das echte FB-Code sind, die der Hub so empfängt, mußt du die bridgeRegexp anpassen, ansonsten wäre es besser, du würdest einfach standardkonforme ID's verwenden, und nicht was "spezielles" erfinden (von dem ich bisher nicht wußte, dass das geht, ID's mit einer oder 3 Stellen; vermutlich füllt die firmware das für's senden auf...)

Kannst ja mal statt "0x3E9" "0x03E9" (bzw. "0x3E90") versuchen, ob dann die Lampe noch schaltet und der korrekte Kenner übermittelt wird?

[Blauhorn]

Ein Licht geht auf! Danke für Deine Geduld.
Der Witz war, dass ich die IDs in der sidoh-Web-UI frei eingetragen habe, so wie ich mir das dachte (im sidoh-Wiki steht dass alles zwischen 0x0000 und 0xFFFF geht).
Ich habe jetzt IDs genommen, die auf jeden Fall gehen.

[Blauhorn]

Nächste Sache: die mehrkanaligen Sonoffs.
Ich habe Schwierigkeiten, das PWMR-Device zu schalten. Hintergrund ist folgende Def.:

das Sonoff 4CH so:

Code Auswählen Erweitern


defmod MQTT2_78 MQTT2_DEVICE DVES_88DD49
attr MQTT2_78 IODev MQTT2_Server
attr MQTT2_78 autocreate 0
attr MQTT2_78 devStateIcon Online:10px-kreis-gruen Offline:10px-kreis-rot 1.on:on:POWER1+off 1.off:off:POWER1+on 2.on:on:POWER2+off 2.off:off:POWER2+on 3.on:on:POWER3+off 3.off:off:POWER3+on 4.on:on:POWER4+off 4.off:off:POWER4+on
attr MQTT2_78 model A_04b_tasmota_4ch_unified_icon
attr MQTT2_78 readingList tele/sonoff_4ch_78/LWT:.* LWT\
  tele/sonoff_4ch_78/STATE:.* { json2nameValue($EVENT) }\
  tele/sonoff_4ch_78/SENSOR:.* { json2nameValue($EVENT) }\
  tele/sonoff_4ch_78/INFO.:.* { json2nameValue($EVENT) }\
  stat/sonoff_4ch_78/RESULT:.* { json2nameValue($EVENT) }\
  tele/sonoff_4ch_78/UPTIME:.* { json2nameValue($EVENT) }\
  stat/sonoff_4ch_78/POWER1:.* POWER1\
  stat/sonoff_4ch_78/POWER2:.* POWER2\
  stat/sonoff_4ch_78/POWER3:.* POWER3\
  stat/sonoff_4ch_78/POWER4:.* POWER4
attr MQTT2_78 room Heizung,Heizung_EG,MQTT2_DEVICE
attr MQTT2_78 setList POWER1:on,off,toggle cmnd/sonoff_4ch_78/POWER1 $EVTPART1\
  POWER2:on,off,toggle cmnd/sonoff_4ch_78/POWER2 $EVTPART1\
  POWER3:on,off,toggle cmnd/sonoff_4ch_78/POWER3 $EVTPART1\
  POWER4:on,off,toggle cmnd/sonoff_4ch_78/POWER4 $EVTPART1
attr MQTT2_78 setStateList on off toggle
attr MQTT2_78 stateFormat LWT\
1:POWER1\
2:POWER2\
3:POWER3\
4:POWER4\
<br>\
<a href="http://192.168.178.78" target="_blank">IPAddress</a>
attr MQTT2_78 webCmd POWER1:POWER2:POWER3:POWER4

setstate MQTT2_78 Online\
1:off\
2:off\
3:off\
4:off\
<br>\
<a href="http://192.168.178.78" target="_blank">192.168.178.78</a>
setstate MQTT2_78 2019-09-17 18:39:53 Backlog Appended
setstate MQTT2_78 2019-09-17 18:39:54 Command Unknown
setstate MQTT2_78 2019-09-19 17:48:36 FallbackTopic cmnd/DVES_88DD49_fb/
setstate MQTT2_78 2019-09-19 17:48:36 GroupTopic sonoffs
setstate MQTT2_78 2019-09-19 18:13:53 Heap 15
...
...
setstate MQTT2_78 2019-09-19 17:48:36 LWT Online
setstate MQTT2_78 2019-09-19 18:13:53 LoadAvg 19
setstate MQTT2_78 2019-09-19 17:48:36 Module Sonoff 4CH
setstate MQTT2_78 2019-09-19 18:13:53 POWER1 off
setstate MQTT2_78 2019-09-19 18:13:53 POWER2 off
setstate MQTT2_78 2019-09-19 18:13:53 POWER3 off
setstate MQTT2_78 2019-09-19 18:13:53 POWER4 off
setstate MQTT2_78 2019-09-19 17:48:36 RestartReason Software/System restart
setstate MQTT2_78 2019-09-17 18:39:55 SaveData on
setstate MQTT2_78 2019-09-19 18:13:53 Sleep 50
setstate MQTT2_78 2019-09-19 18:13:53 SleepMode Dynamic
setstate MQTT2_78 2019-09-17 18:39:53 StateText1 off
setstate MQTT2_78 2019-09-17 18:39:54 StateText2 on
setstate MQTT2_78 2019-09-17 18:39:54 StateText3 toggle
setstate MQTT2_78 2019-09-17 18:39:54 StateText4 hold
setstate MQTT2_78 2019-09-19 18:13:53 Time 2019-09-19T17:13:54
setstate MQTT2_78 2019-09-19 18:13:53 Uptime 0T00:25:33
setstate MQTT2_78 2019-09-18 19:13:06 Vcc 3.226
setstate MQTT2_78 2019-09-19 17:48:36 Version 6.6.0(release-sonoff)
setstate MQTT2_78 2019-09-19 17:48:36 WebServerMode Admin
setstate MQTT2_78 2019-09-19 18:13:53 Wifi_AP 1
...
...
setstate MQTT2_78 2019-09-19 18:13:53 Wifi_Channel 6
setstate MQTT2_78 2019-09-19 18:13:53 Wifi_Downtime 0T00:00:13
setstate MQTT2_78 2019-09-19 18:13:53 Wifi_LinkCount 1
setstate MQTT2_78 2019-09-19 18:13:53 Wifi_RSSI 66
setstate MQTT2_78 2019-09-18 19:05:17 Wifi_SSID ...
setstate MQTT2_78 2019-09-19 18:13:53 Wifi_SSId ...


und das PWMR-Device so:

Code Auswählen Erweitern


defmod EG_WZ PWMR fh 0.85 wbw22_wz1 MQTT2_78:POWER2 eg_fenster_nord_mitte,eg_fenster_nord_rechts,eg_fenster_west,wz_terassentuer:.*open.*
attr EG_WZ autoCalcTemp 0
attr EG_WZ group Heizung_WZ
attr EG_WZ icon sani_floor_heating_neutral
attr EG_WZ room EZ_WZ_KUE,GoogleAssistant,Heizung,Heizung_EG

setstate EG_WZ Manual
setstate EG_WZ 2019-09-19 18:12:11 PWMOnTime 15:00
setstate EG_WZ 2019-09-19 18:12:11 PWMPulse 100
setstate EG_WZ 2019-09-19 18:04:18 actorState Online\
1:off\
2:off\
3:off\
4:off\
<br>\
<a href="http://192.168.178.78" target="_blank">192.168.178.78</a>
setstate EG_WZ 2019-03-27 18:47:48 desired-new 00
setstate EG_WZ 2019-09-19 17:02:48 desired-temp 26.0
setstate EG_WZ 2019-09-19 18:12:11 desired-temp-used 26.0
setstate EG_WZ 2019-09-19 18:12:12 energyused 111111111111111111111111111111
setstate EG_WZ 2019-09-19 18:12:12 energyusedp 100.0
setstate EG_WZ 2019-09-15 09:53:17 lastswitch 1568533997.15263
setstate EG_WZ 2019-03-19 19:14:58 manualTempDuration 0
setstate EG_WZ 2019-09-19 18:12:11 oldpulse 1
setstate EG_WZ 2019-09-19 18:10:47 state Manual
setstate EG_WZ 2019-09-19 18:12:11 temperature 21.48



Das Problem ist der 6. Parameter des PWMR im defmod, also das "MQTT2_78:POWER2". Das ist wahrscheinlich so nicht richtig, aber ich weiß auch nicht wie.(Würde dazu parallel mal im ensprechenden Unterforum beim Maintainer von PWMR nachfragen).
Bisher hatte ich ja jeden Kanal als einzelnes Device, das hat so geschalten, wie es sollte. Nun hat aber wahrscheinlich das PWMR ein Problem mit dem Reading actorState. Ich wollte zwar die 4 Kanäle in einem Device lassen, aber das scheint nicht aufzugehen.
Wie kann ich die 4 Kanäle des Sonoff "vereinzeln"?

Danke für Ideen.