MQTT2_Discovery - nativer HA/Tasmota discovery Support

[Guybrush]

Da spricht grundsätzlich nichts dagegen. Ich nutz nur selbst kein Subversion mehr und hab alles auf git umgestellt. Deswegen pack ich auf github auch grad meine Sachen step by step. Hast du das Modul mal selbst getestet? Ich hab zwar schon super viele tests geschrieben, aber tests ersetzen nicht alles 

[SH_Heini]

Bei einer Lampe wird "zigbee2mqtt/bridge/status" genommen, bei Sensoren jedoch "$DEVICETOPIC/bridge/state".
Würde Ersteres bevorzugen, da dann das Devicetopic für das jeweilige Gerät besser genutzt wird.

readingList von WZ_LIGHTSTRIP_LICHT:

Code Auswählen Erweitern

$DEVICETOPIC/availability:.* { MQTT2_DISCOVERY_runtimeAvailability($NAME, $EVENT, "{\"policies\":[{\"mode\":\"all\",\"reading\":\".availability_policy_cde3617c\",\"sources\":[\".availability_1fd9595d\",\".availability_5c66e817\"]}],\"sources\":[{\"available\":\"online\",\"reading\":\".availability_1fd9595d\",\"template\":\"{{ value_json.state }}\",\"unavailable\":\"offline\"}]}") }
$DEVICETOPIC:.* { json2nameValue($EVENT, '', {'availability' => 'state_availability'}, '^(?:brightness|effect|effect_speed|linkquality|power_on_behavior|state)$') }
zigbee2mqtt/bridge/state:.* { MQTT2_DISCOVERY_runtimeAvailability($NAME, $EVENT, "{\"policies\":[{\"mode\":\"all\",\"reading\":\".availability_policy_cde3617c\",\"sources\":[\".availability_1fd9595d\",\".availability_5c66e817\"]}],\"sources\":[{\"available\":\"online\",\"reading\":\".availability_5c66e817\",\"template\":\"{{ value_json.state }}\",\"unavailable\":\"offline\"}]}") }


discovery message von TK_TUER_BAD:

Code Auswählen Erweitern

{
  "availability": [
    {
      "topic": "zigbee2mqtt/bridge/state",
      "value_template": "{{ value_json.state }}"
    },
    {
      "topic": "zigbee2mqtt/TK_TUER_BAD/availability",
      "value_template": "{{ value_json.state }}"
    }
  ],
  "availability_mode": "all",
  "default_entity_id": "binary_sensor.tk_tuer_bad_contact",
  "device": {
    "hw_version": 2,
    "identifiers": [
      "zigbee2mqtt_0x00158d0007e78871"
    ],
    "manufacturer": "Aqara",
    "model": "Door and window sensor",
    "model_id": "MCCGQ11LM",
    "name": "TK_TUER_BAD",
    "sw_version": "3000-0001",
    "via_device": "zigbee2mqtt_bridge_0x983268fffe1c1485"
  },
  "device_class": "door",
  "object_id": "tk_tuer_bad_contact",
  "origin": {
    "name": "Zigbee2MQTT",
    "sw": "2.13.0",
    "url": "https://www.zigbee2mqtt.io"
  },
  "payload_off": true,
  "payload_on": false,
  "state_topic": "zigbee2mqtt/TK_TUER_BAD",
  "unique_id": "0x00158d0007e78871_contact_zigbee2mqtt",
  "value_template": "{{ value_json[\"contact\"] }}"
}

Gruß

[Guybrush]

das müsste mit der neuen Version schon funktionieren. Lief jedenfalls gerade bei mir sauber durch. Wenn die letzten Sachen fertig und unittests komplett sind, gibts die neue Version 

[Beta-User]

Hast du das Modul mal selbst getestet?

Nein, und das war auch weder mein Plan, noch war mein Anliegen hinter beiden Posts persönliches (Nutzungs-) Interesse. Kurz zu den Punkten:

svn:
Unabhängig davon, ob man svn nun gut findet oder nicht, oder die Art und Weise, wie patches den Eingang ins (fhem-) svn-Repo finden, ist svn aktuell die Methode, mit der die allgemeine Code-Basis gepflegt wird. Damit ist auch implizit verbunden, dass grundsätzlich klar ist, dass ggf. auch anderen diese Code-Basis dauerhaft zur Nutzung bereit steht und (praktisch eher im Notfall, aber) auch andere Entwickler mit svn-Zugang die Möglichkeit haben, Fehler zu beseitigen.
Weiter schaue ich am ehesten in der commandref nach, wenn ich eine (Modul-)Lösung für ein Problem suche, danach im Wiki bzw. Forum. Vielleicht dann zuletzt im allgemeinen Internet. Wenn dann die Lösung in contrib zu finden ist, bin ich persönlich eher geneigt, das auszuprobieren, wie wenn ich (gut gepflegte!) github-repos einbinden muss. (Die imo schlechteste Variante ist es, wenn man sich in Bandwurm-Threads die jeweils letzte Fassung selbst suchen muss).

Da du in der letzten Zeit mind. 3 update-Quellen angelegt hast, wollte ich dich einfach dazu anpingen .

Die mich mich einfachste Variante dabei war, schlicht den Thread zu nutzen, in dem ich sowieso schon mal gepostet hatte .

bridgeRegexp:
Dabei ging es mir weniger um die Übernahme der konkret zu MQTT2_DEVICE gefundenen Lösung, sondern eher um die Überlegung, ob es nicht zielführend ist, eine Eingabestelle für den einzelnen User zu haben, mit der dem Modul ggf. mitgeteilt werden kann, was der User selbst als relevant für solche "autocreate"-Vorgänge ansieht.
Wenn man sowas nicht braucht oder es kontraproduktiv ist, darfst du das gerne anders lösen.

[Guybrush]

Es dürfte kein Problem sein über github actions bei einem commit nach main einen commit ins fhem svn anzulegen. Hab ich noch nicht gemacht, aber wenn das gewünscht ist und ich Zugang zu habe, kann ich mir das gerne anschauen.

BridgeRegexp ist aus meiner Sicht eher ein Behelf, der ohne das Discovery Modul schon fast essentiell ist, wenn man da nicht vollgemüllte readings haben möchte. Ich hab das in der neuen Version schon drin, dass optional per Attribut alle über Discovery erkannten sicheren Readings auch schon ohne Wert angelegt werden können. Man könnte aber auch drüber nachdenken noch eine Regexp Filterung zu hinterlegen, wenns denn Sinn macht. Ich selbst will eigentlich alle sinnigen Readings haben. Über autocreate erstellte Readings werden alle Discovery Config Elemente als reading erkannt, auch wenns nur beschreibend ist usw. Das wird schnell unübersichtlich. Das passiert mit MQTT2_Discovery aber nicht mehr.

[Guybrush]

Ich hab das Modul geupdatet. Die aktuelle Version liegt noch im Dev Branch, den ich dann aber später in Main überführen möchte:

Code Auswählen Erweitern

update add https://raw.githubusercontent.com/next81/fhem.MQTT2_Discovery/dev/controls_MQTT2_DISCOVERY.txt
update

Zigbeebridge usw sollten jetzt auch richtig gehen. So sieht meine Zigbee2Mqtt Bridge nach discovery und rebuild aus:

Code Auswählen Erweitern

attr zigbee2mqtt readingList $DEVICETOPIC/info:.* { MQTT2_DISCOVERY_runtimeRef($NAME, 'r_ddd6824033ac357c', $EVENT) }\
$DEVICETOPIC/state:.* { MQTT2_DISCOVERY_runtimeRef($NAME, 'r_f37c2d6e26b25423', $EVENT) }
attr zigbee2mqtt setList Restart:noArg $DEVICETOPIC/request/restart \
log_level:error,warning,info,debug $DEVICETOPIC/request/options\
permit_join:on,off { MQTT2_DISCOVERY_runtimeRef($NAME, 'r_48b97e793d1525c8', $EVENT) }

Man kann jetzt auch zuvor per autocreate/manuell angelegte MQTT2_DEVICES durch MQTT2_DISCOVERY übernehmen. dafür gibts den neuen Befehl "rebuildDevice <device> clearReadings". clearReadings ist optional und löscht alle readings. Das macht Sinn, wenn durch autocreate blödsinnige Readings entstanden sind. Ich hab das jetzt bei mir ins Produktivsystem übernommen und funktioniert soweit fehlerfrei. Daher gerne andere bitte auch mal testen.

Changelog:
Sonos2mqtt integriert und Discovery-Verarbeitung erweitert

- Sonos2mqtt als dritten Discovery-Adapter eingebunden
- Media-Player-Readings, Availability und Steuerbefehle abgebildet
- Home-Assistant-Update-Entitäten samt Installationsbefehl unterstützt
- Root-Entities unabhängig von Groß- und Kleinschreibung korrekt benannt
- Geräteaktionen mit gemeinsamem Topic zu einem Reading zusammengeführt
- Jinja-Auswertung um defined, undefined und bedingte Ausdrücke erweitert
- Komplexe Templates, Mappings und JSON-Auswertungen über stabile Runtime-Referenzen gekapselt
- Unicode-Werte an der FHEM- und MQTT-Grenze korrekt als UTF-8 codiert
- Doppelte Codierung bereits vorliegender MQTT-Bytes verhindert
- extraJsonReadings, availabilityReading und createReadings ergänzt
- Reading-Kollisionen anhand des Topic-Pfads eindeutig aufgelöst
- Attributänderungen ohne erneute Discovery-Nachrichten neu gerendert
- Vorhandene JSON-Sammelhandler im konservativen Modus berücksichtigt
- Devicetopic-Ableitung anhand geräteeigener Availability-Topics verbessert
- rebuildDevice um atomare Devicetopic- und Listenerzeugung erweitert
- Optionales Löschen sichtbarer Readings beim Neuaufbau ergänzt
- Rollback und Erfolgserkennung beim Löschen von Readings korrigiert
- FHEMWEB-Übersicht für verwaltete und nicht verwaltete Devices ergänzt
- Interne Tasmota-Neuaufbauten von echten Discovery-Löschungen getrennt

[50watt]

Ich hab das Modul geupdatet. Die aktuelle Version liegt noch im Dev Branch, den ich dann aber später in Main überführen möchte:

Code Auswählen Erweitern

update add https://raw.githubusercontent.com/next81/fhem.MQTT2_Discovery/dev/controls_MQTT2_DISCOVERY.txt
update


Beim Versuch, den aktuellen dev-Stand frisch zu aktualisieren, bricht FHEM bei mir mit einer Größenabweichung ab:

Downloading https://raw.githubusercontent.com/next81/fhem.MQTT2_Discovery/dev/controls_MQTT2_DISCOVERY.txt
MQTT2_DISCOVERY
UPD FHEM/10_MQTT2_DISCOVERY.pm
Got 99666 bytes for FHEM/10_MQTT2_DISCOVERY.pm, expected 144096
aborting.

In der controls_MQTT2_DISCOVERY.txt steht aktuell für die Datei:

UPD 2026-08-29_10:50:01 144096 FHEM/10_MQTT2_DISCOVERY.pm

Die aktuell geladene Datei im dev-Branch scheint aber 99666 Bytes groß zu sein.

Könntest du bitte die controls-Datei aktualisieren?

Ich würde danach meine Tasmota-/ESPresense-/sonos2mqtt-Tests mit einem sauberen aktuellen dev-Stand wiederholen, bevor ich die gefundenen Punkte poste.

[Guybrush]

Den Fehler hab ich lokal schon behoben. Das fiel mir auch auf, dass der Pre-Commit Hook unsauber arbeitete. Ich hab die aktuelle Fassung jetzt in den DEV Branch gepushed. Sollte jetzt gehen!