Homeassistant MQTT Autodiscovery von FHEM bzw. MQTT

[stephan-221]

Nachdem ich mich inzwischen durchgewälzt habe und die MQTT_GENERIC_BRIDGE erfolgreich am Laufen habe und in Homeassistant leider ganz viel in der configurations.yaml angelegt habe, gibt es auch einen eleganteren Weg.

Wenn man als topic homeasssistant nutzt und ein reading "config" entsprechend zusammenfügt, dieses per publish auch in den MQTT Lake sendet, lernt Homeassistant das Gerät "automatich" ohne dass manuelle Einträge in der configurations.yaml notwendig sind.

Beispiel für einen Aktor:

Code Auswählen Erweitern

attr myAktor userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
attr myAktor alias FlammenwerferVorgarten
attr myAktor mqttPublish state:topic={"homeassistant/switch/$device/state"} config:topic={"homeassistant/switch/$device/config"}
attr myAktor mqttSubscribe state:stopic={"homeassistant/switch/$device/set"}
attr myAktor room Aktoren,HASS
attr myAktor userReadings config {sprintf('{"name": "%s", "uniq_id": "%s", "command_topic": "homeassistant/switch/%s/set", "state_topic": "homeassistant/switch/%s/state", "payload_on": "on", "payload_off": "off", "state_on": "on", "state_off": "off" ,"retain": false}',AttrVal($name,"alias",0),InternalVal($name,"FUUID",0),InternalVal($name,"NAME",0),InternalVal($name,"NAME",0))}\

Das ist genauso auch für andere Gerätetypen wie Sensoren etc. möglich.
Das config Reading enthält quasi die Angaben aus der configurations.yaml in leicht modifiziertem Format.
Hier habe ich jetzt noch mit einem Freund zusammen daran gearbeitet, dass der Name und eine eindeutige ID sowie der Alias eben aus der FHEM Konfig übernommen werden. Das vereinfacht Copy&Paste.

[Beta-User]

Hast du mal geschaut, wie oft das versendet wird ?

Tipp: Mit trigger arbeiten (als Befehl (z.B. als Reaktion auf einen MQTT-Reconnect) _und_ bei userReadings)...

[stephan-221]

Hast du mal geschaut, wie oft das versendet wird ?

Ein sehr guter Punkt. Das ist ein beobachteter Nebeneffekt, den ich auch noch auf der ToDoListe habe.

Ich sehe bei meinen Sensoren oder auch bei dem Aktor, dass nur ein aktiver Schaltvorgang dazu führt, dass das Device in HASS oder iobroker dann erst einen Status hat. Beim Reload von HASS fehlen bis zur ersten Aktion alle Stati.

Jetzt stehe ich nur gerade auf dem Schlauch. Mit trigger habe ich mich noch nicht beschäftigt.

Ich hätte angenommen, dass "event-min-interval state:120,config:600" meine Freunde gewesen wären. Aber das bringt keine Aktion zum vorschein.
Ziel wäre eine zyklisches senden der Stati, und eben als Sahnehäubchen bei einem Reconnect.

Reconnect im MQTT2_Client hätte ich mit einem DOIF ungefähr so gelöst:

([ha_MQTT2] eq "opened")
{
fhem "trigger  HM_LC_SW4_PCB_Sw_02 config";;
#fhem "trigger  ..."
}

Aber jetzt bin ich erstmal mit meinen Gedanken am Ende...

[Beta-User]

Also:

Zum einen sollte das userReadings-Ding jeweils einen trigger bekommen! Dazu würde ich was "besonderes" verwenden, das eigentlich so gar nicht vorkommt:

Code Auswählen Erweitern

attr myAktor userReadings config:hassConfig {sprintf('{"name": "%s", "uniq_id": "%s", "command_topic": "homeassistant/switch/%s/set", "state_topic": "homeassistant/switch/%s/state", "payload_on": "on", "payload_off": "off", "state_on": "on", "state_off": "off" ,"retain": false}',AttrVal($name,"alias",0),InternalVal($name,"FUUID",0),InternalVal($name,"NAME",0),InternalVal($name,"NAME",0))}
Das sollte dann "anspringen", wenn folgender trigger-Befehl kommt:

Code Auswählen Erweitern

trigger .*:FILTER=mqttPublish~.+ hassConfig Mit einem entsprechenden trigger-Kommando kannst du ggf. auch neue oder geänderte Geräte dann mit HASS bekannt machen.

Würde das dann in ein notify basteln (DOIF kann ich nicht), z.B. so (oder für diesen Zweck uU. retained publishen):

Code Auswählen Erweitern

defmod ha_MQTT2_config notify ha_MQTT2:opened trigger .*:FILTER=mqttPublish~.+ hassConfig
Damit hast du aber "nur" die config in deinem HomeAssistant, kein "zyklisches" Status-update. MAn. sollte man das auch nicht machen, jedenfalls dann nicht, wenn HASS in der Lage ist, sich Werte zu merken. Sonst wirkt das so, als wäre irgendwas aktuell, was "uralt" ist... Habe aber keine Ahnung von HASS oder ioBroker.

[stephan-221]

Das sollte dann "anspringen", wenn folgender trigger-Befehl kommt:
Code Auswählen Erweitern

Code Auswählen Erweitern

trigger .*:FILTER=mqttPublish~.+ hassConfig

Die Idee ist gut.
Der Trigger löst nur eine sehr schräge Aktion aus.
Damit werden sehr viele Devices per mqtt mit folgendem publish gesetzt: state = hassConfig
Ist der String so wirklich korrekt?

Bezüglich periodischer Meldungen:
So wie ich das sehe, senden openDTU und auch rpimon etwa alle 30min die config herum.
Bei HMW Aktoren ist es leider so, dass die nur bei Änderungen den Status an FHEM bzw. dem hm485d mitteilen.
Und dann ist es bei HASS leider so, dass dieser eben nach einem Reload der Config keinen Status für diese Geräte mehr hat.
Daher wäre die Minimallösung eben bei einem Reconnect alle Stati lokal abzufragen.
Das bekäme ich auch noch so mit Bordmitteln hin.

"get HMW_Sen_SC_12_DR_MEQ99999999_.* state"

Das userReading wird in dem Fall (ohne Trigger) zumindest auch neu geschrieben.

Ja ist eine Krücke...

Unsere initiale Idee war halt, dass man ohne manuelle Konfiguration in HASS FHEM/MQTT Devices hinbekommt.


 
 

[Beta-User]

Ist der String so wirklich korrekt?

Es ist eine Variante von vielen denkbaren... "Eigentlich" ändert das nicht den Wert des _Readings_ "state", sondern erzeugt halt ein Reading-loses Event. Wenn z.B. auch dein "FlammenwerferVorgarten" darauf mit "state" anspringt, könntest du es (ungetestet) dahingehend ändern, dass eben explizit ein vermeintliches Reading-Event erzeugt wird (der trigger-Filter im userReadings-Eintrag muss auch entsprechend angepaßt werden, Punkt statt Leerzeichen):

Code Auswählen Erweitern

trigger .*:FILTER=mqttPublish~.+ hassConfig: 1

So wie ich das sehe, senden openDTU und auch rpimon etwa alle 30min die config herum.

...was nicht bedeutet, dass das "vorbildlich" wäre, sondern dass eben jemand einen Würgaround finden mußte...

Bei HMW Aktoren ist es leider so, dass die nur bei Änderungen den Status an FHEM bzw. dem hm485d mitteilen.

Dieses Verhalten ist mAn. "ideal" - mich persönlich nerven alle (nicht-Sensor-) Geräte-Typen, die glauben, es wäre sinnvoll, ständig irgendwelche unveränderten Statusmeldungen machen zu müssen.

Und dann ist es bei HASS leider so, dass dieser eben nach einem Reload der Config keinen Status für diese Geräte mehr hat.
Daher wäre die Minimallösung eben bei einem Reconnect alle Stati lokal abzufragen.

Prinzipiell stellt sich mir die Frage, ob es von HASS wirklich so gedacht sein kann, dass man _ständig_ "on the fly" seine Geräte neu definieren muss, ohne, dass man das dann ggf. schlicht verstetigt, wenn man die _initiale Konfiguration_ mal gemacht hat. Das hat mAn. ziemlich viele Haken, wenn man sich die Geräte-Konfiguration und deren "Zustand" nicht merkt.

Jedenfalls kann es m.E. nicht die Lösung sein, die Konfiguration bei jedem Pups (also auch jeder Temperaturänderung etc.) mit zu versenden...