LoxBerry MQTT

[Christian Fenzl]

User/Pass für den Shelly ist kein Problem. Die MQTT-Schnittstelle ist nicht davon abhängig, ob du am Shelly angemeldet bist.

Ich habe alles im gleichen WLAN. Im Shelly Support-Forum (Facebook) habe ich schon öfter gelesen, dass manche WLAN-Router bei 100+ Clients Probleme bekommen (egal ob Shelly oder sonstige Geräte). Das war markenabhängig und kann durch Ausbau des WLANs gelöst werden (zusätzliche WLAN-Router).

In einem älteren Performancetest wurde (zwar mit Intel-Hardware) der Mosquitto getestet und hatte bei 60.000 Publishern W.O. gegeben.
Die Latenz überstieg bei 30.000 Publishern knapp 100ms.
Es gab bei dem Test auch noch Issues mit QoS, aber gehen wir davon aus, dass der Mosquitto das in einem EFH wegsteckt.

Einen eigenen Performancetest habe ich nicht gemacht.
Das Gateway und der Miniserver können gut ausgelastet sein, wenn du 30+ Geräte dran hast, die auch regelmäßig senden (was dann aber kaum gleichzeitig passiert). Der Cache des MQTT Gateway fängt einiges ab.
Bei sehr vielen Geräten solltest du dann tatsächlich einen Pi3 oder Pi4 nehmen.

Vielleicht kann sonst jemand mit vielen MQTT-Geräten was zur CPU-Last (mit welcher Hardware?) und Memory Usage von Mosquitto und MQTT Gateway sagen?

[Clubsport]

Hi Christian, kann ich eigentlich auf einen hex-Wert triggern, der als "Value" übertragen wird?
Ich würde gerne IR-Commands dazu nutzen, meinen Mediensteuerungs-Baustein mit meiner (alten) IR-Harmony synchron zu halten. Die IR-Values kommen über Tasmota->MQTT rein.
Meine Idee war irgendwie aus dem Statusbaustein auf dezimale Werte zu wandeln, also z.B. "0x10EFB847" -> "1" und damit auf den "AIm" von der Mediensteuerung.

Grüße, Martin

[Clubsport]

Ich meine damit, wie ich mit einem bestimmten String-Inhalt auf einen bestimmen Modus (Z.B. 4) wechseln kann. Geht doch mMn nur über den Status-Baustein...?

[Christian Fenzl]

Du gehst im Plugin in die Conversions, und gibst ein:
0x10EFB847=4

Über den Status-Baustein geht’s vielleicht auch, das hab ich mit Strings nie probiert.

[Clubsport]

Oh man, da bin ich schlichtweg gar nicht drauf gekommen, hatte mich so auf das HEX versteift..... Na klar, danke, funktioniert!

[SehlingS]

Hey zusammen,

ich habe seit dem Update auf 2.2.0 bzw 2.2.0.3 das Problem, dass sich FHEM nicht mehr per MQTT verbinden kann.
Ich habe jetzt alles mal neu aufgesetzt, aber sobald ich update, springt die Anzeige in FHEM dauernd von online, connceted, connceting hin und her.
Aktuell habe ich nur FHEM und MQTT drauf.
Jemand ne Idee?


Grüße und Danke

[hme0354]

habt ihr mal FHEM upgedated?

[Christian Fenzl]

Bei SehlingS fing das Problem reproduzierbar genau mit der Installation der HABridge an.
Genaueres weiß ich nicht, bzw ob’s Sascha schlussendlich hingebracht hat.
FHEM-Update hat jedenfalls nichts gebracht.
Update der MQTT-Lib, die FHEM nutzt, hat auch nicht geholfen.
Während das MQTT Gateway am Broker connected bleibt, fliegt FHEM sofort raus, als würde es vom Mosquitto sofort gekickt. Auch aus dem Mosquitto-Log haben wir nicht mehr gesehen.

[SehlingS]

Ich hatte immer mein Fhem Backup eingespielt. Ohne diese Backup lief dann alles problemlos.

[KapeOne]

Moin,

bin mir nicht sicher ob das hier oder unter "Caldav-4-Lox" gehört

Hab seit ein paar Tagen das Problem, dass die Einträge, die mit dem Caldav-Plugin geholt werden im MQTT - Plugin unter "incommin..." falsch angezeigt werden.

Im Caldav-Plugin über "Anhabe testen" bekomme ich diese (richtigen) Werte angezeigt:



Unter MQTT bekomme ich dies angezeigt (und natürlich auch an den MS übermittelt):

[KapeOne]

das ist ja auch meine Vermutung - würde aber bedeuten, dass vom Caldav-Plugin nichts mehr beim MQTT ankommt! Wie kann ich das prüfen? Caldav sendet ja meinem Verständnis nach automatisch an das MQTT Plugin - oder?

[Christian Fenzl]

In der Incoming Overview steht hinten, wann das Plugin diesen Wert erhalten hat.
Das sollte genau mit dem HTTP-Abruf übereinstimmen.

[svethi]

Ja, die Werte in der incomming Overview scheinen älter zu sein, oder die Abfrage ist tatsächlich etwas anders. Hast Du genau die gleiche Abfrage benutzt wie der Miniserver das macht? Btw. Wenn Du über die Pluginseite eine Testabfrage ausführst, kommen die Daten auch im MQTT an. Die müsstest Du in der incomming overview sehen

[Clubsport]

Guten Morgen,

seit heute morgen habe ich hier massive Probleme (scheinbar) mit dem MQTT-Gateway, hier geht nichts mehr.... Sitz im Dunkeln und musste erst mal per Web-UI meine Tasmota-Lampen einschalten.

Hardware: Raspberry Pi 3B+
Plugin-Version: V1.1.4

Ich habe das Ganze jetzt insofern einkreisen können, als dass scheinbar alles was "zeitkritisch" ist, vor allem z.B. der Status von Bewegungsmeldern, schlichtweg "verschluckt" wird.
In der Incoming Overview taucht der BWM dann irgendwann einmal Minuten später auf, allerdings nur mit Status "0" - das war definitiv schon mal anders.
Ebenso bei Fensterkontakten, hier kann ich ja das Zeitfenster quasi selbst steuern, keine Statusänderung.

Da dass sowohl Devices betrifft die sich direkt am MQTT-Gateway anmelden (Tasmota z.B.), als auch alles was aus NodeRed heraus sendet, würde ich NodeRed als Übeltäter mal ausklammern wollen.

Der Loxberry wurde schon neu gestartet, ebenso das MQTT-Plugin. Any ideas?

Für den Fall dass die Frage aufkommt ob ich in letzter Zeit etwas geändert habe - nö, lief eigentlich alles reibungslos - bis heute...

Grüße, Martin

[hismastersvoice]

Wenn du auf incoming des Plugin schaust kommt das immer mit Verzögerung.
Nutze ein Tool wie den MQTT Explorer um zu sehen was und wann wirklich passiert.

Mit dem Tool habe ich alle Fehler gefunden die ich bis jetzt hatte (lagen meist an mir)

Bei Win10 gibt es den sogar als App im Store

[Clubsport]

Kannte ich noch gar nicht, schau ich mir mal an!
Bzgl. Incoming Overview: ja das ist mir bekannt dass das mit Delay verbunden ist, dennoch habe ich den Status meiner BWM dort wunderbar checken können.

[Christian Fenzl]

Ein Tool wie der MQTT Explorer eignet sich jedenfalls auch sehr gut, um die Fehlerquelle eingrenzen zu können.
Du verbindest damit direkt zum Broker. Wenn es dort langsam ist, liegt es an Absender->Broker.

Zur Fehlersuche auch immer das Gateway-Log heranziehen. Dort werden Nachrichten vom Broker in Echtzeit geloggt, dafür habe ich den Timestamp auch mit Millisekunden versehen.

[Clubsport]

Ich werde das auf jeden Fall im Auge behalten, jetzt (aktuell) kann ich nicht auf Fehlersuche gehen - nachdem ich hier einmal alles komplett vom Strom hatte, hat es sich im Laufe des Vormittags nach und nach eingependelt.
Ich konnte auch anhand von Lampen, die sich kurz an- und wieder ausgeschaltet haben obwohl ich in dem Moment nicht im Raum war sehen, dass scheinbar alle MQTT-Commands von heute früh "abgearbeitet wurden"....?!?! Sehr merkwürdiges Verhalten!

Wenn es nochmal auftreten sollte, habe ich auf jeden Fall das Tool zur Hand!

[Kerle76]

Hallo,
habe seit dem letzten shelly update auf V1.9.0 auch massive Probleme mit MQTT.
Habe an die 30 shellies per MQTT eingebunden. Lief bis vor dem update einwandfrei (Dank an dieser Stelle Christian Fenzl ).
Danach kam Anfangs überhaupt keine Nachricht mehr rein und auch Schalten etc ging nicht mehr. Habe alles versucht, Neustart aller shellies, loxberry, downgrade shellies. Nix zu machen. Kompletten Abend verzweifelt. Am nächsten Morgen ging wieder alles. Für 2 Wochen. Seit gestern zickt wieder eine shelly bulb duo. gib es doch nicht... Hier ein Auszug aus dem Explorer. Der eine hat nur 4 Messages, die anderen funktionieren wie sie sollen.
Hat hierzu einer eine Idee? Bin für alles dankbar. Immer zu warten bis es wieder geht ohne zu wissen warum es nicht ging ist auch fad

VG Christian

[AlexAn]

Wenn das Problem auftritt sind da die Weboberflächen der Shelly´s verfügbar?

[Kerle76]

Ja, Weboberfläche ist ganz normal verfügbar. Auch über die shelly app lässt sich die bulb ganz normal schalten. Nur eben mqtt funktioniert nicht.

[Kerle76]

hier noch ein Screenshot vom Explorer. Ich weiß auch nicht was das "RETAINED" bedeutet. Steht nur bei dem nicht funktionierenden shelly.

[Christian Fenzl]

Hier beschreibt jemand ein MQTT-Problem mit der 1.9.0:
https://www.facebook.com/groups/Shel...28691/?app=fbl

Zusammengefasst: Der Benutzer hat zwei WiFi-Router, und selbst wenn er einen abdreht, verbinden seine Geräte (1 und Bulb) erst zum anderen Router, wenn er den Schaltereingang betätigt.

Es gibt auch eine neuere Beta-Firmware, die du probieren könntest.

[Kerle76]

Die Beta v1.9.3-rc3 habe ich ausprobiert. Keine Änderung.
Der Kollege von FB hat tatsächlich das identische Verhalten.
Anscheinend gibts aber noch keine Lösung, da eben der neue RC auch nicht funktioniert

Wenn ich genau überlege fing das Problem bei mir auch erst an, als die bulb vom Strom genommen wurde. Dh sie ist eigentlich dauerhaft bestromt. Nachdem sie versehentlich vom Netz genommen wurde, ging mqtt nicht mehr

[AlexAn]

Kerle76 teste mal eine ältere Firmware https://www.shelly-support.eu/index....mware-archive/

[Christian Fenzl]

BTW Das RETAINED bedeutet, dass die letzten Daten am Broker gespeichert bleiben. Wenn Zb das MQTT Gateway neu startet, bekommt es vom Broker die letzten Daten, die das Gerät übermittelt hat. Ohne Retained würde das Gateway erst dann Daten bekommen, wenn das Gerät neue Daten sendet. Die Einstellung ist am Shelly bei den MQTT Settings. Aktiv ist meine Empfehlung.

Das heißt, die Daten die du siehst, könnten schon älter sein, wenn der Shelly nichts mehr sendet.

[Kerle76]

habe jetzt folgende Beobachtung gemacht.
nach Neustart der FB meldet sich keiner der bulb duo via mqtt. Sind auch im Explorer nicht mehr sichtbar.
Wenn es so ist wie beim letzten Mal, kommen sie irgendwann zurück. Aber keine Ahnung warum.

[Kerle76]

Gerade mit shelly support in Kontakt. Die wollten den Status der Geräte wissen. Hier ein Beispiel:

{"wifi_sta":{"connected":true,"ssid":"xxx","ip":"x x.xxx.x.xx","rssi":-63},"cloud":{"enabled":false,"connected":false},"m qtt":{"connected":false},"time":"14:50","unixtime" :1608303015,"serial":14225,"has_update":false,"mac ":"98F4ABD160B6","cfg_changed_cnt":0,"actions_stat s":{"skipped":0},"lights":[{"ison":false,"source":"http","has_timer":false,"t imer_started":0,"timer_duration":0,"timer_remainin g":0,"brightness":75,"white":12,"temp":3156}],"meters":[{"power":0.00,"is_valid":true,"timestamp":16083030 15,"counters":[0.000, 0.000, 0.000],"total":15470}],"update":{"status":"idle","has_update":false,"new _version":"20201124-090917/v1.9.0@57ac4ad8","old_version":"20201124-090917/v1.9.0@57ac4ad8","beta_version":"20201202-135537/v1.9.3-rc3@50c6ab57"},"ram_total":51168,"ram_free":38876, "fs_size":233681,"fs_free":160640,"uptime":849 779}

[Kerle76]

So, das hier die Antwort vom shelly support:
We think that the problem is into your mqtt server. We have not been reported from other customers that they have problem with the bulbs using them with mqtt. Please check your system once again.

Das bringt mich ja wirklich weiter

[Kerle76]

hab ihnen den FB post verlinkt. Hat aber erstmal nicht weiter interessiert...
Das mit der ip ist glaube ich mal in die richtige Richtung. Das habe ich tatsächlich auch gerade ausprobiert und es scheint nach restart der shellies zu funktionieren. Wäre ja echt cool wenn das die Lösung ist. Warum bleibt dann noch zu ergründen.
Bzgl. Deiner Frage, ja ich verwende alles orginal aus Deinem Plugin.

[Christian Fenzl]

Wenn's mit der IP geht, wäre es irgendein DNS-Problem. Das kann dann tatsächlich was in deinem Netzwerk sein, es könnte aber genauso gut ein DNS-Problem in Shelly sein. Du musst schon absolut sicher sein, dass dein Netz "sauber" ist.

[Kerle76]

Natürlich kann immer was sein, aber es lief ja alles ohne Probleme genau bis zu dem Zeitpunkt als ich die shellies auf fw 1.9.0 upgedatet habe. Auf alle Fälle läuft es jetzt wohl. Habe bei allen shellies die IP eingetragen, schadet ja nicht. Muss man sich merken falls andere damit auch Probleme haben.
Danke Euch mal wieder für den support.

[fantomas]

LoxBerry MQTT / Installiert nicht

Ich habe meinen Loxberry neu aufgesetzt, ist derzeit LB v2.2.0.4.Ich wollte das MQTT Plugin installieren, nach aussuchen Archiv und "Installation" drücken kommt nur folgende Meldung:
"Die Log-Datei existiert nicht. Es kann sein, dass das entsprechende Plugin noch nichts sendet oder fehlerhaft ist. Überprüfe noch einmal das ensprechende Log-Datei Verzeichnis: ~/log, ~/webfrontend/html/tmp oder /tmp. Die ~ entspricht normalerweise /opt/loxberry/ wohin auch die Windows-Freigabe zeigt."

Das Plugin installiert nicht und es gibt auch keine (für mich auffindbare) Log mit einer Fehlermeldung.

Kann mir hier jemand helfen?

Thomas

[fantomas]

Hallo Christian, das hat nicht geholfen. Es lässt sich gar kein Plugin mehr installieren, alles bricht mit der gleichen Fehlermeldung ab (das Modbus Plugin habe ich schon installiert und das funktioniert auch..) komisch. Health Check läuft auch OK durch. Kann es irgendwas mit Berechtigungen sein? Wenn die Log nicht geschrieben werden kann? Edit: Der Update Check liefert einen Fehler:

01.01.2021 04:23:23 TASK STARTED
LoxBerry Plugins Update Check
INFO: LoxBerry Version 2.2.0.4 ( is_raspberry.cfg )
INFO: Loglevel: 7
INFO: Version of /opt/loxberry/system/cron/cron.daily/02-pluginsupdate is 2.0.1.1
INFO: Executing user of /opt/loxberry/system/cron/cron.daily/02-pluginsupdate is loxberry
INFO: ModbusGateway: Found plugin Modbus Gateway.
INFO: ModbusGateway: Current version is: v0.0.8
INFO: ModbusGateway: RELEASES enabled.
INFO: ModbusGateway: Requesting release file from https://raw.githubusercontent.com/zm...er/release.cfg
CRITICAL: ModbusGateway: Could not fetch RELEASE file. Error: curl: (23) Failed writing body (0 != 554)
Skipping this plugin...
INFO: Exiting.
INFO: Deleting temporary files.
/opt/loxberry/system/cron/cron.daily/02-pluginsupdate finished.
01.01.2021 04:23:23 TASK FINISHED

[svethi]

Nachdem ich gerade mal nachgesehen habe ob die Datei vorhanden ist, muss ich davon ausgehen, dass Deine Internetverbindung des Loxberry gestört ist.

[fantomas]

@sveti: Habe gerade testweise das letzte commit eingespielt, das ging auch problemlos. Ich hatte auch schon ausprobiert die Datei runter zu laden und über die Datei Funktion zu installieren. Das geht auch nicht...

[Christian Fenzl]

Wurde nach der Installation deine SD schon vergrößert, oder ist die noch auf 4 GB?

[fantomas]

Hallo Christian, ja das Volumen wurde vergrößert.

[Gargamel]

Hallo Christian Fenzl

habe das MQTT Plugin schon länger am laufen und es funktioniert auch einwandfrei. Jetzt habe ich gerade zufällig auf das Logfile geschaut und habe festgestellt das dort ein ERROR ist..

Habe aber keine Ahnung warum das so ist weil ja eigentlich alles läuft. Kann ich das einfach ignorieren oder muss ich was an den Einstellungen vornehmen?
Vielleicht kannst du ja mal drüber schauen..
MQTT Version 1.1.4
Loxberry 2.2.0.4

[Christian Fenzl]

Was ist der DW? Der Temperatur/Feuchte Sensor, oder?
Es kommt da unter sensor/act_reasons eine etwas eigenartige Payload herein

["sensor"]

was offenbar erst als JSON erkannt wird, aber der Datentyp ist ein unindexed Array - da zerlegt es möglicherweise die Json-Expandierung. Das muss ich mir ansehen, scheint ein Bug bei mir zu sein.

Was uns der Shelly mit "Sensor" sagen will, ist mir unklar. Das error-Topic davor ist jedenfalls 0.

Weißt du, was act_reasons ist?

[Christian Fenzl]

Nein, erstmal ein Bug im Gateway.
Aber mich würde natürlich interessieren, was Shelly da sendet.

[Gargamel]

Alles klar..

Dann lass ich es jetzt erstmal einfach so weiter laufen oder?

[Christian Fenzl]

Ja, kannst du so laufen lassen. Das Gateway läuft weiter, nur dieser Datensatz wird nicht ausgewertet. Evt. hab ich heute die Gelegenheit, das gleich zu fixen.