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.