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!

[50watt]

Vielen Dank für das neue Modul und die viele Arbeit, die da offensichtlich schon hineingeflossen ist.

Ich habe den aktuellen dev-Stand bei mir mit einem MQTT2_SERVER getestet. Insgesamt macht das schon einen sehr guten Eindruck.

Positiv getestet habe ich bisher:

* Tasmota Discovery mit zwei Gosund EP2
* ESPresense über Home-Assistant-Discovery
* Restart von FHEM mit anschließendem Wiederherstellen der Registry
* erneuter rescan
* Availability der erzeugten Devices
* get mqttDiscovery devices

Besonders positiv: Nach Restart und erneutem rescan bleiben die erzeugten readingList-Einträge bei mir stabil. Die zuvor beobachteten mehrfachen Einträge konnte ich mit dem aktuellen Stand nicht mehr reproduzieren.

Aktuell sind mir noch zwei Punkte aufgefallen.

1. Sonos2mqtt

Mein sonos2mqtt publiziert die Discovery-Informationen in der von sonos2mqtt dokumentierten Form:

homeassistant/music_player/<RINCON>/sonos/config

Genau diese retained Topics sehe ich auch auf meinem Broker.

Ein Beispiel-Payload enthält u.a.:

{
  "device_class": "speaker",
  "state_topic": "sonos/RINCON_xxx",
  "command_topic": "sonos/RINCON_xxx/control",
  "availability_topic": "sonos/connected",
  "payload_available": "2"
}

MQTT2_DISCOVERY verarbeitet diese Topics bei mir aktuell mit dem HomeAssistant-Adapter und meldet:

Nicht unterstuetzte Komponente: music_player

Im aktuellen README ist für den Sonos2mqtt-Adapter dagegen das Format

sonos2mqtt/discovery/<mqttPrefix>/<RINCON>

beschrieben.

Die sonos2mqtt-Dokumentation beschreibt jedoch:

homeassistant/music_player/<RINCON>/sonos/config

Siehe:

https://sonos2mqtt.svrooij.io/topics.html

Daher meine Frage: Ist sonos2mqtt/discovery/... für eine andere bzw. neuere sonos2mqtt-Version gedacht, oder sollte der Sonos2mqtt-Adapter auch das offiziell dokumentierte homeassistant/music_player/.../sonos/config erkennen?

2. ESPresense / number

ESPresense funktioniert bei mir grundsätzlich gut:

* Device wird korrekt angelegt
* Telemetrie wie uptime und freeHeap funktioniert
* Availability funktioniert
* absorption und max_distance werden als Readings korrekt aktualisiert

Bei den beiden number-Entities erhalte ich allerdings:

number: ungueltige min/max/step-Kombination

Betroffen sind:

homeassistant/number/espresense_xxx/absorption/config
homeassistant/number/espresense_xxx/max_distance/config

Die relevanten Discovery-Payloads sehen so aus:

{
  "~": "espresense/rooms/sz",
  "name": "Absorption",
  "stat_t": "~/absorption",
  "cmd_t": "~/absorption/set",
  "step": "0.1",
  "entity_category": "config"
}

und:

{
  "~": "espresense/rooms/sz",
  "name": "Max Distance",
  "stat_t": "~/max_distance",
  "cmd_t": "~/max_distance/set",
  "step": "0.1",
  "entity_category": "config"
}

Die Readings funktionieren:

absorption  2.70
max_distance 16.00

Es wird jedoch für beide kein Setter erzeugt.

Soweit ich die Home-Assistant-MQTT-number-Dokumentation verstehe, sind min und max optional und haben Defaultwerte. Daher könnte hier eventuell das Default-Handling für fehlendes min/max fehlen.

Insgesamt funktioniert aber bereits erstaunlich viel sehr sauber. Vielen Dank auch dafür, dass die Restart-/Rescan-Themen im aktuellen Stand offenbar schon deutlich robuster geworden sind.

[Guybrush]

Danke auch für die Tests!

Wegen Sonos:
Du hast wohl noch eine ältere Sonos2Mqtt Version laufen. Seit der aktuellen 4.0.0-beta-6 haben die das von /homeassistant/music_player/<RINCON>/sonos/config auf sonos2mqtt/discovery/<mqttPrefix>/<RINCON> geändert:
https://github.com/svrooij/sonos2mqtt/pull/184/changes/8c1cbb7b0af75dbcc18cf821ebb34dd2284cc171

Daher habe ich mich entschlossen direkt (nur) das neue Format zu unterstützen. HomeAssistant selbst kennt jedenfalls nativ auch kein music_player. Es ist/war schon immer eine spezifische Sonos2Mqtt Erweiterung. Deswegen kennt der HA Parser das auch nicht, da das nur im S2M Parser drin ist. Die neuen 4.0.0 Beta Releases von S2M laufen aber gut. Daher hab ich die bei mir nun auch schon produktiv laufen. Wenn S2M das aber auf Dauer doch beides parallel unterstützen sollte kann ich das noch integrieren. Ansonsten will ich das so erstmal lassen. S2M wird ja aktiv entwickelt.

Wegen ESPpresence:
Du hast scheinbar ein Bug im Default-Handling gefunden. Aktuell werden min=0, max=100 und step=1 nur gemeinsam gesetzt, wenn alle drei Angaben fehlen. Ist lediglich step=0.1 vorhanden, bleiben min und max undefiniert und die nachfolgende Validierung verwirft den Setter. Home Assistant behandelt diese Felder hingegen unabhängig voneinander als optional. Das ist aber nicht schwer anzupassen. Mach ich im Laufe des Tages 

Hakelig war vor allem, dass manuelle Ergänzungen/Änderungen an der reading/setList erhalten bleiben, aber neue Sachen auch ergänzt werden. Theoretisch muss man mit Discovery garnichts mehr an den Attributen ändern. Aber es gibt leider immer wieder Devices, die Topics senden, die nicht per Discovery vorher bekannt gegeben wurden. Insofern ist es schon gut, wenn wir diese Freizügigkeit bei FHEM erhalten und das nicht zu stark vorgeben wie HA es macht. Aber schön, dass das bei dir auch gut läuft  
 

[Guybrush]

In der neuen DEV Version ist der Fehler mit den Settern bzgl. ESPresence behoben. Nicht gesetzte Setter Werte werden nun mit Defaults gesetzt (min=0,max=100,step=1)

Code Auswählen Erweitern

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