LoxBerry MQTT

[Christian Fenzl]

Ich hab auch noch nicht herausgefunden, warum Mosquitto nicht startet - bei mir hat der Dienst dann funktioniert, nachdem ich ihn in meinem Daemon-Script beim Boot einfach restarten lasse.

Der Restart-Button im WebIf macht übrigens nichts mit Mosquitto, sondern startet nur mein Gateway neu.

Wenn ich an der Shell dann mit systemctl restart mosquitto neu gestartet hatte, funktionierte mosquitto immer. Vielleicht ein Timing-Problem mit dhcp, aber es steht nirgends etwas im Log.

Mosquitto wird ganz normal über Raspbian installiert, ich greife dessen Config nirgends an, deswegen ist das sehr dubios. Eine Plugin-Neuinstallation hilft da deswegen auch garnichts, da das Plugin Mosquitto via apt installiert, und das passiert nur einmalig.

[Christian Fenzl]

Das muss ich mal probieren: https://github.com/eclipse/mosquitto/issues/882
Es scheint ein gängiges Issue zu sein, dass Mosquitto nicht automatisch startet...

[Imperator]

Hi,

ich hab ein MQTT-Gateway als Prototype am Laufen, dass sich am Broker anmeldet und Topics subscribed.

Auf deutsch - ich bekomme die Zustände von Shelly rein.

Derzeit schick ich das ganz einfach per UDP an den MS.

Gibt es was, was ein MQTT-Gateway sonst noch können soll?

Ich fange erst gerade an mich sowohl mit Loxberry als auch mit MQTT zu befassen. Wenn ich es aber richtig verstanden habe, so könnte dieser MQTT Gateway z.B. auch für Zigbee2MQTT (https://github.com/Koenkk/zigbee2mqtt) verwendet werden. Das wäre für mich hoch interessant um beispielsweise die Philips Hue Komponenten direkt und nicht über die Hue Brdige anzusteuern. Dadurch könnte man womöglich ein besseres Handling machen, da der MS den jeweiligen Status kennt.

[Imperator]

Leider scheitere ich bereits bei der Inbetriebnahme von Zigbee2MQTT auf Loxberry. Wenn ich es dies richtig interpretiere, scheint dies mit den Berechtigungen zu tun zu haben, da User&Gruppe Pi auf Loxberry nicht existieren. Ich habe mein Problem direkt im Github Projekt geschildert. Falls sich jemand hier im Loxforum dafür interessiert: https://github.com/Koenkk/zigbee2mqt...ment-439239680

[Christian Fenzl]

chmod -R 777 /opt/zigbee2mqtt

Wenn du das aber versehentlich auf /opt/loxberry (oder einfach auf /opt) machst, ist der Spaß vorbei.

[Imperator]

Vielen Dank Gast Fenzl! Das hat wunderbar funktioniert. Jetzt konnte ich Zigbee2MQTT erfolgreich in Betrieb nehmen und bekomme die Messages in Deinen MQTT Gateway! Hier ein Beispiel der Messages:

23:13:19.944 INFO: zigbee2mqtt/0x0017880102d48aad: {"action":"on","linkquality":39}
23:13:23.063 INFO: zigbee2mqtt/0x0017880102d48aad: {"action":"off","linkquality":44}
23:13:27.177 INFO: zigbee2mqtt/0x0017880102d48aad: {"action":"up-press","brightness":255,"linkquality":39}
23:13:30.136 INFO: zigbee2mqtt/0x0017880102d48aad: {"action":"down-press","brightness":205,"linkquality":13}
23:13:35.858 INFO: zigbee2mqtt/0x0017880102d48aad: {"action":"up-press","brightness":255,"linkquality":39}
23:13:36.662 INFO: zigbee2mqtt/0x0017880102d48aad: {"action":"up-hold","brightness":255,"linkquality":42}
23:13:37.466 INFO: zigbee2mqtt/0x0017880102d48aad: {"action":"up-hold","brightness":255,"linkquality":39}
23:13:38.271 INFO: zigbee2mqtt/0x0017880102d48aad: {"action":"up-hold","brightness":255,"linkquality":39}
23:13:38.423 INFO: zigbee2mqtt/0x0017880102d48aad: {"brightness":255,"action":"up-hold-release","linkquality":39}
23:13:47.805 INFO: zigbee2mqtt/0x0017880102d48aad: {"action":"down-press","brightness":205,"linkquality":36}
23:13:48.608 INFO: zigbee2mqtt/0x0017880102d48aad: {"action":"down-hold","brightness":205,"linkquality":31}
23:13:49.413 INFO: zigbee2mqtt/0x0017880102d48aad: {"action":"down-hold","brightness":125.2,"linkquality":31}
23:13:50.217 INFO: zigbee2mqtt/0x0017880102d48aad: {"action":"down-hold","brightness":45.10000000000001,"linkquality" :34}
23:13:50.318 INFO: zigbee2mqtt/0x0017880102d48aad: {"brightness":32.400000000000006,"action":"down-hold-release","linkquality":31}

23:29:29.224 INFO: zigbee2mqtt/0x0017880102d48aad: {"battery":100,"linkquality":97}

Hierbei handelt es sich um einen Philips Hue Dimmer Switch der mit Zigbee2MQTT gepaired wurde. Voraussichtlich morgen kümmere ich mich um die Übermittlung der Messages in den MS. Bin noch nicht sicher ob ich dies mit UDP oder HTTP realisieren soll. Vielleicht experimentiere ich einfach mit beiden Varianten oder falls hierzu jemand einen guten Tipp hat, bitte her damit

[Christian Fenzl]

Bezüglich "Mosquitto startet nicht":
Ich finde nicht heraus, warum er nicht automatisch startet. Ich werde meinen Daemon nochmal erweitern, dass er einfach solange probiert, bis er läuft. Für mich schaut das nach einem Timing-Issue in der Boot-Sequenz aus.

Bezüglich "Authentifizierung":
Ich hätte das gestern implementiert, aber die MQTT-Library liefert mir bei Authentifizierung einen Fehler. Ich hab Mal den Entwickler angeschrieben, ob er vielleicht weiß, was da schief läuft, das kann aber entweder länger dauern, oder es kommt gar nichts zurück.
Im schlimmsten Fall müsste ich die Lib wechseln, das hab ich aber nicht kurzfristig geplant.

[AlexAn]

Mit

systemctl restart mosquitto
in der Shell läuft es per UDP 1A inkl. Leistung bei der Shelly2!

Virtueller Eingang: shellies_shelly1-IDderShelly_relay_0




Leistung Shelly2 per Virtuellen Eingang: shellies_shellyswitch-IDderShelly_relay_power





Virtuelle Eingänge zum Kopieren:

shellies_shelly1-IDderShelly_relay_0

shellies_shellyswitch-IDderShelly_relay_0
shellies_shellyswitch-IDderShelly_relay_1
shellies_shellyswitch-IDderShelly_relay_power

Die ID der Shelly ist ein Bestandteil der MacAdresse:

[Christian Fenzl]

Du hast übrigens beides ein: Das unten kommt per UDP, der virtuelle Eingang oben wird mit HTTP befüllt.
Und die Device-ID die du links und unten maskiert hast, steht rechts auch nochmal ;-)

[AlexAn]

Ja weil ich die Kommandos vom UDP Eingang für die Leistung abgeleitet habe. Schalte ich dann natürlich wieder ab.
Ups..

wenn ich nach nach deiner ausführlichen kommentar alles machen bekomme ich keine 1 oder 0 sonder open close oder stop

[svethi]

Ist das wieder ein Dienst der bei Neustart nicht hochkommt weil das Netzwerk noch nicht voll hochgefahren ist?

[Christian Fenzl]

Das kann gut sein! Der Mosquitto öffnet sich ja In-Ports, vielleicht ist dieser Dienst hier nicht fail-safe.
Es kommt per apt auch keine "echte" systemd Servicedatei, sondern es wird ein init-Script via Systemd gestartet.

[svethi]

Wir hatten doch letztens auch erst so einen Fall und haben denn noch eine neue Abhängigkeit eingefügt. Vielleicht muss die da auch einfach nur rein. Ich komme aber grad nicht mehr drauf in welchem Zusammenhang das war.

[Christian Fenzl]

MQTT Gateway V0.1.3 - DEVELOPER PREVIEW

https://www.loxwiki.eu/display/LOXBERRY/MQTT+Gateway

Ich habe jetzt doch die Authentifizierung für MQTT Broker hingebracht (der Fehler war doch nicht in der Lib sondern am Keyboard), außerdem habe ich den Daemon so angepasst, dass er so lange versucht, den Mosquitto zu starten, bis er wirklich läuft (Retry für maximal für 2 Minuten).

Wenn ihr irgendwelchen anderen Devices außer Shelly's habt, wäre spannend, ob das klappt, und wenn ja, wenn ihr das in die Tabelle im Wiki eintragen könntet.
Die Auth habe ich jetzt nur mit meinem lokalen Mosquitto getestet, auch hier freue ich mich über Feedback, ob es auch gegen Remote-Broker funktioniert.

lg, Christian

[hagor]

Hab es bei mir laufen und muss sagen funktioniert soweit super in beide Richtungen.

Authentifizierung in einem Remote-Broker funktioniert auch ohne Probleme. Ich hab jetzt gar nicht gecheckt ob das mit dem starten beim lokalen Mosquitto bei mir wieder funktioniert ;-)

Sobald mehr als nur ein einzelner Wert im Data-Bereich stehen kommt man halt nicht um UDP rum. In meinem Testfall wird JSON ausgeliefert, da spielt der VI leider nicht mit.

[Christian Fenzl]

Das mit JSON ist natürlich blöd. Kannst du mir so ein json schicken? Würde mich interessieren, welche Komplexität an Daten da so „herumgeschleudert“ wird.

[hagor]

Klar, hab die Info auch schon im Wiki eingetragen.
Das JSON das daher kommt sieht so aus:

{"id":"12:34:56:78:9a:bc", "retained":"true", "version":"0.1.675", "confidence":"100","name":"Phone","timestamp": "Fri Nov 16 2018 08:01:06 GMT+0000 (UTC)","manufacturer":"Phone company","type":"KNOWN_MAC","rssi":""}

Das Plugin macht daraus:

MQTT: monitor/first_floor/12:34:56:78:9a:bc={"id":"12:34:56:78:9a:bc", "retained":"true", "version":"0.1.675", "confidence":"100","name":"Phone","timestamp": "Fri Nov 16 2018 08:01:06 GMT+0000 (UTC)","manufacturer":"Phone company","type":"KNOWN_MAC","rssi":""}

Und die Befehlserkennung für die Confidence schaut dann so aus:

MQTT: monitor/first_floor/12:34:56:78:9a:bc=\i"confidence"\i:"\v

Ist für die Anwesenheitserkennung via Bluetooth mit dem Script von hier

[hagor]

Eine Möglichkeit um die Last für die UDP Befehlserkennung etwas zu mindern wäre, ein optionaler eigener Port für Topics.
Führt aber zu mehr Komplexität im Plugin und mehr VUIs.

[Christian Fenzl]

Der Schlüssel kommt also im Topic mit (12:34:56:78:9a:bc)?
Hat das eine Bewandnis, dass die MAC im Topic unterschiedlich zur ID im json ist? (Typo oder?)

Ich hätte kein Problem damit, das json auch noch zu zerlegen und per http-rest zu schicken.

Der virtuelle Eingang müsste dann heißen:

monitor_first_floor_12:34:56:78:9a:bc_retained

Mit der Boolean-Conversion würde dann als Wert 0 oder 1 reinkommen.

Macht das Sinn?

[hagor]

Ja genau, der Schlüssel ist im Topic.
War ein Fehler meinerseits, dass die MACs unterschiedlich waren. Habs grad ausgebessert :-)

Eigentlich auch eine gute Idee das JSON direkt zu zerlegen und weiterzuleiten. Potentiell sind das dann zwar einige http-rest calls aber zielgerichtet.
Das macht auf jeden Fall Sinn

[Christian Fenzl]

Die LoxBerry-SDK-Sendefunktion sendet sowieso nur Änderungen, und ich habe auch noch in der Queue, zur erleichterten Einrichtung alle Topics/Values, die weitergereicht wird, lokal vorzuhalten und als Liste für Copy/Paste anzuzeigen. Da ich den Response-Status des HTTP-Requests an den Miniserver kenne (ich weiß nach einem Sendevorgang also, ob es den virtuellen Eingang überhaupt gibt), ist es auch einfach, nicht existierende Virtuelle Eingänge einfach kein weiteres Mal zu übertragen.

Das mit dem JSON schau ich mir am Wochenende an.

Heute vorm Frühstück habe noch ein generisches HTTP->MQTT publish über das Gateway implementiert:

http://<lbuser:lbpass>@loxberry/admin/plugins/mqttgateway/mqtt.php?topic=shellies/shellyswitch-32BA7F/relay/1/command&value=on

Damit könnte jedes Device, das HTTP-Requests senden kann, z.B. den Shelly einschalten, und wenn im Gateway shellies/# abonniert ist, geht der Status via Gateway auch an die Loxone.

Gestern Abend hab ich mich (mangels anderer MQTT-Geräte) noch etwas gespielt, und für FHEM eine einfache Config erstellt, die alle FHEM-Readings an den MQTT-Broker published: https://www.loxwiki.eu/display/LOXBE...gs+weitergeben
Das ist beispielsweise in meiner Konfiguration ganz praktisch, wo ich per EnoceanPi in FHEM die Enocean-Fenstergriff-Stati "einsammle".


Ich glaub, ich hab mit MQTT jetzt endlich die Schnittstelle gefunden, mit der ich standardisiert Geräte verbinden kann. "Ich liebe es!" :-)

[hagor]

Guter Punkt mit den Änderungen.Damit wäre das eh eine optimale Lösung ohne nutzlosen Traffic.

Na du bist ja produktiv vor dem Frühstück :-)
Das ist eine richtig gute Möglichkeit per HTTP was in die Queue zu bekommen.

Wenn man erst mal auf den Geschmack gekommen, dann will man MQTT nicht mehr hergeben ;-)
Da fällt mir ein, ich hab irgendwo noch ESP8266 Sensorplatinen rumliegen die MQTT sprechen, mal schauen ob ich da nicht auch wieder eine Verwendung finde :-D

[Imperator]

Ich glaub, ich hab mit MQTT jetzt endlich die Schnittstelle gefunden, mit der ich standardisiert Geräte verbinden kann. "Ich liebe es!" :-)

Ganz so weit bin ich noch nicht ganz, aber ich sehe eine grosse Gefahr, dass ich in Kürze dasselbe sagen könnte ....

[AlexAn]

Hab gerade mit dem1.3er nach 2 Minuten den Mosquitto manuell in der Shell starten müssen.
Plugin sauber deinstalliert neu gebootet und neu installiert/neu gebootet.
Hab ich was übersehen??

[Christian Fenzl]

Wie bereits gesagt, eine Neuinstallation des Plugins ist bezüglich Mosquitto unerheblich, weil der deswegen trotzdem nicht neu installiert wird.
Ich kann die Zeit noch höher setzen.

Der Mosquitto Start-Retry ist leider nicht in diesem Log, weil das woanders passiert. Mosquitto selbst schreibt überhaupt kein Log, warum er nicht startet, und Systemd sagt nur, "hab ihn eh gestartet, was er dann tut, geht mich nichts an".
Definitiv dauert es eine Zeit (sehe aber, du hast schon ziemlich lange gewartet). Das Webinterface ist viel früher Online als die Dämons.

[Christian Fenzl]

PS: Du hast sogar ZIEMLICH lange gewartet - weil mein Daemon erst NACH dem Mosquitto gestartet wird, oder eben nach Ablauf der 2 Minuten. Wenn im WebIf die PID meines Gateway grün wird, aber Mosquitto noch länger als 10 Sekunden rot bleibt, ist es also "schon vorbei".
Ich mach die Zeit noch länger, aber ich weiß nicht mal, was ich loggen soll, weil ich absolut keine Infos vom Start bekomme. Blöder Dienst...