Autodiscovery für HomeAssistant ermöglichen

[Shortie]

Wie hier https://forum.fhem.de/index.php/topic,115279.msg1185614.html#msg1185614 angeregt ein neuer Thread zu dem Thema discovery Topics in MQTT für Home Assistant zu senden.

Es geht dabei um die Idee die Discovery Funktionalitäten von Home Assistant für MQTT zu nutzen und die Konfiguration insgesamt zu vereinfachen, sowie die Möglichkeit zu haben auf HA Seite verschiedene MQTT Entitäten zu einem Gerät zusammen zu fassen.

Grundsätzlich muss dafür pro Entität in Home Assistant eine Nachricht gesendet werden die dem folgenden Format folgt: <discovery_prefix>/<component>/[<node_id>/]<object_id>/config
In der Nachricht sind dann Informationen zum Gerät und zur Entität enthalten.

Als Beispiel ein Temperatur und Luftfeuchte Sensor um mehrere Entitäten auf einem Gerät zu demonstrieren.

In fhem habe ich dazu bei dem entsprechenden Sensor 2 Topics über mqttPublish konfiguriert um Temperatur und Luftfeuchte zu übermitteln:

Code Auswählen Erweitern


attr DeviceWerkstattTemperaturSensor mqttPublish humidity|temperature:topic={"workshop/$name"}


Um dafür nun ein Discovery zu ermöglichen muss jeweils eine config Nachricht gesendet werden, sinnvollerweise mit retain, damit auch nach einem Neustart von HA direkt die Geräte wieder bekannt sind und HA nicht auf Recovery zurückfällt.

Die config Nachricht kann dabei alle Daten enthalten die normalerweise in der configuration.yaml eingetragen werden und zusätzlich noch Informationen um die Entitäten zu einem Gerät zusammen zu fassen und in einen Bereich einzusortieren. Gerät ist ohne Discovery nicht möglich, Bereich nur nachträglich für jede einzelne Entität über die GUI.

Hier ein Beispiel wie so eine Nachricht aussehen könnte, ich denke vieles davon sollte sich auch per Variablen füllen lassen.

Code Auswählen Erweitern


{
   "unique_id":"workshop.temperature",
   "name":"workshop_temperature",
   "state_topic":"workshop/temperature",
   "availability_topic":"fhem/connection/status",
   "payload_available":"connected",
   "payload_not_available":"disconnected",
   "device":{
      "name":"Workshop Temperatursensor",
      "identifiers":"workshop_environment_sensor",
      "suggested_area":"Workshop",
      "manufacturer":"Homematic",
      "model":"HM-WDS40-TH-I-2"
   }
}


Das ganze geht dann z.B. an das Topic homeassistant/workshop_temperature/temperature/config

In fhem könnte das ganze Ähnlich Aussehen wie für mqttPublish. Also in diesem Beispiel wäre es dann z.B. ein neues Attribut mqttConfig humidity|temperature:topic={"workshop/$name/config"}:json=<inhalt des json mit entsprechenden Variablen>

Je nach verfügbaren Daten könnte man das auch komplett pro Gerät auf fhem Seite vereinfachen. Also z.B. anstatt "workshop" im Beispiel den Raum, Gruppen oder Device Namen nutzen, je nachdem wie man das in fhem Strukturiert, so wie es bei den Topics im anderen Thread ja auch schon für die Topics selbst gemacht wird. Als uniqe_id könnte man sinnvollerweise das Attribut serialNr hernehmen, sowie bestimmt auch weitere Attribute.

Damit würde sich das bekanntmachen und die Konfiguration des Gerätes nur auf das entsprechende Template im Config Attribut auf fhem Seite beschränken, welches bestenfalls sogar für alle Geräte gleichen Typs identisch sein kann.

Die Nachricht sollte dann gesendet werden wenn sich das Attribut mqttConfig ändert oder wenn fhem die Verbindung zum MQTT Broker herstellt.

[Beta-User]

Na ja, manches gibt es so ähnlich schon in jsonlist2, da könnte man also ggf. Anleihen hernehmen.

Wo bzw. wie so eine Funktionalität untergebracht werden könnte, sollte man m.E. erst mal noch offen lassen.

Sinn macht das ganze (so man überhaupt einen erkennen mag) dann, wenn es mehr oder weniger automatisch geht - aus den Angaben, die schon da sind. Hier wäre mir z.B. unklar,
- was das mit "workshop" soll;
- wieso hier nicht beide Readings auftauchen (temp/hum);
- wie soll das gehen mit der availability, wenn mehrere FHEM-Devices übertragen werden (kommt sich das ins Gehege oder nicht? Wenn nein, ist es vermutlich ok, aber wo kommt dann die Info her?)
- warum man die Hersteller/Modellangaben braucht;
- warum man neue ID's erzeugen soll.

Von Vorn:
- "workshop" scheint die Übersetzung des room-Attributs zu sein. Warum nicht direkt?
- Jedes FHEM-Device hat ein ID-Internal. Warum nicht das? Ggf. iVm. dem Reading-Namen (bzw. dessen $alias), wenn es sein muss (=> zuerst klären, was mit mehreren Readings ist;
- Hersteller => TYPE, model darf model bleiben, wenn es das gibt (was ist mit subType).

Würde also mal empfehlen, den gewünschten Payload mit dem zu vergleichen, was "jsonlist2 DeviceWerkstattTemperaturSensor" liefert.

[hexenmeister]

So was mache ich auch schon lange für diverse Sensoren und auch für Thermostate. Allerdings nicht direkt. Hat historische Gründe. Ich habe vor Jahren alle Sensoren aus fhem per mqtt weitergeleitet. Diese werden in NodeRed ausgewertet und für einige Logiken verwendet. Außerdem werden alle in influxdb geschrieben, damit man diese in grafana anzeigen kann.
Später habe ich in NodeRed eine entsprechende Erweiterung zum Erstellen von discovery Nachrichten implementiert.
Könnte ich natürlich hier teilen, aber ist schon sehr speziell (gehört eher in NodeRed forum, als hierher) und nicht für jeden geeignet.

[Beta-User]

...vermutlich ist das ganze immer sehr speziell, und wird auch erfordern, dass man gewisse Standards in FHEM einhält. Daher auch meine Fragen, wo eigentlich bestimmte Dinge herkommen sollen. Denn wenn es sowieso für jedes Device irgendwie (zu sehr) manuell angepaßt werden muss, dürften andere Lösungen einfacher sein...

Vorläufig würde ich annehmen, dass man sowas entweder mit einem setter in MGB erschlagen könnte, oder ein separates Modul generiert, das in der Lage ist, die Infos aus den MGB-Attributen auszuwerten (bzw. die "get-Anfrage" an MGB per Device). Letzteres dürfte näher liegen, weil das eher wenige Leute benötigen... (?).

[hexenmeister]

Na so sehr manuell muss das nicht sein. Man hat an dem Device ja alles, was man benötigt. Daher können die mqttPublish-Einträge pro Geräte/Sensor-Art durchaus gleich sein.

Mein Beispiel für 'humidity' mit HomeMatic Wandthermostat. Ist nur die 'Vorstufe', die in NodeRed noch umformatiert wird, aber man könnte sicherlich so umbauen, dass es gleich AutoDiscovery-Einträge entstehen. Soll hier also nur als eine Anregung dienen.

mqttPublish ist bei alle Geräten gleich:

Code Auswählen Erweitern


humidity!info:topic={"$base/usr/$roomid/sen/humidity/$num/info"}
humidity!info:expression={toJSON({manuf=>"$dev_manuf",type=>"sensor",categorie=>"clima",
  reading=>"humidity",num=>"$num",unit=>"%",valuetype=>"number",format=>"00",
  roomid=>"$roomid",room=>"$roomname",name=>"$device",dev_uid=>"$uid"})}


mqttDefaults enthält speziefische Variablen, könne man aber weg bekommen, indem man z.B. die 'room'-Attribute verwendet.

Code Auswählen Erweitern

roomid="ka" num="01"
roomname="Kinderzimmer"
dev_manuf="HomeMatic"

Daraus entsteht folgende Topic: home/usr/ka/sen/humidity/01/info

Code Auswählen Erweitern


{
  "categorie": "clima",
  "dev_uid": "5ce00c65-f33f-7939-1de4-f4cb0ee7ec0de2ba",
  "format": "00",
  "manuf": "HomeMatic",
  "name": "KA_WT01_Weather",
  "num": "01",
  "reading": "humidity",
  "room": "Kinderzimmer",
  "roomid": "ka",
  "type": "sensor",
  "unit": "%",
  "valuetype": "number"
}


NodeRed 'kennt' alle Sensor-Typen (sind ja nicht so viele) und erstellt daraus folgendes:
homeassistant/sensor/red_KA_WT01_Weather/humidity/config

Code Auswählen Erweitern

{
  "device": {
    "identifiers": [
      "red:KA_WT01_Weather"
    ],
    "manufacturer": "HomeMatic",
    "name": "KA_WT01_Weather",
    "suggested_area": "Kinderzimmer"
  },
  "name": "ka_humidity_01",
  "state_topic": "home/usr/ka/sen/humidity/01/json",
  "value_template": "{{ value_json.value }}",
  "unique_id": "home.usr.ka.sen.humidity.01",
  "device_class": "humidity",
  "state_class": "measurement",
  "unit_of_measurement": "%",
  "expire_after": 600
}


Etwas komplexer wird es bei Aktoren wie z.B. Thermostate, da sehen die Einträge schon so aus:
homeassistant/climate/red_KA_WT01/config

Code Auswählen Erweitern

{
  "name": "ka_heating_01",
  "unique_id": "home.usr.ka.act.clima.heating.01",
  "device": {
    "identifiers": [
      "red:KA_WT01",
      "origin:KA_WT01_Climate"
    ],
    "name": "KA_WT01",
    "manufacturer": "HomeMatic",
    "sw_version": "1.4",
    "suggested_area": "Kinderzimmer",
    "via_device": "Node-RED 2.1.3"
  },
  "temperature_command_topic": "home/usr/ka/act/clima/heating/01/set-desired-temp",
  "temperature_state_topic": "home/usr/ka/act/clima/heating/01/desired-temp",
  "modes": [
    "off",
    "heat"
  ],
  "mode_state_topic": "home/usr/ka/act/clima/heating/01/mode",
  "power_command_topic": "home/usr/ka/act/clima/heating/01/power",
  "hold_modes": [
    "auto",
    "manual",
    "boost",
    "day",
    "night"
  ],
  "hold_command_topic": "home/usr/ka/act/clima/heating/01/set-control-mode",
  "hold_state_topic": "home/usr/ka/act/clima/heating/01/control-mode",
  "precision": 0.1,
  "temp_step": 0.5,
  "max_temp": 25,
  "min_temp": 5,
  "json_attributes_topic": "home/usr/ka/act/clima/heating/01/attributes",
  "json_attributes_template": "{{value_json}}"
}

Aber auch hier bekommt man eine Automatisierung hin.

Im Anhang paar Bilder...

[Shortie]

Ich stehe hier gerade am Anfang Versuche mit MQTT in Richtung HA zu unternehmen. Dem gegenüber steht eine seit sehr vielen Jahren gewachsene fhem Installation. Durch meinen Beruf bin ich gerade bei solchen Integrationen mittlerweile sehr stark dazu übergegangen auf technischer Ebene englische Bezeichnungen zu verwenden. Daher das "workshop" in den Bezeichnungen. Auch bin ich noch nicht soweit an allen möglichen Stellen Variablen ausprobiert zu haben. Daher auch bei dem json Beispiel die Ergänzung das sich vieles per Variablen machen lassen müsste. Dies fand ich besser als dort meinerseits ungetestete Variablen reinzuschreiben.
Das json war eher als Beispiel gedacht wie eine config Message insgesamt aussieht.
Einfach auf $room setzen ist in meiner aktuellen Installation und Nutzung von fhem auch nicht möglich, da ich so meine aktuelle fhem Ansicht zerlegen würde. Hier werde ich mir weiter Gedanken machen wie dies in meinem Fall sinnvoll umsetzbar ist. Ggf schenke ich doch auf die lokalisierten Bezeichnungen oder mir fällt noch etwas anderes ein.

Hier nochmal mit (evtl. nicht funktionierenden) Variablen um zu zeigen wie man es für die verschiedenen Readings nutzen könnte.

Code Auswählen Erweitern


{
   "unique_id":"$room.$name",
   "name":"$room_$name",
   "state_topic":"$room/$name",
   "availability_topic":"fhem/connection/status",
   "payload_available":"connected",
   "payload_not_available":"disconnected",
   "device":{
      "name":"$device",
      "identifiers":"$serialNr",
      "suggested_area":"$room",
      "manufacturer":"Homematic",
      "model":"$model"
   }
}


Die availability wird von HA dazu genutzt um zu sehen ob fhem generell erreichbar ist. Über MQTT_CLIENT wird auf fhem/connection/status beim verbinden mit retain "connected" gesetzt, beim trennen wird es auf "disconnected" gesetzt. Dies wäre in allen Configs identisch.

Hersteller und Model wird in der Geräteübersicht von HA angezeigt.

id bezieht sich auf die Entität, also in dem Fall jeweils auf temperature und humidity.

[Wiesel]

Hallo,

gibt es hierzu irgendwas neues ?

[dominik]

Passt zwar nicht ganz zu der Lösung, aber vielleicht dennoch relevant in diesem Thread.

Ich habe gerade in fhempy die Erkennung der HomeAssistant MQTT Topics eingebaut:
https://github.com/fhempy/fhempy/tree/master/FHEM/bindings/python/fhempy/lib/mqtt_ha_discovery

Das ist nur mal eine erste Version, die automatisch Devices in FHEM erstellt und die richtigen readingList, setList Attribute anhand der HA MQTT Messages befüllt. Ich hatte das nur implementiert, da ich die Konfiguration der selbstgebauten ESPHome Devices immer mühsam fand.

[monosurr0und]

Das finde ich sehr spannend, kann bis auf den git Beitrag aber nichts weiter dazu finden. Der Eintrag in fhem ist schnell gemacht, jedoch fürchte ich, dass bis auf ,,Installation finished. Please wait..." nicht viel passieren wird. Ich steig bei HA aber noch nicht wirklich durch, ich bin mir lediglich sicher das es fhem bei mir nicht ablösen wird.

Passt zwar nicht ganz zu der Lösung, aber vielleicht dennoch relevant in diesem Thread.

Ich habe gerade in fhempy die Erkennung der HomeAssistant MQTT Topics eingebaut:
https://github.com/fhempy/fhempy/tree/master/FHEM/bindings/python/fhempy/lib/mqtt_ha_discovery

Das ist nur mal eine erste Version, die automatisch Devices in FHEM erstellt und die richtigen readingList, setList Attribute anhand der HA MQTT Messages befüllt. Ich hatte das nur implementiert, da ich die Konfiguration der selbstgebauten ESPHome Devices immer mühsam fand.

[masterpete23]

Ich suche auch noch eine Lösung, da FHEM gerade mein MQTT Broker ist und ich HASS teste.
Zigbee2MQTT habe ich aber auf homeassistant: false einstellen müssen, da sonst z.b. ein Tastendruck doppelt gesendet wird und ich somit bei einem toggle keine Schaltung erhalte.

[freetz]

Ich implementiere gerade für die HomeAssistant-User ein MQTT AutoDiscovery für mein BSB-LAN Projekt, das ursprünglich mal mit FHEM angefangen hat, aber inzwischen von den Usern an unterschiedliche Projekte angebunden wurde. Da ich selber weiterhin FHEM nutze, wollte ich fragen, ob jemand weiß. ob es außer Dominiks fhempy-MQTT auto discovery auch "native" FHEM-Lösungen gibt, bei denen über MQTT Auto Discovery dann die entsprechenden Geräte angelegt werden?
Wenn es so etwas gibt, würde ich mich über eine kurze Kontaktaufnahme freuen, damit ich mich bei der Implementation nicht aus Versehen auf Home Assistant begrenze, wenn es mit wenigen Änderungen z.B. auch für FHEM gehen würde.