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
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
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
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
Zum Zittern besteht keine Veranlassung ;D .
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
So, das erste Device ist umgestellt. Dazu habe ich folgendes getan:
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
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
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
:) 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 :) .
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.
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.
(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
attr MQTT2_milight_hub_1330194 readingList milight_hub_1330194:milight/LWT:.* { json2nameValue($EVENT) }
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
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.
Zitat von: Blauhorn am 18 September 2019, 10:33:36
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).
ZitatNoch 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
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?
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?
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?
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.
Nächste Sache: die mehrkanaligen Sonoffs.
Ich habe Schwierigkeiten, das PWMR-Device zu schalten. Hintergrund ist folgende Def.:
das Sonoff 4CH so:
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:
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.
Mobil+kurz: andere template-Alternative anwenden, "split".
Etwas ausführlichere Antwort:
Es gibt eventuell mehrere Möglichkeiten, das umzusetzen, was jeweils sinnvoll ist, ist auch abhängig vom "Abnehmer", hier also PWMR.
1. Die "simple" Variante ist die, das "split"-Template anzuwenden. Es gibt für mehrkanalige Aktoren in der Regel mind. 2 templates, eines als "Einheitsdevice" (unified), eines als "split"-Variante.
In der Regel ist das mit dem Split am einfachsten zu machen, da hat dann jeder Kanal ein "on"/"off", das jeweils im "state" stattfindet und die SetExtensions-Funktionen bietet.
Dass und welche Querbezüge existieren, wird über ein Reading und einen Comment jeweils in den einzelnen Devices vermerkt.
Würde sagen, das ist der Weg, der in der Regel zu empfehlen ist.
2. Du kannst aber auch erst "splitten" und dann das "unified"-Template nochmal auf den Hauptkanal anwenden, dann hast du auch dort alle Statusinformationen. Dann allerdings bitte noch je on und off für den Hauptkanal (POWER1) in die setList aufnehmen.
3. Bei allen mehrkanaligen Devices kann man einzelne Kanäle mit "ReadingsProxy" zu eigenen Geräten machen. Funktioniert auch im MQTT2_DEVICE-Kontext, allerdings finde ich das hier über den direkten Weg (1 oder 2) eleganter.
4. Wenn der "Abnehmer" (hier: PWMR) das erlaubt, "andere Befehle" wie on und off zuzulassen (aber keine Leerzeichen), kannst du für jeden Kanal auch separate Befehle in das "unified"-Device in die setList aufnehmen, also on1, off1, on2 usw..
(Vermutlich gibt es noch weitere Optionen, aber das sollten die wichtigsten sein und erst mal reichen ;D ).
Ich nehme mal an, dass du so langsam ein Gefühl dafür hast, wie das ganz konkret aussehen könnte und laß' dich da mal machen?
Sehr vielen Dank,
ich habe für die 4CH Sonoffs kein split-template gefunden, weswegen ich das nun von Hand gesplittet habe. In Anlehnung an das Split-template der Dual-Sonoffs habe ich dann jetzt ein template gebaut, das ich gerne im contribute-Zweig bereitstelle.
Vielen Dank nochmals.
Hallo, ich könnte auch etwas Umzugshilfe gebrauchen. Am Besten Schritt für Schritt. :)
Irgendwie haben die Beschreibungen die bisher gefunden habe irgendwo ein Detail, was nicht funktioniert....
Ich würde gerne den Weg zu MQTT2_CLIENT wählen.
define MQTT2 MQTT2_CLIENT 127.0.0.1:1883
set MQTT2 autocreate simple
ich habe dann eine Birne von ioDEV von MQTT auf MQTT2 gewechselt, die Birne lässt sich schalten und auch dimmen.
ABER mein Problem ist, dass ich keine Templates für die (Farb)Birne habe.
ABER der Zustand der Birne wird nicht mehr aktualisiert (restart von FHEM habe bisher nicht gemacht, wollte erst die config speichern, wenn der Umzug auf dem richtigen Weg ist...)
bei ioDEV MQTT2_DEVICE bekomme ich folgende Antwort: unknown IODev MQTT2_DEVICE specified
Nach etwas Warten wurde ein neues Device angelegt MQTT2_MQTT2
Hier sollte wohl das Template MQTT2_CLIENT_general_bridge angewandt werden, oder?
jetzt habe ich
MQTT2_GeneralBridge
und
MQTT2_MQTT2
nun hat sich auch die Birne verändert auf MQTT2_DEVICE, ABER attrTemplates fehlt mir bei der Birne ......
Hat sich überschnitten, schön, dass der Weg jetzt schon mal weiter ging:
Da es fertig war, nochmal der komplette Ablauf:
@Müller: Der WEg bei MQTT2_CLIENT ist der folgende:
- kommt bei autocreate simple (und aktivierter allg. autocreate-Instanz) irgendwas vom mosquitto her, landet das erst mal _alles_ in einem einzigen Device.
- Daher sollte man als erstes das template "MQTT2_CLIENT_general_bridge" anwenden. Das erstellt ein weiteres Device des Typs MQTT2_DEVICE, das einfach nur dafür sorgt, dass (hoffentlich) jeweils alles soweit vorsortiert wird, was offentsichtlich nicht zusammengehört.
- Dann sollten alle Messages, die vom zigbee2mqtt-Dienst her gesendet werden, wieder in einer Art Sammeldevice landen (wieder TYPE=MQTT2_DEVICE). Auf dieses wendest du dann das template für die zigbee2mqtt-Bridge an.
- Erst dann bekommst du ein Device (vom TYPE MQTT2_DEVICE, das sinnvoll mit einem template für farbige Birnen verwendet werden kann und sich auch steuern läßt.
Wenn du da jetzt ein Problem hast, solltest du eine RAW-Definition hier einstellen (von dem Device, das mit der passenden ID automatisch erstellt wurde, nachdem du die Lampe mit dem direkten publish aus dem anderen Thread geschaltet hast).
Hallo, danke für die schnelle Antwort.
ich habe mal als erstes auf MQTT2_MQTT2 das "attrTemplate Zigbee bridge" angewandt.
Jetzt tauchen langsam alle Lampen und Schalter im "room" MQTT2_Device auf (wenn sie AN / Aus geschaltet werden).
Ich habe auf die Osram Lampe das template "zigbee2mqtt_light_rgbw_hex" bzw. "zigbee2mqtt_light_rgbw_rgb" angewandt - beide funktionieren.
Vielleicht noch eine Anmerkung: Im Moment läuft bei mir
defmod MQTT2 MQTT2_CLIENT 127.0.0.1:1883
attr MQTT2 autocreate simple
attr MQTT2 room MQTT2_DEVICE
setstate MQTT2 opened
setstate MQTT2 2019-09-25 21:59:38 state opened
und
defmod MQTT MQTT localhost:1883
attr MQTT room XiaomiMQTTDevice,test
setstate MQTT opened
setstate MQTT 2019-09-26 08:40:15 connection active
setstate MQTT 2019-09-25 21:49:13 state opened
parallel. Nunja, ich werde meine Geräte auf den MQTT2-Client umziehen und MQTT dann löschen.
Meine MQTT2_GeneralBridge hat als STATE drei Fragezeichen, muß ich hier noch etwas einstellen?
defmod MQTT2_GeneralBridge MQTT2_DEVICE MQTT2_GeneralBridge
attr MQTT2_GeneralBridge IODev MQTT2
attr MQTT2_GeneralBridge autocreate 1
attr MQTT2_GeneralBridge bridgeRegexp (tele|cmnd)[/]([^/]+)[/].*:.* "$2"\
shellies[/]([^/]+)[/].*:.* "$1"\
(ESPClient_[^/]+)[/].*:.* "$1"
attr MQTT2_GeneralBridge comment Do not use very open bridgeRegexp expressions! This might lead to irritating results...
attr MQTT2_GeneralBridge model MQTT2_CLIENT_general_bridge
attr MQTT2_GeneralBridge room MQTT2_DEVICE
attr MQTT2_GeneralBridge setStateList on off
setstate MQTT2_GeneralBridge 2019-09-25 22:09:33 associatedWith MQTT2_MQTT2
DANKE für die Hilfe und Geduld
UND ich dachte schon alles ist gut......
Wenn ich versuche einen Schalter per webcmd zu schalten bekomme ich
Unknown argument on, choose one of attrTemplate:?,General_Info,MQTT2_CLIENT_general_bridge,tasmota_basic,tasmota_basic_state_power1,shelly1,eBus_daemon_splitter,zigbee2mqtt_bridge,zigbee2mqtt_light_dimmer,zigbee2mqtt_light_cct,zigbee2mqtt_light_rgb_hex,zigbee2mqtt_light_rgb_rgb,zigbee2mqtt_light_rgbw_hex,zigbee2mqtt_light_rgbw_rgb,zigbee2mqtt_light_rgbcct_hex,zigbee2mqtt_light_rgbcct_rgb,zigbee2mqtt_smokeDetector,zigbee2mqtt_hueMotionSensor,zigbee2mqtt_smart+plug,zigbee2mqtt_ContactSensor,zigbee2mqtt_TempHumHpaSensor,zigbee2mqtt_TempHumSensor,zigbee2mqtt_Human_Motion_Sensor,zigbee2mqtt_TempMotion_sensor,zigbee2mqtt_Motion_Sensor,zigbee2mqtt_Water_Leak_Sensor,zigbee2mqtt_Light_Switch,zigbee2mqtt_Wireless_Button,zigbee2mqtt_wireless_button_old,zigbee2mqtt_aqara_cube,esp_milight_hub_bridge,esp_milight_hub_remote_events_only
und nichts tut sich mehr
Moin,
schön, dass jetzt die Kette vollständig ist und funktioniert, wie sie soll :) .
Man kann die neue und die alte Implementierung parallel nutzen, das ist kein Problem, wenn man davon absieht, dass eben durch die autocreate-Mechanismen ggf. doppelt Geräte erstellt werden (als MQTT2_DEVICE).
Wenn du alles umgezogen hast, kannst du auch das Duo MQTT2_CLIENT+mosquitto noch durch den MQTT2_SERVER ersetzen (erfordert uU. etwas Nacharbeit bei den CID-Angaben bzw. diese wären evtl. zweckmäßig), auch das Device MQTT2_MQTT2 ist dann nicht mehr erforderlich. Dass das keinen aussagefähigen state hat, kannst du ignorieren, das ist nur ein Hilfsdevice zur Vorsortierung.
Was mich (und v.a. Blauhorn) noch interessiert: Gibt es irgendwelche relevanten Unterschiede in der Handhabung der Devices zwischen der XiaomiMQTTDevice-Fassung und der MQTT2_DEVICE-Version? Also Reading-Namen, setter usw.?
Anders gefragt: Ist es eine große Sache, den kompletten zigbee2mqtt-Zweig auf einen Rutsch umzustellen, wenn man die neuen Geräte benennt wie die alten?
(Ich vermute: nein, weil die JSON-Auspack-Ergebnisse dieselben sind...)
Ohne list kann ich nichts zu der Frage von 09:16 sagen...
Ich vermute, es gibt da keine setList?
Ja, setList ist das Problem gewesen. Arbeite ich gerade von Hand nach....
Bisher habe ich die Geräte aus autocreate genommen und angepasst. Ob ich durch IODEV umbenennen, es einfach umziehen kann muß ich noch probieren
Wieso von Hand?
Wenn die templates nicht funktionieren (ggf. wegen des CLIENT), hätte ich gerne Rückmeldung, ansonsten sollte es was passendes geben (oder die file müßte ergänzt werden ;) ).
templates für dimbare OsramBirne und dimmbare RGB Osram Birne gehen gut.
Template für osramSteckdose habe ich smart+plug benutzt, dass geht nicht
defmod MQTT2_zigbee_0x7cb03eaa0a0148a6 MQTT2_DEVICE zigbee_0x7cb03eaa0a0148a6
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 IODev MQTT2
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 alias brunnen123
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 eventMap { dev=>{ON=>'on',OFF=>'off'} }
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 model zigbee2mqtt_smart+plug
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 readingList zigbee2mqtt/0x7cb03eaa0a0148a6:.* { json2nameValue($EVENT) }\
zigbee2mqtt/0x7cb03eaa0a0148a6/set:.* set
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 room MQTT2_DEVICE
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 setList off zigbee2mqtt/0x7cb03eaa0a0148a6/set OFF\
on zigbee2mqtt/0x7cb03eaa0a0148a6/set ON
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 stateFormat click
setstate MQTT2_zigbee_0x7cb03eaa0a0148a6 click
setstate MQTT2_zigbee_0x7cb03eaa0a0148a6 2019-09-26 10:28:26 associatedWith MQTT2_MQTT2
setstate MQTT2_zigbee_0x7cb03eaa0a0148a6 2019-09-26 10:28:29 set OFF
setstate MQTT2_zigbee_0x7cb03eaa0a0148a6 2019-09-26 10:28:28 state off
das baugleiche Gerät (andere ID) mit funktionierenden Einstellungen:
defmod MQTT2_zigbee_0x7cb03eaa0a06c3d2 MQTT2_DEVICE zigbee_0x7cb03eaa0a06c3d2
attr MQTT2_zigbee_0x7cb03eaa0a06c3d2 IODev MQTT2
attr MQTT2_zigbee_0x7cb03eaa0a06c3d2 alias trocknerschalter
attr MQTT2_zigbee_0x7cb03eaa0a06c3d2 devStateIcon ON:message_socket@orange:Aus OFF:message_socket@gray:An
attr MQTT2_zigbee_0x7cb03eaa0a06c3d2 eventMap on:An off:Aus
attr MQTT2_zigbee_0x7cb03eaa0a06c3d2 readingList zigbee2mqtt/0x7cb03eaa0a06c3d2/set:.* { json2nameValue($EVENT) }\
zigbee2mqtt/0x7cb03eaa0a06c3d2:.* { json2nameValue($EVENT) }
attr MQTT2_zigbee_0x7cb03eaa0a06c3d2 room MQTT2_DEVICE
attr MQTT2_zigbee_0x7cb03eaa0a06c3d2 setList on:noArg zigbee2mqtt/0x7cb03eaa0a06c3d2/set {"state":"ON"}\
off:noArg zigbee2mqtt/0x7cb03eaa0a06c3d2/set {"state":"OFF"}
attr MQTT2_zigbee_0x7cb03eaa0a06c3d2 stateFormat state
attr MQTT2_zigbee_0x7cb03eaa0a06c3d2 webCmd :
setstate MQTT2_zigbee_0x7cb03eaa0a06c3d2 OFF
setstate MQTT2_zigbee_0x7cb03eaa0a06c3d2 2019-09-26 08:27:05 associatedWith MQTT2_MQTT2
setstate MQTT2_zigbee_0x7cb03eaa0a06c3d2 2019-09-26 10:35:10 linkquality 47
setstate MQTT2_zigbee_0x7cb03eaa0a06c3d2 2019-09-26 10:35:10 state OFF
OK. Kannst du sagen, was geändert werden müßte?
(Bitte ggf. ein list vom alten device liefern)
Hallo habe nun die Dose zum laufen bekommen:
defmod MQTT2_zigbee_0x7cb03eaa0a0148a6 MQTT2_DEVICE zigbee_0x7cb03eaa0a0148a6
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 IODev MQTT2
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 alias brunnen123
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 devStateIcon ON:message_socket@orange:Aus OFF:message_socket@gray:An
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 eventMap on:An off:Aus
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 readingList zigbee2mqtt/0x7cb03eaa0a0148a6/set:.* { json2nameValue($EVENT) }\
zigbee2mqtt/0x7cb03eaa0a0148a6:.* { json2nameValue($EVENT) }
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 room MQTT2_DEVICE
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 setList off:noArg zigbee2mqtt/0x7cb03eaa0a0148a6/set {"state":"OFF"}\
on:noArg zigbee2mqtt/0x7cb03eaa0a0148a6/set {"state":"ON"}
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 stateFormat state
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 webCmd An:Aus
setstate MQTT2_zigbee_0x7cb03eaa0a0148a6 ON
setstate MQTT2_zigbee_0x7cb03eaa0a0148a6 2019-09-26 10:38:19 associatedWith MQTT2_MQTT2
setstate MQTT2_zigbee_0x7cb03eaa0a0148a6 2019-09-26 10:39:29 linkquality 0
setstate MQTT2_zigbee_0x7cb03eaa0a0148a6 2019-09-26 10:32:52 set {"state":"OFF"}
setstate MQTT2_zigbee_0x7cb03eaa0a0148a6 2019-09-26 10:39:29 state ON
Ich denke die Einstellungen in der setlist brauchen die Klammer
off:noArg zigbee2mqtt/0x7cb03eaa0a0148a6/set {"state":"OFF"}
Hmm, das mit dem JSON sollte dann aber doch eigentlich bei allen zigbee2mqtt-Devices so sein; komisch, dass das mit dem plug+ so klappen soll... da kommt dann ein neues Template, kannst du mir die Type mitteilen, dann kommt das in die desc rein?
Was bei dir evtl. noch geändert werden sollte: auf den "set"-Zweig sollte die readingList _nicht_ hören (das wäre dann spezielle Nacharbeit, geht vermutlich bei CLIENT nicht anders, solange man autocreate nicht bei dem Device abstellt).
du meinst bei readinglist
zigbee2mqtt/0x7cb03eaa0a06c3d2/set:.* { json2nameValue($EVENT) }
zigbee2mqtt/0x7cb03eaa0a06c3d2:.* { json2nameValue($EVENT) }
die obere Zeile löschen? (Bei aktiven Autocreate kommt die wieder.)
Hängt dies mit der Rückmeldung der Geräte zusammen?
Bei MQTT kommte ich eine Lampe die nicht am Strom hängt nicht schalten, nun bei MQTT2_CLIENT ändert sich der Status. D.h. ich habe keine Rückmeldung mehr, ob die Aktion tatsächlich erfolgt ist?
Genau, löschen, autocreate (es reicht am jeweiligen Device) ausschalten...
Dann sollte auch wieder der Status nur dann aktualisiert werden, wenn es vom zigbee2mqtt-Dienst bestätigt wird.
Auch nach einem Neustart von FHEM funktioniert dies mit dem State noch nicht.
Bei den Readings ändert sich das state in Abhängigkeit vom Schaltbefehl. Bei den Internals ändert sich STATE gar nix (auch wenn die Lampe etc geschalten wird)
Hmm, ohne den genauen Ablauf auch auf der MQTT-Seite ist das etwas Gestochere im Nebel.
Würde mal auf
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 eventMap on:An off:Ausals Verursacher tippen. Da gibt es kein ON:An OFF:Aus, die Rückmeldung ist aber uppercase, denke ich.
Generell: Änderungen der Internals werden eventuell erst sichtbar nach einem refresh der Browser-Seite.
Um Mißverständnisse zu vermeiden hier nochmal die aktuellen Settings
defmod MQTT2_zigbee_0x7cb03eaa0a0148a6 MQTT2_DEVICE zigbee_0x7cb03eaa0a0148a6
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 IODev MQTT2
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 alias Brunnen
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 devStateIcon ON:sani_water_tap@blue:OFF OFF:sani_water_tap@gray:ON
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 group HofGarten
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 readingList zigbee2mqtt/0x7cb03eaa0a0148a6:.* { json2nameValue($EVENT) }
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 room Baßler,Baßler_komplett,MQTT2_DEVICE
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 setList OFF:noArg zigbee2mqtt/0x7cb03eaa0a0148a6/set {"state":"OFF"}\
ON:noArg zigbee2mqtt/0x7cb03eaa0a0148a6/set {"state":"ON"}
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 webCmd :
setstate MQTT2_zigbee_0x7cb03eaa0a0148a6 OFF
setstate MQTT2_zigbee_0x7cb03eaa0a0148a6 2019-09-26 10:38:19 associatedWith MQTT2_MQTT2
setstate MQTT2_zigbee_0x7cb03eaa0a0148a6 2019-09-26 13:12:48 linkquality 0
setstate MQTT2_zigbee_0x7cb03eaa0a0148a6 2019-09-26 10:32:52 set {"state":"OFF"}
setstate MQTT2_zigbee_0x7cb03eaa0a0148a6 2019-09-26 13:12:59 state OFF
Refresh des Browser hilft definitiv ;D
eventMAP ist nicht definiert
Beide, state (Readings) und STATE (Internals), ändern sich beim Schalten, auch wenn die Dose nicht am Netz ist
Zitat von: Beta-User am 26 September 2019, 09:18:52
Was mich (und v.a. Blauhorn) noch interessiert: Gibt es irgendwelche relevanten Unterschiede in der Handhabung der Devices zwischen der XiaomiMQTTDevice-Fassung und der MQTT2_DEVICE-Version? Also Reading-Namen, setter usw.?
Anders gefragt: Ist es eine große Sache, den kompletten zigbee2mqtt-Zweig auf einen Rutsch umzustellen, wenn man die neuen Geräte benennt wie die alten?
(Ich vermute: nein, weil die JSON-Auspack-Ergebnisse dieselben sind...)
Ich habe den zigbee2mqtt-Zweig seit 3 Tagen parallel laufen, über MQTT2_CLIENT->mosquitto als IODevice.
Die parallelen Definitionen sehen so aus:
Das autocreated para-MQTT2-DEVICE:
define MQTT2_zigbee_IKEA_L1 MQTT2_DEVICE zigbee_IKEA_L1
attr MQTT2_zigbee_IKEA_L1 IODev MQTT2_Client
attr MQTT2_zigbee_IKEA_L1 devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr MQTT2_zigbee_IKEA_L1 icon light_control
attr MQTT2_zigbee_IKEA_L1 model zigbee2mqtt_light_dimmer
attr MQTT2_zigbee_IKEA_L1 readingList zigbee2mqtt/IKEA_L1:.* { json2nameValue($EVENT) }
attr MQTT2_zigbee_IKEA_L1 room MQTT2_DEVICE
attr MQTT2_zigbee_IKEA_L1 setList on:noArg zigbee2mqtt/IKEA_L1/set {"state":"ON"}\\n off:noArg zigbee2mqtt/IKEA_L1/set {"state":"OFF"}\\n brightness:colorpicker,BRI,0,5,255 zigbee2mqtt/IKEA_L1/set {"state":"on","$EVTPART0":"$EVTPART1"}
attr MQTT2_zigbee_IKEA_L1 setStateList on off
attr MQTT2_zigbee_IKEA_L1 webCmd toggle:on:off:brightness
und das ältere XiaomiMQTTDevice:
define IKEA_L1 XiaomiMQTTDevice LED1623G12 0x000b57fffe2b606f IKEA_L1
attr IKEA_L1 userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
attr IKEA_L1 IODev mosquitto_banana
attr IKEA_L1 devStateIcon on:rc_GREEN:off off:rc_RED:on
attr IKEA_L1 eventMap ON:on OFF:off ON:Ein OFF:Aus
attr IKEA_L1 lightSceneParamsToSave brightness
attr IKEA_L1 room GoogleAssistant,XiaomiMQTTDevice
attr IKEA_L1 webCmd brightness: state
attr IKEA_L1 widgetOverride state:uzsuToggle,OFF,ON, brightness:slider,0,1,255
Beide Geräte sind online. Bei den Sensoren sind bei den Parallel-Devices alle Readings gleich, senden ja auch die gleiche payload per JSON-String, so dass einer Umbenennungsaktion nichts mehr im Wege stünde.
Ich hoffe, dass die associatedDevices hier nicht automatisch reagieren, z.B. wenn LightScenes betroffen sind. Dann wäre das Verfahren einfach:
- alle XiaomiMQTTDevices umbenennen
rename TYPE=XiaomiMQTTDevice $name $name."_old"
rename MQTT2_zigbee_.*.....hier verlässt mich gerade mein Perl-Wissen: Name des MQTT2-Devices ohne das führende "MQTT2_zigbee_"
Das kann ich heute abend mal probieren.
Zitat von: Müller am 26 September 2019, 13:19:16
Beide, state (Readings) und STATE (Internals), ändern sich beim Schalten, auch wenn die Dose nicht am Netz ist
Das ist soweit logisch, du könntest noch über ein "setStateList on off" nachdenken ;) . Dann mal nachsehen, was wann passiert, zuletzt ergänzen mit einem eventMap für ON/OFF.
Zitat von: Blauhorn am 26 September 2019, 13:27:46
Ich hoffe, dass die associatedDevices hier nicht automatisch reagieren, z.B. wenn LightScenes betroffen sind. Dann wäre das Verfahren einfach:
[...]
:) Schön, dass du jetzt so schnell vorangekommen bist.
Was das weitere Vorgehen angeht:
- vorab mit "list -r TYPE=XiaomiMQTTDevice" alle vorhandenen Devices anzeigen lassen, das RAW wegsichern (dann kannst du das notfalls reaktivieren).
- Dann alle löschen: "delete TYPE=XiaomiMQTTDevice"
- zuletzt die neuen so umbenennen, dass sie die alten ersetzen, vermutlich lohnt da kein Automatismus. Dabei werden die Umbenennungen in "associatedWith" automatisch nachgeführt, das hat aber mit den "alten" Devices dann nichts mehr zu tun, das ist nur ein "special feature", das Rudi da in dieses Reading eingebaut hat ;) . Auch automatisch geschaltet wird da nichts, das dient nur der Erhaltung der Sichtbarkeit, was ggf. zu welcher Hardware gehört.
Ich habe setStateList und eventmap ergänzt
defmod MQTT2_zigbee_0x7cb03eaa0a0148a6 MQTT2_DEVICE zigbee_0x7cb03eaa0a0148a6
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 IODev MQTT2
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 alias Brunnen
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 devStateIcon ON:sani_water_tap@blue:OFF OFF:sani_water_tap@gray:ON
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 eventMap on off
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 group HofGarten
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 readingList zigbee2mqtt/0x7cb03eaa0a0148a6:.* { json2nameValue($EVENT) }
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 room Baßler,Baßler_komplett,MQTT2_DEVICE
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 setList OFF:noArg zigbee2mqtt/0x7cb03eaa0a0148a6/set {"state":"OFF"}\
ON:noArg zigbee2mqtt/0x7cb03eaa0a0148a6/set {"state":"ON"}
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 setStateList on off
attr MQTT2_zigbee_0x7cb03eaa0a0148a6 webCmd :
setstate MQTT2_zigbee_0x7cb03eaa0a0148a6 OFF
setstate MQTT2_zigbee_0x7cb03eaa0a0148a6 2019-09-26 14:51:42 OFF set
setstate MQTT2_zigbee_0x7cb03eaa0a0148a6 2019-09-26 14:52:02 ON set
setstate MQTT2_zigbee_0x7cb03eaa0a0148a6 2019-09-26 10:38:19 associatedWith MQTT2_MQTT2
setstate MQTT2_zigbee_0x7cb03eaa0a0148a6 2019-09-26 14:51:43 linkquality 44
setstate MQTT2_zigbee_0x7cb03eaa0a0148a6 2019-09-26 10:32:52 set {"state":"OFF"}
setstate MQTT2_zigbee_0x7cb03eaa0a0148a6 2019-09-26 14:51:43 state OFF
Das scheint nun zu funktionieren - Vielen Dank
mit eventMap war "ON:on OFF:off" gemeint, es sollte schon was "gemappt" werden ;D .
So, in Summe braucht es zwar doch einige Nacharbeit aber man kann es doch alles stückweise machen. (Ich meine den zigbee-Zweig).
Am blödesten waren dann eben doch die LightScene-Devices. Die passen nämlich auf, ob irgendwo ein Gerät nicht mehr da ist, und ändern schwuppdiwupp ihre eigene Definition. Der kurze Moment des Fehlens der Lampe reicht denen aus.
Muss also darin alle Lampen neu eintragen und auch die Scenes neu beschalten. Das war jetzt glücklicherweise nicht so viel Zeug drin.
Die PWMRs scheinen das kurze Fehlen eines verbundenen Devices zu tolerieren.
Hallo Blauhorn,
ich habe beim mitlesen gesehen, das Du "2 Tradfri Remotecontrol" eingebunden hast. Ich habe bereits versucht die Remotecontrol einzubinden, bin jedoch noch nicht weiter gekommen. Zigbee und MQTT2_Fhem_Server mit zigbee2mqtt ist für mich neu. Die Remotecontrol ist momentan mein einziges Device.
Das Device hat sich bereits wie folgt eingetragen, jedoch komme ich einfach nicht weiter die Definition zu erweitern.
Internals:
CID zigbee_0x90fd9ffffee7e93a
DEF zigbee_0x90fd9ffffee7e93a
DEVICETOPIC MQTT2_zigbee_0x90fd9ffffee7e93a
FUUID 5d764aee-f33f-81e9-2602-d15adc73613be593
IODev MQTT2_FHEM_Server
NAME MQTT2_zigbee_0x90fd9ffffee7e93a
NR 350
STATE ???
TYPE MQTT2_DEVICE
READINGS:
2019-09-09 14:52:00 associatedWith MQTT2_zigbee_pi
2019-09-23 01:19:39 battery 87
2019-09-23 01:19:39 linkquality 68
Attributes:
IODev MQTT2_FHEM_Server
alias MQTT2_zigbee_0x90fd9ffffee7e93a
comment Ikea Tradfri Remote Control
readingList zigbee2mqtt/0x90fd9ffffee7e93a:.* { json2nameValue($EVENT) }
room MQTT2_DEVICE
verbose 5
Internals:
CID zigbee_pi
DEF zigbee_pi
DEVICETOPIC MQTT2_zigbee_pi
FUUID 5d763393-f33f-81e9-b187-fa1c3d1eae39d1bd
IODev MQTT2_FHEM_Server
NAME MQTT2_zigbee_pi
NR 349
STATE online
TYPE MQTT2_DEVICE
READINGS:
2019-09-23 01:19:40 commit ac3b924
2019-09-12 14:28:55 devices {"type":"devices","message":[{"ieeeAddr":"0x00124b0018e1e960","type":"Coordinator"},{"ieeeAddr":"0x90fd9ffffee7e93a","type":"EndDevice","model":"E1524","friendly_name":"0x90fd9ffffee7e93a","nwkAddr":13378,"manufId":4476,"manufName":"IKEA of Sweden","powerSource":"Battery","modelId":"TRADFRI remote control","hwVersion":1,"swBuildId":"1.2.214","dateCode":"20170302"}]}
2019-09-12 16:16:22 log {"type":"entity_not_found","message":"bridge/group"}
2019-09-23 01:19:40 log_level info
2019-09-23 01:19:40 permit_join true
2019-09-12 14:31:57 raw {"nodes":[{"ieeeAddr":"0x00124b0018e1e960","friendlyName":"0x00124b0018e1e960","type":"Coordinator","nwkAddr":0,"status":"online","scanfailed":["lqi"]},{"ieeeAddr":"0x90fd9ffffee7e93a","friendlyName":"0x90fd9ffffee7e93a","type":"EndDevice","nwkAddr":13378,"manufName":"IKEA of Sweden","modelId":"TRADFRI remote control","status":"offline","scanfailed":[]}],"links":[]}
2019-09-23 01:19:39 state online
2019-09-23 01:19:40 version 1.5.1
2019-09-12 17:38:16 x_group_add_group set RemoteControl
2019-09-12 17:40:54 x_group_add_to set RemoteControl 0x90fd9ffffee7e93a
2019-09-12 17:35:27 x_group_rm_group set 'RemoteControl'
Attributes:
IODev MQTT2_FHEM_Server
alias MQTT2_zigbee_pi
autocreate 1
bridgeRegexp zigbee2mqtt/([A-Za-z0-9._]*)[/]?.*:.* "zigbee_$1"
getList devicelist:noArg log zigbee2mqtt/bridge/config/devices
networkmap_raw:noArg raw zigbee2mqtt/bridge/networkmap raw
networkmap_graphviz:noArg graphviz zigbee2mqtt/bridge/networkmap graphviz
model L_01_zigbee2mqtt_bridge
readingList zigbee2mqtt/bridge/state:.* state
zigbee2mqtt/bridge/config/devices:.* {}
zigbee2mqtt/bridge/config/log_level:.* log_level
zigbee2mqtt/bridge/config/permit_join:.* permit_join
zigbee2mqtt/bridge/config/rename:.* { json2nameValue($EVENT, 'rename_') }
zigbee2mqtt/bridge/log:.*\"type\".\"devices\".\"message\".* devices
zigbee2mqtt/bridge/log:.* log
zigbee2mqtt/bridge/networkmap:.* {}
zigbee2mqtt/bridge/networkmap/graphviz:.* graphviz
zigbee2mqtt/bridge/networkmap/raw:.* raw
zigbee2mqtt/bridge/config:.* { json2nameValue($EVENT) }
room MQTT
setList log_level:debug,info,warn,error zigbee2mqtt/bridge/config/log_level $EVTPART1
permit_join:true,false zigbee2mqtt/bridge/config/permit_join $EVTPART1
remove:textField zigbee2mqtt/bridge/config/remove $EVTPART1
y_device_setting:textField zigbee2mqtt/$EVTPART1/set {"$EVTPART2": "$EVTPART3"}
x_bind:textField zigbee2mqtt/bridge/bind/$EVTPART1 $EVTPART2
x_bind_unbind:textField zigbee2mqtt/bridge/unbind/$EVTPART1 $EVTPART2
x_device_options:textField zigbee2mqtt/bridge/config/device_options {"friendly_name":"$EVTPART1",""options": {"$EVTPART2": "$EVTPART3"}}
x_group_add_to:textField zigbee2mqtt/bridge/group/$EVTPART1/add $EVTPART2
x_group_rm_from:textField zigbee2mqtt/bridge/group/$EVTPART1/remove $EVTPART2
x_group_rm_from_all:textField zigbee2mqtt/bridge/group/$EVTPART1/remove_all $EVTPART2
x_group_add_group:textField zigbee2mqtt/bridge/config/add_group $EVTPART1
x_group_rm_group:textField zigbee2mqtt/bridge/config/remove_group $EVTPART1
z_elapsed:textField zigbee2mqtt/bridge/config/elapsed $EVTPART1
z_last_seen:textField zigbee2mqtt/bridge/config/last_seen $EVTPART1
z_ban:textField zigbee2mqtt/bridge/config/ban $EVTPART1
z_rename:textField zigbee2mqtt/bridge/config/rename {"old":"$EVTPART1","new":"$EVTPART2"}
z_reset_CC:noArg zigbee2mqtt/bridge/config/reset
setStateList on off
verbose 5
Internals:
DEF 1883 global
FD 33
FUUID 5d751c78-f33f-81e9-291a-1d62334721ed96af
NAME MQTT2_FHEM_Server
NR 348
PORT 1883
STATE Initialized
TYPE MQTT2_SERVER
READINGS:
2019-09-23 01:19:40 RETAIN {"zigbee2mqtt/bridge/config":"{\u0022version\u0022:\u00221.5.1\u0022,\u0022commit\u0022:\u0022ac3b924\u0022,\u0022log_level\u0022:\u0022info\u0022,\u0022permit_join\u0022:true}","zigbee2mqtt/bridge/state":"online"}
2019-09-27 12:46:16 nrclients 0
2019-09-27 12:46:16 state Initialized
clients:
retain:
zigbee2mqtt/bridge/config:
ts 1569581178.25234
val {"version":"1.5.1","commit":"ac3b924","log_level":"info","permit_join":true}
zigbee2mqtt/bridge/state:
ts 1569581178.25234
val online
Attributes:
alias MQTT2_FHEM_Server
autocreate simple
room MQTT
verbose 5
Gruß
Christian
Hallo Christian, also ich habe die rc noch nicht wirklich im Einsatz.
Sie ist als Device angelegt, und ich hatte das attrtemplate zigbee2mqtt_Wireless_Button draufgelegt.
Wenn ich jetzt Tasten drücke, werden alle Tasten aufd em Reading action erkannt, auch hold und release und so.
Zitat von: Blauhorn am 28 September 2019, 11:10:29
Hallo Christian, also ich habe die rc noch nicht wirklich im Einsatz.
Sie ist als Device angelegt, und ich hatte das attrtemplate zigbee2mqtt_Wireless_Button draufgelegt.
Wenn ich jetzt Tasten drücke, werden alle Tasten aufd em Reading action erkannt, auch hold und release und so.
Danke,das probiere ich dann mal. Bie mir wird nur Batterie und Signalqualität angezeigt.
Gruß Christian
Hmm, das template ändert aber nichts wesentliches an dem, was via MQTT kommt. Sieht mir eher danach aus, als wäre die nicht mehr angelernt?
Hallo nochmal.
Das mit den Templates hat wie bereits angedeutet nicht geklappt.
Durch das pairen wurde bei mir nur Battery und Link Qualität angelernt. Das Device wurde ebenfalls automatisch erzeugt, wodurch ich denke, dass die MQTT2 Konfiguration in FHEM funktionieren sollte.
Eventuell mache ich ja beim pairen etwas falsch?
Hat jemand eine funktionierende Remote Control Konfiguration, die ich eventuell in meine zigbee2mqtt Installation herein Kopieren kann. Bisher ist das ja mein einziges Device und ich würde den Weg dann mal testen.
Gruß Christian
Gesendet von meinem SM-G930F mit Tapatalk
Wenn du updates zu zweien der Informationen/Readings hast, die die FB sendet, ist es weder FHEM noch die Konfiguration, die verbogen ist.
Sofern es also kein weiteres MQTT2_DEVICE gibt, das die fehlenden Infos abgreift, darst du davon ausgehen, dass das Ding nichts sendet bzw. zigbee2mqtt nichts an den Server weitergibt. Der Verdacht liegt nahe, dass das Teil entweder schlicht kaputt ist oder einfach an ein Leuchtmittel angelernt (dann sendet die FB nur noch dahin, afaik).
Kannst du die FB nochmal resetten?
Hallo,
ich habe 2 Ikea Tradfri Fernbedienungen ( Modell E1524/E1810) im Einsatz, welche vorzüglich mit Zigbee2Mqtt funktionieren. Wichtig bei der ganzen Geschichte ist das der Stick mit der neuesten Firmware (Juni2019) geflasht ist. mit einer älteren Firmware hatte ich auch das Problem, das nur Battery und Link Quality angelegt wurde. Es gibt in der Zigbee2Mqtt Geräteliste auch irgendwo einen entsprechenden Issue Eintrag, ich finde ihn im Moment aber nicht.
Ich hänge mal ein List vom Stick (Coordinator)
Internals:
CID mqttjs_8e63835e
DEF mqttjs_8e63835e
DEVICETOPIC Zigbee2MQTT
FUUID 5d123bdc-f33f-0bdc-55b1-e3103e529cd81380
IODev MQTT2_Server_FHEM
LASTInputDev MQTT2_Server_FHEM
MQTT2_Server_FHEM_MSGCNT 5
MQTT2_Server_FHEM_TIME 2019-09-26 18:08:13
MSGCNT 5
NAME Zigbee2MQTT
NR 15
STATE online
TYPE MQTT2_DEVICE
READINGS:
2019-09-01 19:47:33 commit 927c4db
2019-09-01 19:47:33 [color=red]coordinator 20190608[/color]
2019-09-26 18:08:13 devices {"type":"devices","message":[{"ieeeAddr":"0x00124b000766d962","type":"Coordinator"},{"ieeeAddr":"0x90fd9ffffe7fd13c","type":"Router","model":"LED1536G5","friendly_name":"0x90fd9ffffe7fd13c","nwkAddr":63264,"manufId":4476,"manufName":"IKEA of Sweden","powerSource":"Mains (single phase)","modelId":"TRADFRI bulb E14 WS opal 400lm","hwVersion":1,"swBuildId":"1.2.217","dateCode":"20170331"},{"ieeeAddr":"0x90fd9ffffe16b6d7","type":"EndDevice","model":"E1524","friendly_name":"0x90fd9ffffe16b6d7","nwkAddr":25264,"manufId":4476,"manufName":"IKEA of Sweden","powerSource":"Battery","modelId":"TRADFRI remote control","hwVersion":1,"swBuildId":"1.2.214","dateCode":"20170302"},{"ieeeAddr":"0x000d6ffffe429408","type":"EndDevice","model":"E1524","friendly_name":"0x000d6ffffe429408","nwkAddr":24968,"manufId":4476,"manufName":"IKEA of Sweden","powerSource":"Battery","modelId":"TRADFRI remote control","hwVersion":1,"swBuildId":"1.2.223","dateCode":"20190211"},{"ieeeAddr":"0x000d6ffffe0b416a","type":"EndDevice","model":"E1525","friendly_name":"0x000d6ffffe0b416a","nwkAddr":60452,"manufId":4476,"manufName":"IKEA of Sweden","powerSource":"Battery","modelId":"TRADFRI motion sensor","hwVersion":1,"swBuildId":"2.0.022","dateCode":"20190308"}]}
2019-07-01 16:12:33 graphviz digraph G {
node[shape=record];
"0x00124b0018ed1a21" [style="bold", label="{0x00124b0018ed1a21|Coordinator|No model information available|online}"];
"0x00124b0018ed1a21" -> "0x90fd9ffffe7fd13c" [label="119"]
"0x90fd9ffffe7fd13c" [style="rounded", label="{0x90fd9ffffe7fd13c|Router|IKEA TRADFRI LED bulb E12/E14 400 lumen, dimmable, white spectrum, opal white (LED1536G5)|offline}"];
"0x90fd9ffffe7fd13c" -> "0x00124b0018ed1a21" [label="67"]
"0x90fd9ffffe16b6d7" [style="rounded, dashed", label="{0x90fd9ffffe16b6d7|EndDevice|IKEA TRADFRI remote control (E1524)|online}"];
"0x90fd9ffffe16b6d7" -> "0x00124b0018ed1a21" [label="55"]
}
2019-09-26 18:08:13 log {"type":"devices","message":[{"ieeeAddr":"0x00124b000766d962","type":"Coordinator"},{"ieeeAddr":"0x90fd9ffffe7fd13c","type":"Router","model":"LED1536G5","friendly_name":"0x90fd9ffffe7fd13c","nwkAddr":63264,"manufId":4476,"manufName":"IKEA of Sweden","powerSource":"Mains (single phase)","modelId":"TRADFRI bulb E14 WS opal 400lm","hwVersion":1,"swBuildId":"1.2.217","dateCode":"20170331"},{"ieeeAddr":"0x90fd9ffffe16b6d7","type":"EndDevice","model":"E1524","friendly_name":"0x90fd9ffffe16b6d7","nwkAddr":25264,"manufId":4476,"manufName":"IKEA of Sweden","powerSource":"Battery","modelId":"TRADFRI remote control","hwVersion":1,"swBuildId":"1.2.214","dateCode":"20170302"},{"ieeeAddr":"0x000d6ffffe429408","type":"EndDevice","model":"E1524","friendly_name":"0x000d6ffffe429408","nwkAddr":24968,"manufId":4476,"manufName":"IKEA of Sweden","powerSource":"Battery","modelId":"TRADFRI remote control","hwVersion":1,"swBuildId":"1.2.223","dateCode":"20190211"},{"ieeeAddr":"0x000d6ffffe0b416a","type":"EndDevice","model":"E1525","friendly_name":"0x000d6ffffe0b416a","nwkAddr":60452,"manufId":4476,"manufName":"IKEA of Sweden","powerSource":"Battery","modelId":"TRADFRI motion sensor","hwVersion":1,"swBuildId":"2.0.022","dateCode":"20190308"}]}
2019-09-01 19:47:33 log_level info
2019-09-01 19:47:33 permit_join false
2019-07-01 16:12:16 raw [{"ieeeAddr":"0xd0cf5efffe43215c","nwkAddr":40720,"lqi":0,"parent":"0x00124b0018ed1a21","status":"offline"},{"ieeeAddr":"0x90fd9ffffe7fd13c","nwkAddr":31592,"lqi":65,"parent":"0x00124b0018ed1a21","status":"offline"},{"ieeeAddr":"0x90fd9ffffe16b6d7","nwkAddr":55401,"lqi":55,"parent":"0x00124b0018ed1a21","status":"online"},{"ieeeAddr":"0x00124b0018ed1a21","nwkAddr":0,"lqi":119,"parent":"0x90fd9ffffe7fd13c","status":"online"}]
2019-06-25 17:45:35 remove set 0x90fd9ffffe7fd13c
2019-09-01 19:47:05 state online
2019-09-01 19:47:33 version 1.4.0
Attributes:
IODev MQTT2_Server_FHEM
bridgeRegexp zigbee2mqtt/([A-Za-z0-9._]*)[/]?.*:.* "zigbee_$1"
getList devicelist:noArg log zigbee2mqtt/bridge/config/devices
networkmap_raw:noArg raw zigbee2mqtt/bridge/networkmap raw
networkmap_graphviz:noArg graphviz zigbee2mqtt/bridge/networkmap graphviz
model L_01_zigbee2mqtt_bridge
readingList zigbee2mqtt/bridge/state:.* state
zigbee2mqtt/bridge/config/devices:.* {}
zigbee2mqtt/bridge/config/log_level:.* log_level
zigbee2mqtt/bridge/config/permit_join:.* permit_join
zigbee2mqtt/bridge/config/rename:.* { json2nameValue($EVENT, 'rename_') }
zigbee2mqtt/bridge/log:.*\"type\".\"devices\".\"message\".* devices
zigbee2mqtt/bridge/log:.* log
zigbee2mqtt/bridge/networkmap:.* {}
zigbee2mqtt/bridge/networkmap/graphviz:.* graphviz
zigbee2mqtt/bridge/networkmap/raw:.* raw
zigbee2mqtt/bridge/config:.* { json2nameValue($EVENT) }
room Geräte
setList log_level:debug,info,warn,error zigbee2mqtt/bridge/config/log_level $EVTPART1
permit_join:true,false zigbee2mqtt/bridge/config/permit_join $EVTPART1
remove:textField zigbee2mqtt/bridge/config/remove $EVTPART1
y_device_setting:textField zigbee2mqtt/$EVTPART1/set {"$EVTPART2": "$EVTPART3"}
x_bind:textField zigbee2mqtt/bridge/bind/$EVTPART1 $EVTPART2
x_bind_unbind:textField zigbee2mqtt/bridge/unbind/$EVTPART1 $EVTPART2
x_device_options:textField zigbee2mqtt/bridge/config/device_options {"friendly_name":"$EVTPART1",""options": {"$EVTPART2": "$EVTPART3"}}
x_group_add_to:textField zigbee2mqtt/bridge/group/$EVTPART1/add $EVTPART2
x_group_rm_from:textField zigbee2mqtt/bridge/group/$EVTPART1/remove $EVTPART2
x_group_rm_from_all:textField zigbee2mqtt/bridge/group/$EVTPART1/remove_all $EVTPART2
x_group_add_group:textField zigbee2mqtt/bridge/config/add_group $EVTPART1
x_group_rm_group:textField zigbee2mqtt/bridge/config/remove_group $EVTPART1
z_elapsed:textField zigbee2mqtt/bridge/config/elapsed $EVTPART1
z_last_seen:textField zigbee2mqtt/bridge/config/last_seen $EVTPART1
z_ban:textField zigbee2mqtt/bridge/config/ban $EVTPART1
z_rename:textField zigbee2mqtt/bridge/config/rename {"old":"$EVTPART1","new":"$EVTPART2"}
z_reset_CC:noArg zigbee2mqtt/bridge/config/reset
setStateList on off
wichtig ist der Eintrag beim Reading Coordinator.
Der Vollständigkeit halber noch das List einer Fernbedienung
Internals:
CID zigbee_0x90fd9ffffe16b6d7
DEF zigbee_0x90fd9ffffe16b6d7
DEVICETOPIC MQTT2_zigbee_0x90fd9ffffe16b6d7
FUUID 5d1ba23d-f33f-0bdc-fbeb-2a898e7c3f1a262d
IODev MQTT2_Server_FHEM
LASTInputDev MQTT2_Server_FHEM
MQTT2_Server_FHEM_MSGCNT 79
MQTT2_Server_FHEM_TIME 2019-10-06 21:45:15
MSGCNT 79
NAME MQTT2_zigbee_0x90fd9ffffe16b6d7
NR 25
STATE toggle
TYPE MQTT2_DEVICE
READINGS:
2019-09-26 18:05:48 action toggle
2019-07-02 20:28:13 associatedWith Zigbee2MQTT
2019-10-06 21:45:15 battery 60
2019-10-06 21:45:15 linkquality 76
Attributes:
IODev MQTT2_Server_FHEM
alias TRADFRI_RC1
devStateIcon .*:noIcon
imageLink /fhem/deviceimages/mqtt2/E1524.jpg
model L_12_Wireless_Button
readingList zigbee2mqtt/0x90fd9ffffe16b6d7:.* { json2nameValue($EVENT) }
room MQTT2_DEVICE
stateFormat action
unter action steht dann jeweils was gedrückt wurde: hier die mittlere Taste (toggle)
Ich hoffe das hilft weiter.
Gruß Thomas
Zitat von: Beta-User am 07 Oktober 2019, 12:21:27
Der Verdacht liegt nahe, dass das Teil entweder schlicht kaputt ist oder einfach an ein Leuchtmittel angelernt (dann sendet die FB nur noch dahin, afaik).
Aber dann würde sie ja auch keine battery- und linkquality-Werte zum zigbee2mqtt senden.
So sieht die def von mir aus. Aber das topic, dass die readingList füttert, kommt aus dem friendlyName des Gerätes, der ursprünglich mal aus XiaomiMQTTDevice generiert wurde.
define MQTT2_zigbee_tradfri_r1 MQTT2_DEVICE zigbee_tradfri_r1
attr MQTT2_zigbee_tradfri_r1 IODev MQTT2_Client
attr MQTT2_zigbee_tradfri_r1 model zigbee2mqtt_Wireless_Button
attr MQTT2_zigbee_tradfri_r1 readingList zigbee2mqtt/tradfri_r1:.* { json2nameValue($EVENT) }
attr MQTT2_zigbee_tradfri_r1 room MQTT2_DEVICE
attr MQTT2_zigbee_tradfri_r1 stateFormat action
setstate MQTT2_zigbee_tradfri_r1 toggle
setstate MQTT2_zigbee_tradfri_r1 2019-10-02 06:35:27 action toggle
setstate MQTT2_zigbee_tradfri_r1 2019-09-21 09:47:49 associatedWith MQTT2_zigbee_pi
setstate MQTT2_zigbee_tradfri_r1 2019-10-07 09:03:08 battery 74
setstate MQTT2_zigbee_tradfri_r1 2019-10-02 06:35:12 duration 2.909
setstate MQTT2_zigbee_tradfri_r1 2019-10-07 09:03:08 linkquality 54
Ich hab schon hin und wieder bemerkt, dass es da Kollisionen gibt, z.B. auch bei Fenstersensoren, die urplötzlich nicht mehr wollten. Da stand in der yaml noch der friendlyName mit der falschen Adresse drin oder anderesrum.
Da half dann nur noch ein set remove auf das falsche Gerät und einige Minuten warten, bis der Remove-Prozess auf die unterste Ebene durchgestellt wurde.
Ich muss irgendwann mal ausprobieren, ob der friendlyName eines Devices auch aus Fhem heraus geändert werden kann.
Na ja, die Tasten könnten trotzdem kaputt sein. Aber wenn es an der firmware des Sticks hängt, dann "einfach" mal den updaten, wie von TL60 vorgeschlagen...
Hallo zusammen.
Vielen Dank für die vielen Hilfestellungen.
Als erstes werde ich den Stick neu flashen.
Das hat ein Arbeitskollege gemacht und garantiert die Version vor Juni .
Das dauert jetzt allerdings, bis ich mich mit einem Ergebnis wieder melden kann.
Die Fernbedienung ist noch neu und ich hatte vorher auch einen Werksreset gemacht.
Vielen Dank
Christian
Hallo!
ich bin gerade am umstellen von Mosquitto auf MQTT2_Server. Ich habe meine ganzen MQTT_Devices schon auf MQTT2 umgestellt jetzt will ich auch meine Zigbee Devices auf MQTT2 haben.
Habe den ganzen Beitrag gelesen, und nicht wirklich was gefunden, ich suche in der zigbee2mqtt configuration.yaml eine position wo ich 1. den Port einstellen kann und
2. Wo ich ein user:passwort einfügen kann! Mein mqtt2 server braucht ein Passwort.
3. Wie lösch ich Mosquitto von meinem Raspi?
Danke!
@Kawaci
zu 1) und 2) https://www.zigbee2mqtt.io/information/configuration.html (https://www.zigbee2mqtt.io/information/configuration.html)
zu3) "sudo apt-get remove --auto-remove mosquitto". Könnte jedoch sein, dass Du noch mehr deinstallieren musst - hängt davon ab, was Du alles installiert hast ...
Danke! Habs versucht mosquitto zu entfernen und dann ist fhem nicht mehr hochgefahren! Jetzt noch mal ein fhem backup aufgespielt und die ganzen tasmota sachen laufen nun auf mqtt2 port 1884 die alten gelöscht und es funktioniert. Jetzt zu meiner frage, wie krieg ich die zigbee geräte auf mqtt2? Einfach port änder hat nichts gebracht es wurde kein einziges gerät angelegt!
Den zigbee2mqtt-Dienst hast du aber nach der Änderung der yaml neu gestartet?
Wenn ja, ist da mind. ein Device (wenn autocreate auf beiden Ebenen MQTT2_SERVER+TYPE=autocreate darf). Auf das mußt du dann das zigbee2mqtt-Bridge-attrTemplate anwenden (siehe "Praxisbeispiele" im Wiki). Der Rest sollte dann halbwegs selbsterklärend sein.
Ja alles neugestartet! 3-4 mal aber kein device ist gekommen! Clienten muss ich keinen anlegen oder?
Nein. Wenn der Port paßt, müßte der zigbee2mqtt-Dienst direkt mit dem MQTT2_SERVER sprechen, und dann sollten auch Devices angelegt werden, wenn nicht "allowed" zuschlägt; irgendwo hattest du mal gefragt, wie das mit dem Passwort geht. Vermutlich solltest du mal im FHEM- und zigbee2mqtt-log nachsehen, ob da was zu finden ist.
Alternativ: eventuell paßt die readingList einer deiner "Altlasten"... (Sammeldevice?)? Dann wird natürlich nichts mehr neu angelegt.
(Wenn beide Dienste auf derselben Maschine laufen und via localhost kommunizieren, würde ich da ein Ausnahme zulassen).
So jetzt kommen alle devices nach der reihe herein! Es hat alles gepasst nur die Zeile server: 'mqtt://localhost:1884' musste ich auf die server: 'mqtt://192.168.xx.xx:1884' ändern! Keine Ahnung wieso!
So danke noch mal für die Hilfe! Die Geräte die ich vorher über MQTT angelegt habe löschen und nicht mit set remove entfernen, wenn ich mit dem einrichten fertig bin!
So, da bin ich nun.
Ich möchte auch von Mosquitto mit MQTT auf MQTT2_Server umsteigen.
Habe fleißg mehrfach diesen Thread gelesen und auch die Praxisbeispiele.
Aktuell betrifft es mich nur im Bereich XiaomiMQTTDevice mit Osram Plugs, Xiaomi Tempsensoren und vier neuen Bulbs, die meine alte Milight Config ablösen sollen.
- MQTT2_Server auf port 1884 eingerichtet.
- Port und client_id in configuration.yaml umgestellt.
- Bridge wird angelegt und mit Template zu MQTT2_zigbee_coordinator gemacht.
- mit dem BridgeRegexp Attribut werden auch viele Geräte vereinzelt.
- Danach wende ich auf die Plugs das Plug template an, auf die Sensoren das TempHumHpaSensor Template und die Bulb das light_cc.
Aber:
Ich habe wahrscheinlich den Fehler gemacht, das meine Temperatursensoren alle diese Namen haben:
Temp_Badezimmer, Temp_Kinderzimmer, Temp_Kueche usw.
Diese werden mir nicht vereinzelt, sondern in einem Device MQTT2_zigbee_Temp zusammen gefasst.
1. Wie kann ich das beheben? Muss der "Unterstrich" mit in den Regexp Ausdruck?
2. Die Plugs lassen sich nicht schalten.
Ich schaue mit journalctl -u zigbee2mqtt.service -f parallel nach ob ein Commando an kommt. Tut es aber nicht.
Kann ich ein paar Denkanstöße für meine beiden Punkte haben bitte?
Gruß Marco
Zitat von: Sedonion am 03 April 2020, 17:12:23
1. Wie kann ich das beheben? Muss der "Unterstrich" mit in den Regexp Ausdruck?
Wenn ich https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template#L64 ansehe, ist der _ in der BridgeRegexp drin (und zwar schon ziemlich lange).
=> bist du auf dem aktuellen Template-Stand? (auch mit FHEM allg., da hat sich grade im MQTT2-Bereich einiges getan
Zitat2. Die Plugs lassen sich nicht schalten.
Ich schaue mit journalctl -u zigbee2mqtt.service -f parallel nach ob ein Commando an kommt. Tut es aber nicht.
Auch hier kann ich nicht ausschließen, dass es erst vor kurzem eine Änderung gab, da war bei irgendeinem noch ein fehlender Parameter drin, wenn ich's richtig im Kopf habe.
Sollte das nach einem update (und der automatischen Neuanlage der plug-devices, da evtl. was kaputt gegangen ist...) noch da sein, bitte je ein RAW von jedem Device, so kann man nur raten...
Ja, FHEM update wurde gestern durchgeführt. Ich hoffe die Templates sind da mit drin und auch aktuell?
Zumindest für die Plugs bin ich auf der Spur:
- Ein Plug Device gelöscht
- mit set MQTT2_Server publish zigbee2mqtt/ID_der_Plug/set {"state":"ON","brightness":60} geschaltet
- Plug ist wieder da aber mit folgender readinglist: zigbee2mqtt/Bassbox:.* { json2nameValue($EVENT) }
Wende ich da jetzt das template für die Plugs an, kommen solche Dinge dabei raus:
Internals:
CFGFN
CID zigbee_Bassbox
DEF zigbee_Bassbox
DEVICETOPIC zigbee2mqtt/Bassbox:.* { json2nameValue($EVENT)
FUUID 5e8757ad-f33f-5a77-2244-041bc99761be0e7c
IODev MQTT2_Server
NAME MQTT2_zigbee_Bassbox
NR 2168
STATE on
TYPE MQTT2_DEVICE
READINGS:
2020-04-03 17:35:09 associatedWith MQTT2_zigbee_coordinator
2020-04-03 17:35:09 last_seen 1585928109630
2020-04-03 17:35:09 linkquality 52
2020-04-03 17:35:09 state ON
2020-04-03 17:35:09 update_available false
Attributes:
IODev MQTT2_Server
devicetopic zigbee2mqtt/Bassbox:.* { json2nameValue($EVENT)
eventMap { dev=>{ON=>'on',OFF=>'off'} }
genericDeviceType switch
icon message_socket
model zigbee2mqtt_plug
readingList $DEVICETOPIC:.* { json2nameValue($EVENT) }
room MQTT2_DEVICE
setList on:noArg $DEVICETOPIC/set {"state":"ON"}
off:noArg $DEVICETOPIC/set {"state":"OFF"}
attr MQTT2_zigbee_Bassbox setStateList on off
Allein das Devicetopic haut so nicht hin.
Kann es richtig sein, dass über alle die eckigen Klammern mit drin sind?
Hmm, ok, hast recht, das devicetopic scheint "kaputt" zu sein, der Doppelpunkt und alles danach muß an der Stelle raus.
Muß den Fehler erst suchen, wird ggf. etwas dauern, bitte einstweilen manuell reparieren...
OK, habe es gefunden und im svn auch eine passendes update bereitgestellt.
Kannst du mal das hier machen:
{ Svn_GetFile("FHEM/lib/AttrTemplate/mqtt2.template", "FHEM/lib/AttrTemplate/mqtt2.template", sub(){ AttrTemplate_Initialize() }) }
und dann das neue/aktualisierte template anwenden? Das sollte auch mit der "falschen Schreibweise" in devicetopic klarkommen...
Mach ich gern, aber vorher noch ein Hinweis:
Mal hat er das devicetopic richtig gesetzt, mal nicht.
Kann das was mit der Auswahl im Popup Fenster bezüglich Alexa zu tun haben?
Nach dem Template Update habe ich alle Plugs gelöscht, den zigbee2mqtt Dienst neu gestartet und auf alle Plugs das Template angewandt.
Topics sehen gut aus :)
Ich muss korrigieren:
Topics sehen nicht gut aus.
Es wird das letzte Zeichen weg gelassen.
Aus zigbee2mqtt/Gartenhaus wird zigbee2mqtt/Gartenhau und aus zigbee2mqtt/Druckersteckdose wird zigbee2mqtt/Druckersteckdos
Kannst du bitte den genauen Weg nennen, wie das Device jetzt konfiguriert wurde (aus dem "kaputten" von neulich heraus oder gelöscht, autocreate, neues attrTemplate)?
Dann wäre ein RAW-list nett, der Fehler kann nämlich an zwei Stellen entstehen, und ich kann so nicht erkennen, worauf sich das bezieht.
Es würde mir zusätzlich helfen, wenn ich ein "neues" Device (auch als RAW-List) bekäme, falls ich doch was testen muß...
Ich habe das Device gelöscht, den zigbee2mqtt Dienst restartet, dadruch durch autocreate das Device anlegen lassen und das neue Template laufen lasen.
Ich habe hier noch einige ungenutzte nie angemeldete Contaktsensoren, die ich nachher einbinden und "jungfräulich" den Weg durch spiele und das RAW Device schicke.
Es gibt im zigbee2mqtt_ContactSensor Template einen weiteren Fehler im Zusammenspiel mit Alexa und dem Homebridgemapping.
Soll ich da auch hier beschreiben oder in den zigbee2mqtt Template Thread?
Es wäre vermutlich einfacher, beide Themen zusammen in einen Extra-Thread zu packen, ist jweils an sich kein Umstellungs-Thema, und das mit dem mapping geht ggf. "on the fly" zusammen mit der Frage, was an der regex jetzt wieder/noch kaputt ist.