Umzug v. MQTT_DEVICE und XiaomiMQTTDevice nach MQTT2_DEVICE

[Beta-User]

Mobil+kurz: andere template-Alternative anwenden, "split".

[Beta-User]

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 ).

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?

[Blauhorn]

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.

[Müller]

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.

Code Auswählen Erweitern


define MQTT2 MQTT2_CLIENT 127.0.0.1:1883

Code Auswählen Erweitern

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

[Müller]

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 ......

[Beta-User]

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).

[Müller]

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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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?

Code Auswählen Erweitern

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

[Müller]

UND ich dachte schon alles ist gut......

Wenn ich versuche einen Schalter per webcmd  zu schalten bekomme ich

Code Auswählen Erweitern

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

[Beta-User]

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?

[Müller]

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

[Beta-User]

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 ).

[Müller]

templates für dimbare OsramBirne und dimmbare RGB Osram Birne gehen gut.
Template für osramSteckdose habe ich smart+plug benutzt, dass geht nicht

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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



[Beta-User]

OK. Kannst du sagen, was geändert werden müßte?

(Bitte ggf. ein list vom alten device liefern)

[Müller]

Hallo habe nun die Dose zum laufen bekommen:

Code Auswählen Erweitern

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"}

[Beta-User]

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).