Community

homee in Verbindung mit MQTT: homeeToMqtt


#102

Mit https://github.com/odig/homeeToMqtt/pull/8 ist Ruhe.

Ich hab das Gefühl, er hat immer wieder mit Homee neu verbunden, evtl weil nach mqtt-Connect keine Prüfung gemacht wurde, ob Homee available ist: https://github.com/odig/homeeToMqtt/pull/8/files#diff-0364f57fbff2fabbe941ed20c328ef1aR517


#103

@Micha es war gar kein Absturz von Homee, sondern wohl einfach Überlastung. Das Log war voll mit mqtt-Events. Wie gesagt, jetzt ist Ruhe.

Erst dachte ich, es läge am Echo der “human events”. Hatte zwischenzeitlich “subscribeHuman” auf false gesetzt. Aber nun tuts auch mit true wunderbar (mit meinem PR oben).


#104

Korrektur: doch nicht so ruhig mit “subscribeHuman=true”. Alle paar Minuten komplettes Relist vom mqtt (also alle “human” topics). Die schreibt homee-to-mqtt dann zurück zum Homee, und insbesondere der Z-Wave-Stack im Homee scheint sich arg zu verschlucken.

Jetzt habe ich “subscribeHuman=false” gesetzt. Dann ist alle paar Minuten (nehme an dass ist der 3-minütige Status-sync) zwar einiges zu sehen, aber keine Writes Richtung Homee.

Wie unterdrückt der Code die Echos bei den numerischen Topics? Warum brauchen die “human” Topics andere Logik? Ich hab diesen neuen Parameter dazu gesehen. Sieht aber auch arg nach Hack aus.


#105

Ja genau das ist das Problem, wenn der MQTT nicht ordentlich konfiguriert ist.

Kenne ich auch zu gut.:grinning:


#106

:slight_smile: Definiere “ordentlich”. Was muss man ändern? Hab ja jetzt die Config aus dem Install-Skript.

Hat das mit Persistenz zu tun, dass mqtt weiß, welchem Aktor es welche Nachrichten schicken muss? Hab momentan z.B. keine Benutzer, sondern Verbindung ist anonym (mit Client-Id evtl.).


#107

Hallo,

Ich denke hier geht etwas im Verständnis von MQTT durcheinander und damit die Schlussfolgerungen.

Grundsätzlich besteht eine MQTT Nachricht aus zwei teilen. Dem Topic und einen String Inhalt.
Jeder Client kann sich auf eine oder mehrere Topics registrieren für die er benachrichtigt werden will. Im Standardfall gibt es hier keine Historie. Ein Topic wird also nur von denen Empfangen, die zum Erzeugungszeitpunkt auch auf das Topic lauschen.

Schickt jetzt ein Client eine MQTT-Nachricht mit dem Topic a/b/c und ist selber auch darauf registriert. Empfängt er auch seine eigene Nachricht.

Jetzt zu homeeToMqtt.

“homeeStatusRepeat”: true,
“statusTimer”: 180,

Das sind die Konfigurationspatameter ob und wenn ja, wie oft ein Komplettstatus gesendet werden soll. Hat man z.B: eine Node-Red Panel eingerichtet, so würde ohne diese Option das Panel erst aktuell sein wenn sich jeder Sensor mindestens einmal gemeldet hat. Wenn man die Funktion nicht braucht, einfach false setzen.

Der Human Mode existiert um eine Ansicht zu haben die nicht auf den Device Id’s beruht.
Für ein Panel gut, weil lesbare Namen. Zum steuern relativ schlecht, da die Nachricht von homeeToMqtt selber wieder empfangen wird. Deshalb ist ein kleiner Trick implementiert aber leider nicht automatisch vorhanden und im default wohl auch falsch gesetzt ist. Es empfiehlt sich wenn man “subscribeHuman” auf true gesetzt hat “filterEchoedMQTTMessages” auf true zu setzen.

Ich hoffe das hilft.

Ciao
Gido


#108

Danke für die umfangreiche Erklärung. Soweit verstehe ich das oben, dass mqtt-Clients ihre Nachrichten selbst wieder empfangen. Aber warum braucht der “human”-Code diesen filterEchoedMQTTMessages-Mechanismus und der “id”-Code nicht? Wie wird das Echo bei den IDs vermieden?


#109

Nur beim human-mode ist das Topic zum Setzen und für den Status identisch.
Somit subscribed/aboniert hommeeToMqtt im normalen Modus nur die Topics zum Setzen und nicht die für den Status und sieht somit nicht seine eigenen Nachrichten.

Der Human Mode ist auch ein bisschen ein Zugeständnis an die einfachere Einbindung in MQTT- Oberflächen, weil dann das Status setzen und des Wert setzen Topic identisch sind. Dort braucht man dann die Filter Funktion.

Ciao
Gido


#110

@gido jetzt ist es klar. Danke!