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]

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]

{
   "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]

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]

roomid="ka" num="01"
roomname="Kinderzimmer"
dev_manuf="HomeMatic"
Daraus entsteht folgende Topic: home/usr/ka/sen/humidity/01/info

Code: [Auswählen]

{
  "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]

{
  "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]

{
  "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]

{
   "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.