Tasmota, zigbee2mqtt und generische Geräte via MQTT und Autocreate

Begonnen von HomeAlone, 17 Oktober 2019, 12:07:34

Vorheriges Thema - Nächstes Thema

HomeAlone

Hallo zusammen,
ich hoffe der Titel passt halbwegs. Folgendes würde ich gerne realisieren:


  • Anbindung meiner Zigbee-Geräte über zigbee2mqtt und automatische Einbindung in fhem, wenn hier neue Geräte angelernt werden.
  • Anbindung meiner Tasmota-geflashten Geräte über eine zentrale Instanz in fhem, welche sich auch um das Autocreate kümmert.
  • MQTT-isierung meiner ZWave und Enocean-Geräte (aktuell noch nicht angegangen, aber das wäre dann der nächste Schritt)

Als MQTT Server verwende ich Mosquitto.

Den ersten Punkt (zigbee2mqtt) habe ich realisiert:
externer Mosquitto Server <-> MQTT2_CLIENT (+autocreate) <-> MQTT2_DEVICE (mit attrTemplate zigbee2mqtt_bridge).
So werden mir fleißig alle über zigbee2mqtt angebundenen Geräte im Raum MQTT2_DEVICE angelegt und mittels Templates kann ich diesen die gewünschte Funktion zuordnen. Das funktioniert.

Jetzt wollte ich mich an den zweiten Punkt machen und dachte eigentlich, es müsste wie folgt funktionieren:
externer Mosquitto Server <-> derselbe MQTT2_CLIENT (+autocreate) <-> ein neues MQTT2_DEVICE (mit attrTemplate MQTT2_CLIENT_general bridge)
Tut es aber nicht :)
Jetzt wird zwar ein neuer Raum angelegt, in dem ein neues MQTT2_DEVICE angelegt wird, aber meine mit Tasmota geflahten Devices erscheinen dort nicht (mehrfach an und aus geschaltet).

Die Definition dieses automatisch erzeugten Devices ist:
defmod TasmotaCoordinator MQTT2_DEVICE TasmotaCoordinator
attr TasmotaCoordinator IODev mosquittoATnucgulp
attr TasmotaCoordinator alias TasmotaCoordinator
attr TasmotaCoordinator autocreate 1
attr TasmotaCoordinator bridgeRegexp (tele|cmnd)[/]([^/]+)[/].*:.* "$2"\
  shellies[/]([^/]+)[/].*:.* "$1"\
  (ESPClient_[^/]+)[/].*:.* "$1"
attr TasmotaCoordinator comment Do not use very open bridgeRegexp expressions! This might lead to irritating results...
attr TasmotaCoordinator model MQTT2_CLIENT_general_bridge
attr TasmotaCoordinator room MQTT2_MQTT2_Tasmota
attr TasmotaCoordinator setStateList on off

setstate TasmotaCoordinator 2019-10-17 11:23:51 associatedWith MQTT2_Tasmota


Orientiert habe ich mich dabei an den Praxisbeispielen für MQTT2-Module (Tasmota), dort wird aber explizit davon ausgegangen, dass ein MQTT2_SERVER im Spiel ist. So wie ich beim Weiterlesen verstanden habe, müsste es aber auch mit einem MQTT2_CLIENT funktionieren, der auf einen externen MQTT-Server (hier: mosquitto) verweist.

Kann mir jemand auf die Sprünge helfen, wo mein Denkfehler ist oder was zu tun ist, um in fhem Tasmota-geflashte Geräte so komfortabel wie über die zigbee2mqtt Anbindung einzubinden?

Sowohl fhem als auch die Tasmota-Geräte sind alle auf dem aktuellsten Stand.

Schon mal vielen Dank im Voraus für Eure Hilfe.

Viele Grüße
Sascha

Beta-User

"An sich" sollte MQTT2_CLIENT-Gerät+MQTT2_DEVICE-attrTemplate: MQTT2_CLIENT_general_bridge in Bezug auf autocreate (fast) dieselbe Funktionalität haben wie ein MQTT2_SERVER, kann aber sein, dass die bridgeRegexp da noch verbesserungsfähig ist, oder Probleme bestehen, weil du nicht zuerst das "generelle" MQTT2_CLIENT_general_bridge-Gerät angelegt hast (dein "TasmotaCoordinator"), sondern das "spezielle" für zigbee2mqtt...

Um dem auf den Grund zu kommen:

- Welche CID hat die zigbee2mqtt-Bridge? Wenn da die vom CLIENT drin steht, "fängt" dieses Device vermutlich bereits alles ab, was eigentlich woanders hin gehört - schau also da mal in die readingList, ob da nicht deutlich "zu viel" drinne ist. Wenn ja: die betreffenden Teile löschen, und auch die CID so ändern, dass das NICHT zum CLIENT paßt.

- Generell solltest du dir dann mal ansehen, wie sämtliche MQTT2-DEVICE's aussehen und ggf. ebenfalls das jeweils löschen, was zu viel ist (sobald ein readingList-Eintrag paßt, werden andere Devices nicht mehr via autocreate "bedient").

- Besonders interessieren würde mich das Device "MQTT2_Tasmota". Was ist das, wo kommt das "associatedWith" dahin her?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

HomeAlone

Zitat von: Beta-User am 17 Oktober 2019, 12:30:03
"An sich" sollte MQTT2_CLIENT-Gerät+MQTT2_DEVICE-attrTemplate: MQTT2_CLIENT_general_bridge in Bezug auf autocreate (fast) dieselbe Funktionalität haben wie ein MQTT2_SERVER, kann aber sein, dass die bridgeRegexp da noch verbesserungsfähig ist, oder Probleme bestehen, weil du nicht zuerst das "generelle" MQTT2_CLIENT_general_bridge-Gerät angelegt hast (dein "TasmotaCoordinator"), sondern das "spezielle" für zigbee2mqtt...

Um dem auf den Grund zu kommen:

- Welche CID hat die zigbee2mqtt-Bridge? Wenn da die vom CLIENT drin steht, "fängt" dieses Device vermutlich bereits alles ab, was eigentlich woanders hin gehört - schau also da mal in die readingList, ob da nicht deutlich "zu viel" drinne ist. Wenn ja: die betreffenden Teile löschen, und auch die CID so ändern, dass das NICHT zum CLIENT paßt.

- Generell solltest du dir dann mal ansehen, wie sämtliche MQTT2-DEVICE's aussehen und ggf. ebenfalls das jeweils löschen, was zu viel ist (sobald ein readingList-Eintrag paßt, werden andere Devices nicht mehr via autocreate "bedient").

- Besonders interessieren würde mich das Device "MQTT2_Tasmota". Was ist das, wo kommt das "associatedWith" dahin her?
Ich hatte gerade knapp eine Stunde dokumentiert, was ich gemacht habe, um weiterzukommen und jetzt ist der Text weg.  :'(

Kurz: Ich habe die Definition für den MQTT_Coordinator (also den Zigbee2MQTT-Teil) unverändert gelassen - mMn. muss die CID derjenigen aus der config von zigbee2mqtt entsprechen. Scheint auch so zu klappen.

Dann habe ich wie von Dir geraten, die autocreated devices gecheckt und entdeckt, dass es ein Device im Raum MQTT2-DEVICE gab, welches sämtliche readings enthielt, die von den Tasmota-Devices kommen. Also dieses gelöscht, zusätlich das MQTT2-Tasmota MQTT2-Device gelöscht und mit der CID des mosquitto Servers neu angelegt und als GENERAL_BRIDGE definiert.
Daraufhin wurde im Raum MQTT2-DEVICE ein Gerät MQTT2_GeneralBridge angelegt.
Da bei mir alle Tasmota-Geräte ihre mqtt-Befehle mit dem Prefix tasmota/ senden, habe ich die bridgeRegExp dort noch um diesen Präfix erweitert:
defmod MQTT2_GeneralBridge MQTT2_DEVICE MQTT2_GeneralBridge
attr MQTT2_GeneralBridge IODev mosquittoATnucgulp
attr MQTT2_GeneralBridge alias MQTT2_GeneralBridge
attr MQTT2_GeneralBridge autocreate 1
attr MQTT2_GeneralBridge bridgeRegexp (tasmota/tele|tasmota/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


Und siehe da: die ersten Tasmota Devices wurden schon angelegt (Sonoff S20, Sonoff Basic und eine Gosund SP111). <- gibt es für letztere schon ein Template? ;)

Irgendwas ist glaube ich immer noch nicht so perfekt - aber das gucke ich mir in Ruhe am WE noch mal an, muss jetzt ins Bettchen. :)

Der entscheidende Hinweis war auf jeden Fall das checken der auto-created devices.

Noch mal vielen Dank für Deine Hilfe, @Beta-User!

Beta-User

Zitat von: HomeAlone am 17 Oktober 2019, 22:58:45
Und siehe da: die ersten Tasmota Devices wurden schon angelegt (Sonoff S20, Sonoff Basic und eine Gosund SP111). <- gibt es für letztere schon ein Template? ;)
:) Schön, dass es soweit geklappt hat und auch klarer zu sein scheint, wie man ggf. die bridgeRegexe anpassen muß!

Die attrTemplates sind in der Regel weniger auf konkrete Hardware zugeschnitten, sondern eher auf Funktion (wieviele Relais, mit/ohne Meßfunktion...). Wenn effektiv was fehlt, einfach fragen/ein RAW einstellen (->contributing bzw. Anregungen).

Was die CID-Frage für das "generelle Bridge-Device" angeht, ist es Absicht, dass das NICHT die CID vom IO ist: Dann landen nämlich alle nicht zuordenbare Dinge genau in einem anderen Device, mit dem man (anders als mit dem Bridge-Device) beliebig verfahren kann, es insbesondere also auch einfach löschen ;) . Aber das scheint ja bei dir jetzt auch wieder so zu sein.
Diese Überlegung ist aber zugegebenermaßen "auf die Schnelle" mal auf meinem Mist gewachsen; da ich (außer auf einem Testsystem) weder CLIENT noch (derzeit irgendeinen) Tasmota im Einsatz habe, muß das nicht optimal sein... (Es gibt dazu auch einen Thread, in dem ich mich mit mir selber unterhalte, sonst hat sich bisher kaum einer dazu gemeldet ??? ).

Wenn du Vorschläge hast, was ggf. an welcher Stelle der Doku noch ergänzungsbedürftig ist: Vorschläge nehme ich gerne entgegen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files