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
@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).
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.
Ja genau das ist das Problem, wenn der MQTT nicht ordentlich konfiguriert ist.
Kenne ich auch zu gut.
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.).
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
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?
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
Hallo,
ich bräuchte mal ein bisschen Hilfe bei MQTT über Node-Red und Homee.
Ich habe einen Raspi mit homeetoMQTT und Node-Red eingerichtet. Bei Node-Red habe ich auch den homee Plugin installiert (alles über Homeean). Im Flow habe ich alles eingerichtet, im Homee einen extra User eingerichtet. Im Flow sind homee und MQTT connected.
Jetzt hätte ich gerne von Node-Red zum Homee eine Statusmeldung gesendet. Irgendwie stehe ich auf dem Schlauch, wie ich das einrichten muss. Mit den Beispielen komme ich irgendwie nicht klar. Kann mir da jemand ein paar Tipps geben?!
Vielen Dank,
Steffen
Du hast da was falsch verstanden.
Entweder das eine oder das andere nehmen.
homeetomqtt sagt ja der Name schon da wird mit den State gearbeitet und alles über MQTT erreichbar und ansprechbar.
Node Red homee ist ein Knoten für Node Red
Hier kannst du dann alle Aktionen in Node red darstellen und auch Aktionen ausführen.
VG Micha
Hallo Micha,
vielen Dank. Dann versuche ich das mal mit dem Plugin für Node Red.
Ich werde berichten.
Jetzt läuft’s wie es soll. 
Werde mal unter “Stories und Projekte” ein neues Thema erstellen.
Vielleicht hat ja jemand Interesse an meiner Lösung.
Hallo zusammen,
ich habe über homeean den homee-to-mqtt und homeeup installiert. Wenn nun die Abfrage on homee-to-mqtt im Logfile läuft, folgt unmittelbar nach deren Ende ein Aufruf an homeeup, der die beiden angelegten SimpleHTTPPlugin auf aus setzt und damit die entsprechenden Aktionen auslöst.
EDIT: Manche ZigBee Lampen, werden dann auch eingeschaltet.
Sobald ich den homee-to-mqtt service stoppe, passiert auch nichts mehr…
Habt ihr eine Idee warum das so ist und wie ich das unterbinden kann?
Gruß
Sascha
Morgen @sr1,
homee wird nur beim Start von homeetomqtt abgefragt.
Es besteht eine aktive Verbindung zu homee und die Änderungen die über die api erfolgen werden an den MQTT Broker weitergeleitet.
Wenn der Broker falsch eingestellt kommt es zu den von dir beschriebenen Problemen.
Wenn du in homee einen extra User angelegt hast, dann kannst du das im Tagebuch verfolgen.
homeeup mit dem SimpleHTTPPlugin hat ja grundsätzlich nichts mit MQTT zu tun.
Wie stellst du hier eine Verbindung her ?
VG Micha
HI @Micha,
der Tipp mit dem Tagebuch war gut. Ich habe für den homeean-to-mqtt einen eigenen User angelegt und der schaltet tatsächlich die Geräte (ZWave, ZigBee und die homeeup CCU).
Bei ZWave passiert dabei nichts und nur die ZigBee und virt. CCU Geräte reagieren von homee aus.
Beim homee-to-mqtt habe ich aktuell erst mal nur die config.json um die homee-IP, sowie User und Passwort ergänzt - sonst nichts. Wo könnte da der (mein?) Fehler liegen?
VG Sascha
Es liegt an der Konfiguration des Broker und nicht an homeetomqtt.
Hier musst du mal schauen ob der Broker auf Werteänderungen reagiert.
Der Broker darf nur die Werte empfangen.
Welchen Broker hast du im Einsatz?
VG
Von homeean wird als Broker der Mosquitto installiert.
Der läuft mit der homeean-Standard-Konfig. Ich lese ich hier gerade ein, habe aber noch keine Idee woran das liegt.
Kannst Du mir einen Tipp geben, @Micha?!
VG
@Micha: Wenn es an der Standardkonfiguration liegt, dann lass es uns wissen und wir ändern die Config über den Installer…
@sr1 @hblaschka , kann mit einer mal die config zusenden ?
Da ich alles händisch installiere liegt mir die config nicht vor…
VG