MQTT2_Client + MQTT2_Device mit zigbee2mqtt

[DOCa Cola]

Ich versuche gerade mein zigbee2mqtt in fhem einzubinden. Ich bin davon ausgegangen, dass mit MQTT2_Device mir die Geräte nun von FHEM erstellt werden. Leider funktioniert das noch nicht so ganz, oder ich habe etwas noch nicht ganz verstanden. In den Beschreibungen im Wiki wird das ganze immer mit MQTT2_Server demonstriert. Im moment setze ich Mosquitto ein und bin damit eigentlich auch zufrieden. Daher habe ich das mit MQTT2_Client eingebunden.

Ich habe die Grundkonfiguration so gemacht:

Mein MQTT2_CLIENT

Code Auswählen Erweitern

defmod mqttClient MQTT2_CLIENT 127.0.0.1:1883
attr mqttClient room MQTT2_DEVICE



und das ist mein MQTT2_Device mit dem zigbee2mqtt_bridge template

Code Auswählen Erweitern


defmod MQTT2_zigbee_pi MQTT2_DEVICE
attr MQTT2_zigbee_pi IODev mqttClient
attr MQTT2_zigbee_pi autocreate 1
attr MQTT2_zigbee_pi bridgeRegexp $DEVICETOPIC/([A-Za-z0-9._]*)[/]?.*:.* "zigbee_$1"
attr MQTT2_zigbee_pi comment To check for new updates of the deamon software, you might want to use a separate HTTPMOD device. See HTTPMOD template zigbee2mqtt_daemon_updates for further details.
attr MQTT2_zigbee_pi devicetopic zigbee2mqtt
attr MQTT2_zigbee_pi getList devicelist:noArg log $DEVICETOPIC/bridge/config/devices\
  networkmap_raw:noArg raw $DEVICETOPIC/bridge/networkmap raw\
  networkmap_graphviz:noArg graphviz $DEVICETOPIC/bridge/networkmap graphviz
attr MQTT2_zigbee_pi model zigbee2mqtt_bridge
attr MQTT2_zigbee_pi readingList $DEVICETOPIC/bridge/state:.* state\
  $DEVICETOPIC/bridge/config/devices:.* {}\
  $DEVICETOPIC/bridge/config/log_level:.* log_level\
  $DEVICETOPIC/bridge/config/permit_join:.* permit_join\
  $DEVICETOPIC/bridge/config/rename:.* { json2nameValue($EVENT, 'rename_') }\
  $DEVICETOPIC/bridge/log:.*\"type\".\"devices\".\"message\".* devices\
  $DEVICETOPIC/bridge/log:.* log\
  $DEVICETOPIC/bridge/networkmap:.* {}\
  $DEVICETOPIC/bridge/networkmap/graphviz:.* graphviz\
  $DEVICETOPIC/bridge/networkmap/raw:.* raw\
  $DEVICETOPIC/bridge/config:.* { json2nameValue($EVENT) }
attr MQTT2_zigbee_pi room MQTT2_DEVICE
attr MQTT2_zigbee_pi setList log_level:debug,info,warn,error $DEVICETOPIC/bridge/config/log_level $EVTPART1\
  permit_join:true,false $DEVICETOPIC/bridge/config/permit_join $EVTPART1\
  remove:textField $DEVICETOPIC/bridge/config/remove $EVTPART1\
  ota_update:textField $DEVICETOPIC/bridge/ota_update/update $EVTPART1\
  ota_update_check:textField $DEVICETOPIC/bridge/ota_update/check $EVTPART1\
  y_device_setting:textField $DEVICETOPIC/$EVTPART1/set {"$EVTPART2": "$EVTPART3"}\
  x_bind:textField $DEVICETOPIC/bridge/bind/$EVTPART1 $EVTPART2\
  x_bind_unbind:textField $DEVICETOPIC/bridge/unbind/$EVTPART1 $EVTPART2\
  x_device_options:textField $DEVICETOPIC/bridge/config/device_options {"friendly_name":"$EVTPART1","options": {"$EVTPART2": "$EVTPART3"}}\
  x_group_add_to:textField $DEVICETOPIC/bridge/group/$EVTPART1/add $EVTPART2\
  x_group_rm_from:textField $DEVICETOPIC/bridge/group/$EVTPART1/remove $EVTPART2\
  x_group_rm_from_all:textField $DEVICETOPIC/bridge/group/$EVTPART1/remove_all $EVTPART2\
  x_group_add_group:textField $DEVICETOPIC/bridge/config/add_group $EVTPART1\
  x_group_rm_group:textField $DEVICETOPIC/bridge/config/remove_group $EVTPART1\
  z_elapsed:textField $DEVICETOPIC/bridge/config/elapsed $EVTPART1\
  z_last_seen:disable,ISO_8601,epoch,ISO_8601_local $DEVICETOPIC/bridge/config/last_seen $EVTPART1\
  z_ban:textField $DEVICETOPIC/bridge/config/ban $EVTPART1\
  z_rename:textField $DEVICETOPIC/bridge/config/rename  {"old":"$EVTPART1","new":"$EVTPART2"}\
  z_reset_CC:noArg $DEVICETOPIC/bridge/config/reset
attr MQTT2_zigbee_pi setStateList on off


Ich bin jetzt davon ausgegangen, dass mir FHEM jetzt nun neue Devices generiert, sobald ein event von einem an zigbee2mqtt verbundenen Gerät ausgelöst wird. Tatsächlich passiert aber garnichts. Die Nachrichten kommen aber an. Ich kann mir die devicelist anzeigen lassen und auch MQTT befehle an zigbee2mqtt über Mosquitto absetzen.

Hat jemand einen Tipp für mich?

Im Anhang habe ich auch mal einen Screenshot aus dem MQTT Explorer angehängt.

[rudolfkoenig]

Per Voreinstellung ist autocreate bei MQTT2_CLIENT ausgeschaltet, weil das nur im Zusammenhang mit einem MQTT2_DEVICE mit passenden bridgeRegexp sinnvoll funktioniert.
Da MQTT2_SERVER mehr Infos hat, ist da autocreate per Voreinstellung an.

[Otto123]

Hallo Rudi,

ich wusste, dass es so ist wie Du sagst. Während Du geantwortet hast, habe ich gesucht um meine Antwort mit der Doku zu unterlegen, ich habe nichts gefunden.

Sollte man die default Einstellung für autocreate mit einem Satz in der Doku für MQTT2 Client und Server erwähnen?
Wenigsten mit fett markiert? [no|simple|complex]

Gruß Otto

[rudolfkoenig]

Server hatte schon, beim client habe ich es gerade dazugeschrieben.

[DOCa Cola]

D.h ich sollte auf dem MQTT2_Client das autocreate einschalten und es sollte gehen? Das MQTT2_Device hat auch ein autocreate. Wie die jetzt aufeinander wirken habe ich noch nicht ganz verstanden. Wenn ich beim MQTT2_Device das autocreate attribut auswähle, steht dort als Beschreibung:

if set to 0, disables extending the readingList, when the IODev autocreate is also set. ...

Die Beschreibung finde ich nicht ganz eindeutig. "is also set" - auf was gesetzt, an oder aus? Bezieht sich also das autocreate im Device rein auf die Readings und das mit Client ist allein für die Erstellung von Geräten da?

Ich habe mal mit autocreate in Client und Device rumgespielt ohne direkten Erfolg. Wenn ich es im MQTT2_Client aktiviere dann wird mir das folgende MQTT2_Device erstellt. Aber es werden keine Einzelgeräte aus zigbee2mqtt angelegt.

Code Auswählen Erweitern

defmod MQTT2_fhemMQTT2 MQTT2_DEVICE fhemMQTT2
attr MQTT2_fhemMQTT2 IODev mqttClient
fhemMQTT2:zigbee2mqtt/XiaomiButton/click:.* click\
fhemMQTT2:zigbee2mqtt/XiaomiButton:.* { json2nameValue($EVENT, 'XiaomiButton_', $JSONMAP) }\
fhemMQTT2:zigbee2mqtt/OsramOutdoor/set:.* set
...
attr MQTT2_fhemMQTT2 room MQTT2_DEVICE

setstate MQTT2_fhemMQTT2 2020-04-01 00:38:02 XiaomiButton_battery 100
setstate MQTT2_fhemMQTT2 2020-04-01 00:38:02 XiaomiButton_click
setstate MQTT2_fhemMQTT2 2020-04-01 00:38:02 XiaomiButton_linkquality 0
setstate MQTT2_fhemMQTT2 2020-04-01 00:38:02 XiaomiButton_voltage 3022
...
setstate MQTT2_fhemMQTT2 2020-04-01 00:38:02 set ON
setstate MQTT2_fhemMQTT2 2020-04-01 00:38:39 status connected




[Beta-User]

Hallo zusammen,

ein Teil des Problems ist auch das "kaputte" template gewesen (via update sollte jetzt wieder was passendes kommen)...

Hier aber bitte am besten manuell ändern:

Code Auswählen Erweitern

attr MQTT2_zigbee_pi bridgeRegexp zigbee2mqtt/([A-Za-z0-9._]*)[/]?.*:.* "zigbee_$1"

[rudolfkoenig]

autocreate bei MQTT2_CLIENT oder MQTT2_SERVER kann no,simple oder complex sein, wobei die Voreinstellung fuer MQTT2_SERVER simple, fuer MQTT2_CLIENT no ist. Falls ein Benutzer MQTT2_SERVER einsetzt, wird ohne weitere Einstellungen autocreate aktiviert, ein MQTT2_CLIENT Benutzer muss sie erst aktivieren, und fuer einen funktionierenden(!)  Bridge-Device sorgen.

"autocreate 0" sorgt bei MQTT2_DEVICE dafuer, dass neue Readings bei genau diesem Geraet nicht angelegt werden, es ist per Voreinstellung aktiviert (autocreate 1).

[DOCa Cola]

Ich hab mal das update gezogen und das template neu angewandt. Schon werden die Geräte angelegt. Super! Danke für die Hilfe. 

Etwas offtopic, aber ich bin gerade beim Stöbern in der FHEM Referenz auf anderes kleines MQTT2 Problem gestoßen. Ich wollte eigentlich die attribute für das Autocreate modul (das globale) nachlesen um ein anderes Problem zu lösen. Wenn man in der FHEM Referenz oben unter "Helper modules" auf den "autocreate" link klickt, landet man allerdings bei der referenz für das autocreate attribut von MQTT2_CLIENT.
https://fhem.de/commandref.html#autocreate
Die attribute von den MQTT2 geräten haben alle autocreate als seitenbookmark festgelegt und stehlen somit den link 

[Beta-User]

  Danke, dass du das gleich noch bestätigt hast, dass auch an der Stelle die Parameter vom template wieder sauber aufgelöst werden.

Das mit der commandref ist afaik ein bekanntes Problem, das aus der Benennung der Anker kommt, und das ist wohl auch etwas weiter verbreitet. Ich nehme an, Rudi würde dazu einen patch akzeptieren, vielleicht könntest du das für den MQTT2_DEVICE-Teil fixen?

Ansonsten wäre meine Empfehlung, mal auf "modular" umzustellen. Da gibt es zwar auch ein paar Ungereimtheiten, aber insgesamt ist das m.E. der bessere trade-off .

[DOCa Cola]

Ich glaube da fehlt mir ein bischen zuviel Hintergrundwissen um da passende Änderungen einzureichen. Tatsächlich habe ich gedacht die Seite wird irgendwie automatisch generiert. Also ähnlich wie Doxygen.

[Beta-User]

Die wird in der Tat automatisch generiert, commandref_join.pl (bzw. .._modular_pl) in contrib.

Und zwar mit Hilfe dessen, was direkt in den Modulen steht, z.B. https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/10_MQTT2_DEVICE.pm#L897: Das wäre ein entsprechender Anker - funktioniert lokal, aber wohl nicht mehr, wenn es mehrere Anker mit demselben Namen aus anderen Modulen gibt...

(@Rudi: Ich gehe davon aus, dass du mich korrigierst, wenn ich unvollständiges schreibe; (auch) mit cref tu' ich mich schwer...)

[rudolfkoenig]

Nur wenn es grob falsch ist

Deine Beschreibung ist richtig, das Problem ist bekannt, und ich habe keine gute Idee es zu fixen.
Einen Teil koennte man automatisch fixen,  aber ich zoegere noch alle Module anzufassen, und warte auf "Deus ex machina"

[Beta-User]

"deus ex machina" hieße, alle anchors bei der Generierung pro Modul zwischenzuspeichern bzw. - sofern nicht vorhanden - z.B. mit einem automatisch generierten "Präfix/postfix" zu versehen, FALLS der anchor auch eine passende interne Referenz hat?

Birgt zwar immer noch das Risiko, dass wir "false positives haben", aber wenn man sowas als separat aufrufbares sub-Programm hätten, könnten ggf. auch die Maintainer das - vereinfacht! - jeweils selbst im Quellcode fixen und müßten dann nur noch ihre "false positives" auf die "passende Referenz" umbiegen...?

Sollte doch eigentlich eine lösbare Aufgabe sein... Vielleicht sollten wir eine "support the Maintainer"-Seite aufmachen, wo man solche Tasks, die mal ein Einsteigerprojekt für einen (Noch-) Nicht-Maintainer wären, mal irgendwo sammeln...?

Ist zwar auch Aufwand, aber vermutlich weniger (frustrierender), als es selbst zu machen...
(Und ich habe im Moment neben den eigentlichen Modulthemen auch noch andere Textparser, mit denen ich rumkämpfe, mein Bedarf ist vorerst gedeckt, dazu später an anderer Stelle mehr...).

@DOCa Cola: wenigstens für den MQTT2-Device-part...? (Ohne deus ex machina.)

[rudolfkoenig]

Deus Ex Machina heisst, irgendwer mit einer goettlichen Idee erscheint aus dem Nichts, loest das Problem, und ich muss nichts machen.

Die Aufgabe waere (soweit ich es ueberblicke):
- in allen Modulen die Anker auf Modulname_attributname umstellen (automatisierbar).
- in fhemweb.js beim Attribut-Help zusaetzlich nach Modulname_attributname suchen
- die Links auf dem Anker umbauen auf Modulname_attributname. Das geht automatisch fuer alle eindeutigen Anker, ist aber ein Problem bei den doppelten, da muss ein Mensch ran.