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