Zum Hintergrund:
Nachdem Phoscon alle paar Monate die Verbindung von den meisten Lampen verliert möchte ich ZB2MQTT versuchen.
- ZB2MQTT wurde auf einem separaten PI eingerichtet und Frontend funktioniert.
In FHEM wurde eine bridge eingerichtet:
Internals:
CID zigbee_pi
DEF zigbee_pi
FUUID 68e505ab-f33f-2a6c-1482-092b9754e2bfa3da
IODev m2server
NAME MQTT2_zigbee_pi
NR 660
STATE ???
TYPE MQTT2_DEVICE
READINGS:
2025-10-07 14:42:55 IODev m2server
2025-10-07 14:41:30 attrTemplateVersion 20240628
Attributes:
autocreate 1
bridgeRegexp zigbee2mqtt/((?!bridge)[A-Za-z0-9._]+)/?.*:.* "zigbee_$1"
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.
devicetopic zigbee2mqtt
getList networkmap_raw:noArg raw $DEVICETOPIC/bridge/request/networkmap raw
networkmap_graphviz:noArg graphviz $DEVICETOPIC/bridge/request/networkmap graphviz
icon mqtt
model zigbee2mqtt_bridge
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/config:.* { json2nameValue($EVENT) }
$DEVICETOPIC/bridge/log:.*\"type\".\"devices\".\"message\".* devices
$DEVICETOPIC/bridge/log:.* log
$DEVICETOPIC/bridge/logging:.* { json2nameValue($EVENT,'log_') }
$DEVICETOPIC/bridge/response/networkmap:.* { my $type = $EVENT =~ m/.*,"type":"(raw|graphviz)",.*/ ? $1 : 'networkmap'; $EVENT =~ m/{"data":\{.*"value":"?(.*[^"])"?\},"status":"ok"\}/ ? { $type=>$1 } : {} }
$DEVICETOPIC/bridge/devices:.* devices
$DEVICETOPIC/bridge/info:.* info
$DEVICETOPIC/bridge/groups:.* groups
$DEVICETOPIC/bridge/event:.* { json2nameValue($EVENT) }
$DEVICETOPIC/bridge/extensions:.* extensions
$DEVICETOPIC/bridge/response/permit_join:.* { json2nameValue($EVENT) }
$DEVICETOPIC/bridge/definitions:.* {}
room 97_ZB2MQTT
setList log_level:debug,info,warn,error $DEVICETOPIC/bridge/config/log_level $EVTPART1
permit_join:true,false $DEVICETOPIC/bridge/request/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
setStateList on off
Im Frontend lässt sich eine Lampe sowie ein Schalter problemlos bedienen.
Sollten diese jetzt nicht in FHEM aufschlagen?
Wo liegt mein Denkfehler?
Zitat von: Brad Majors am 07 Oktober 2025, 15:03:49Sollten diese jetzt nicht in FHEM aufschlagen?
Wo liegt mein Denkfehler?
Ja das sollten sie.
- Ist das IODev (mserver) connected?
- Was ist das IODev für ein Typ? Bei MQTT2CLIENT/SERVER kannst du dir den Traffic anschauen. Kommt da was an?
- Stimmt das topic überhaupt?
- Ist das globale (FEHM) autocreate auch enabled?
VG Sebastian
Zum Bridge-Device, die Definition aus dem Wiki ist inzwischen wegen Z2M Version 2 veraltet.
Hier hatte ich mal eine rudimentäre Definition gepostet: https://forum.fhem.de/index.php?topic=140307.msg1333978#msg1333978
Bin mir grade aber nicht sicher, ob das für autocreate noch so valide ist, das nutze ich nicht. (Ich würde aber eigentlich sowieso empfehlen, nicht autocreate zu nutzen, sondern einfach die Geräte manuell in FHEM anzulegen, schön sauber mit json2nameValue und devicetopic, etc. Die attrTemplates kann man natürlich als Inspiration nutzen.)
Ist das IODev (mserver) connected?
> Ja, aber jetzt wird es kompliziert, das ist ein mserver der auch mqtt von den Tasmota Wifi Schaltern abgreift.
> Muss ich einen neuen für die Zigbee MQTT anlegen? Oder läuft das über einen? Sorry für die blöde Frage.
Was ist das IODev für ein Typ?
> m2server
Bei MQTT2CLIENT/SERVER kannst du dir den Traffic anschauen. Kommt da was an?
> Wo schaut man das?
Stimmt das topic überhaupt?
> Ja, da bin ich mir sicher, das habe ich im Z2M im GUI sehen können
> zigbee2mqtt
Ist das globale (FEHM) autocreate auch enabled?
> Ja, steht auf simple
Oder muß ich noch was im Z2M eintragen?
Zitat von: Brad Majors am 07 Oktober 2025, 16:54:32Bei MQTT2CLIENT/SERVER kannst du dir den Traffic anschauen. Kommt da was an?
> Wo schaut man das?
Da wo auf der Detailseite Deines m2server in FHEM steht "Show MQTT traffic"
Ziemlich weit oben links, direkt unter der FHEM Befehlszeile.
Zitat> Muss ich einen neuen für die Zigbee MQTT anlegen?
Nein, ein MQTT Server reicht, solange die Geraete unterschiedliche Topics oder MQTT-ClientIDs verwenden.
ZitatIst das globale (FEHM) autocreate auch enabled?
> Ja, steht auf simple
Damit autocreate funktioniert, muss sowohl eine autocreate
Instanz definiert sein (ist in der initialen Version von fhem.cfg der Fall), wie auch das Attribut autocreate des IODevs.
Bei MQTT2_SERVER ist das Attribut per Voreinstellung no, bei MQTT2_SERVER simple.
D.h. wenn man nichts geaendert oder geloescht hat, dann ist bei MQTT2_SERVER autocreate aktiv.
MQTT2_DEVICE Instanzen werden dann automatisch angelegt, wenn eine Nachricht von einem Geraet empfangen wurde.
Bei gateways wie z2m muss zusaetzlich ein bridgeRegexp Attribut gesetzt sein (siehe oben, ist der Fall), damit das Modul die Nachrichten den einzelnen Geraeten zuordnen kann.