MQTT2_Discovery - nativer HA/Tasmota discovery Support

[Guybrush]

Das ist alles richtig so, da zigbee2mqtt den bridgestatus auch bei jedem einzelnen device im discovery mitschickt. HA nutzt das für die Verfügbarkeitsprüfung. Dort werden bei zigbee2mqtt default 2 Werte im discovery topic eines devices übertragen - die des devices und die der bridge. wenn beide positiv sind, dann ist availability = 1 bei HA.

Wenn du in Zigbee2mqtt unter settings>home assistant integration "enabled" aktivierst, wird auch automatisch ein Zigbee Bridge Device angelegt. HA funktioniert ja etwas anders als fhem. Das ist eigentlich unnötig in jedem device den bridge status zu haben. Aber es ist auch komfortabel, weil man so nichts händisch machen muss, wie bei fhem. MQTT2_Discovery soll das HA / Tasmota Protokoll insoweit 1:1 umsetzen und verzichtet auf hardcodierte Umbiegungen. Das funktioniert also alles so wie gewollt und würde in HA auch nicht anders laufen.

ich bau das aber gerade schon ein, dass entsprechend der HA Vorgaben ein availabilty topic gesetzt wird. die readings von device+bridge würden dann ausgeblendet, oder optional über attribut trotzdem angelegt werden. so in etwa solls werden.

[Guybrush]

Bei Schaltern sieht es momentan noch so aus.
automatisch angelegtes Gerät:

kannst du davon die discovery message einmal posten?

[SH_Heini]

kannst du davon die discovery message einmal posten?

da stehe ich gerade auf dem Schlauch, was meinst Du mit discovery message?

[Guybrush]

das sind die mqtt nachrichten mit discovery prefixen. default:
homeassistant/...
tasmota/discovery/...

nur diese nachrichten verarbeitet MQTT2_Discovery. alle anderen sind states/cmd und werden unverändert von MQTT2_Device verarbeitet. Ich brauch also die zu dem Gerät gehörende Nachricht die mit einem der beiden präfixe beginnt. also z.b. tasmota/discovery/<gerät>/...

[SH_Heini]

Code Auswählen Erweitern

{
  "availability": [
    {
      "topic": "zigbee2mqtt/bridge/state",
      "value_template": "{{ value_json.state }}"
    },
    {
      "topic": "zigbee2mqtt/SCHALTER_WAND_SZ/availability",
      "value_template": "{{ value_json.state }}"
    }
  ],
  "availability_mode": "all",
  "command_topic": "zigbee2mqtt/SCHALTER_WAND_SZ/set/identify",
  "default_entity_id": "button.schalter_wand_sz_identify",
  "device": {
    "hw_version": 1,
    "identifiers": [
      "zigbee2mqtt_0xf4b3b1fffea4daf8"
    ],
    "manufacturer": "IKEA",
    "model": "TRADFRI on/off switch",
    "model_id": "E1743",
    "name": "SCHALTER_WAND_SZ",
    "sw_version": "24.4.6",
    "via_device": "zigbee2mqtt_bridge_0x983268fffe1c1485"
  },
  "device_class": "identify",
  "entity_category": "config",
  "object_id": "schalter_wand_sz_identify",
  "origin": {
    "name": "Zigbee2MQTT",
    "sw": "2.13.0",
    "url": "https://www.zigbee2mqtt.io"
  },
  "payload_press": "identify",
  "unique_id": "0xf4b3b1fffea4daf8_identify_zigbee2mqtt"
}
das hier?

[Guybrush]

ich hab das jetzt so umgesetzt, dass ein availability reading entsprechend automatisch berechnet wird anhand der discovery settings. falls ein device zufällig diesen reserved key selbst setzen sollte, wird das reading state_availability benannt. Das entspricht jetzt so der HA Vorgaben.

Code Auswählen Erweitern

update force https://raw.githubusercontent.com/next81/fhem.MQTT2_Discovery/0.9.5-dev/controls_MQTT2_DISCOVERY.txt
shutdown restart

die angelegte readinglist/setlist sollte dann sauber sein bei dir. teste das mal.

[SH_Heini]

Hab mit oben genannten Befehl alles neu geladen, scheint aber noch die alte Version zu sein.

2026.08.24 18:51:11 2: MQTT2_DISCOVERY mqttDiscovery: defined for MQTT2_CLIENT MQTT2_TEST_CLIENT; version=0.9.3

[Guybrush]

commit ohne push funktioniert nicht jetzt aber

Code Auswählen Erweitern

update force https://raw.githubusercontent.com/next81/fhem.MQTT2_Discovery/0.9.5-1-dev/controls_MQTT2_DISCOVERY.txt
shutdown restart


[SH_Heini]

Hier wird für jedes action - payload ein eigenes Reading erstellt.
Schöner fände ich 1 Reading für action

Code Auswählen Erweitern

$DEVICETOPIC/action:arrow_left_click$ action_arrow_left_click
$DEVICETOPIC/action:arrow_right_click$ action_arrow_right_click
$DEVICETOPIC/action:brightness_move_down$ action_brightness_move_down
$DEVICETOPIC/action:brightness_move_up$ action_brightness_move_up
$DEVICETOPIC/action:brightness_stop$ action_brightness_stop
$DEVICETOPIC/action:off$ action_off
$DEVICETOPIC/action:on$ action_on
$DEVICETOPIC:.* { json2nameValue($EVENT, '', {'availability' => 'state_availability'}, '^(?:battery|linkquality)$') }
zigbee2mqtt/bridge/state:.* { MQTT2_DISCOVERY_runtimeAvailability($NAME, $EVENT, "{\"policies\":[{\"mode\":\"latest\",\"reading\":\".availability_policy_5b2bc7f1\",\"sources\":[\".availability_ad7452a7\"]}],\"sources\":[{\"available\":\"online\",\"reading\":\".availability_ad7452a7\",\"template\":\"{{ value_json.state }}\",\"unavailable\":\"offline\"}]}") }


das List eines Gerätes welches offline ist:

Code Auswählen Erweitern

Internals:
   CFGFN     
   CID        mqtt2_discovery_216684b4ecee73c1
   DEF        mqtt2_discovery_216684b4ecee73c1
   FUUID      6a8c8dfc-f33f-0f6f-011e-7f86aa44e50e9c92
   IODev      MQTT2_TEST_CLIENT
   LASTInputDev MQTT2_TEST_CLIENT
   MQTT2_TEST_CLIENT_MSGCNT 2
   MQTT2_TEST_CLIENT_TIME 2026-08-24 20:33:00
   MSGCNT     2
   NAME       FLUR_LIGHTSTRIP_LICHT
   NR         1100
   STATE      ???
   TYPE       MQTT2_DEVICE
   eventCount 3
   .DT:
     DEVICETOPIC zigbee2mqtt/FLUR_LIGHTSTRIP_LICHT
   .attraggr:
   .attrminint:
   READINGS:
     2026-08-24 20:33:00   .availability_4e04eb0c offline
     2026-08-24 20:32:44   .availability_5c66e817 online
     2026-08-24 20:32:00   .availability_io online
     2026-08-24 20:33:00   .availability_policy_5a662e8d offline
     2026-08-24 20:31:24   IODev           MQTT2_TEST_CLIENT
     2026-08-24 20:33:00   availability    offline
   SEMANTIC_METADATA:
     confidence 0.95
     entities:
       HASH(0x55ab5f1f40)
       HASH(0x55ab5ec268)
       HASH(0x55ab60c048)
       HASH(0x55ab3f37a0)
Attributes:
   DbLogExclude .*
   devicetopic zigbee2mqtt/FLUR_LIGHTSTRIP_LICHT
   group      N_E_U
   readingList $DEVICETOPIC/availability:.* { MQTT2_DISCOVERY_runtimeAvailability($NAME, $EVENT, "{\"policies\":[{\"mode\":\"all\",\"reading\":\".availability_policy_5a662e8d\",\"sources\":[\".availability_4e04eb0c\",\".availability_5c66e817\"]}],\"sources\":[{\"available\":\"online\",\"reading\":\".availability_4e04eb0c\",\"template\":\"{{ value_json.state }}\",\"unavailable\":\"offline\"}]}") }
$DEVICETOPIC:.* { json2nameValue($EVENT, '', {'availability' => 'state_availability'}, '^(?:brightness|linkquality|power_on_behavior|state)$') }
zigbee2mqtt/bridge/state:.* { MQTT2_DISCOVERY_runtimeAvailability($NAME, $EVENT, "{\"policies\":[{\"mode\":\"all\",\"reading\":\".availability_policy_5a662e8d\",\"sources\":[\".availability_4e04eb0c\",\".availability_5c66e817\"]}],\"sources\":[{\"available\":\"online\",\"reading\":\".availability_5c66e817\",\"template\":\"{{ value_json.state }}\",\"unavailable\":\"offline\"}]}") }
   room       N_E_U
   setList    brightness:slider,0,1,254 $DEVICETOPIC/set {"brightness":$EVTPART1}
flur_lightstrip_licht_effect:blink,breathe,okay,channel_change,finish_effect,stop_effect,colorloop,stop_colorloop $DEVICETOPIC/set/effect
identify:noArg $DEVICETOPIC/set/identify identify
power_on_behavior:off,on,toggle,previous $DEVICETOPIC/set/power_on_behavior
state:ON,OFF $DEVICETOPIC/set {"state":"$EVTPART1"}


Allgemin empfinde ich die jetzige Art der readingList Definitionen als unübersichtlich.

Gruß

[Guybrush]

die readinglist wird definitiv bei Geräten, die zb Jinja Templates nutzen komplexer. Bei einfachen Geräten wie Steckdosen Tasmotas usw gibts eigentlich keinen Unterschied. Dafür entstehen keine unsinnigen Reading mehr und man muss sich nicht mit der Suche nach einem passenden Template rumschlagen. das sieht da jetzt auch nur wegen dem neuen availabilty so komplex aus. dafür haben jetzt all deine Zigbee Devices ein availabilty Flag, was sofort zeigt, ob es funktioniert.

dass da mehrere readings angelegt wurden für arrow_left_click/arrow_right_click ist eigentlich richtig. Jedenfalls ist das kein Bug. Genau dieses Schema kann man der HA Doku entnehmen und Zigbee2mqtt setzt das genauso um. Das ist für Fhem etwas doof. man könnte aber sowas ggf. in etwa so zusammenfassen:

Code Auswählen Erweitern

$DEVICETOPIC/action:(?:arrow_left_click|arrow_right_click|...)$ action

Da muss ich aber erst schauen, ob das nicht irgendwelche anderen Sachen beeinflusst. Derzeit bin ich schon am Sonos2Mqtt Parser dran. Das wird dann neben Tasmota und HA der dritte Aggregator. Das muss ich erst fertig machen bevor ich danach schauen kann, aber werd mich dem dann annehmen.

Wegen der Readinglist muss man schauen. Es gibt eine versteckte Registry im Modul. Da stehen die Sachen etwas detaillierter drin. Man könnte da nur stabile Policy und Source IDs in die readinglist schreiben und den Rest aus der registry holen. Das ist aber komplexer und es betrifft nur die Lesbarkeit der readingList bei komplexen Geräten. Eigentlich soll man durch MQTT2_Discovery nie wieder die readinglist/setlist bearbeiten müssen. 

Schön ist aber, dass die neue Version availability richtig berechnet und damit auch bei dir funktioniert   Sonst sehen deine Readings jetzt aber sauber aus?