Tweet
Kannst ja mal versuchen abzuschalten, dass JSON‘s aufgeschlüsselt werden
-
Miniserver; KNX; Vitogate; EnOcean (EnOceanPi); Loxone Air; Caldav-Kalenderanbindung; RaspberryPi und für keine Frickellösung zu schade :-) -
Hallo und erst mal großen Dank an Christian! Es sind viele neue Features dazugekommen - und schneller gehts jetzt auch
))
Im Thread #125 wurde schon mal das "Do not Forward" Feature behandelt. Wie sinnvoll ist es eigentlich alle gelb markierten ("Not found") Nachrichten zu deaktivieren? Was ist z.B. mit den HASH- bzw. KeepAlive-Subscriptions?
Link zum Thread #125: https://www.loxforum.com/forum/proje...294#post314294
Vielen Dank für die Rückmeldung
Grüße ChrisKommentar
-
Moin,
hatte heute einen Segfault des MQTTGateways:
Mosquitto selbst war OK, nur der MS selbst bekam nix mehr geliefert.Code:root@Loxberry:/opt/loxberry/log/plugins/mqttgateway# journalctl | grep -i mqtt Sep 24 10:49:04 Loxberry kernel: mqttgateway.pl[1103]: [COLOR=#e74c3c][B]segfault[/B][/COLOR] at 2 ip 0000562d3380598e sp 00007fff14945e98 error 4 in perl[562d3379e000+15e000] root@Loxberry:/opt/loxberry/log/plugins/mqttgateway#
Zur Uhrzeit des Segfaults habe ich nix gemacht, die letzte Änderung von mir waren ein paar einfache Subscription Filters, vmtl war das am 14.09.21...
Der Button Restart im Plugion hat geholfen, Gateway lief dann wieder.
Lief sonst sehr gut, incl S4L, Danke!Kommentar
-
Ich habe ein ähnliches Problem.
Bei mir hört das MQTT Gateway einfach irgendwann auf zu laufen.
Hatte das jetzt 2 mal nach jeweils ca. 10 Tagen.
Das Log ist leider nicht aussagekräftig. Ich werde wenn des Prozess das nächste mal nicht mehr läuft auch mit journalctl grep -i mqtt schauen was dort steht.
im Moment steht dort nur mein Restart von gestern aben drin.
Aktuell sehe ich nur im mqttgateway.log das gestern um 17.07 die letzte Meldung ankam und mein drücken des Restart Buttons um 22:27 das Problem behoben hat.
Mosquitto und der Rest der Loxberry laufen problemlos weiter.
Das Problem hatte ich früher nicht.
Sprich es muss durch irgendein update mit rein gekommen sein.
Jemand ne Idee?Zuletzt geändert von SehlingS; 29.09.2021, 08:11. Grund: ERGÄNZUNG AUSGABE "journalctl grep -i mqtt"
-
-
Kommentar
-
Hallo,
sollte in v2.0.4 der MQTT Gateway Dienst (/mqttgateway.pl) automatisch mit dem Loxberry starten?
Nach einem Neustart gestern (hätte also genug Zeit gehabt) ist mir aufgefallen dass der Broaker nicht funktioniert. Heute gesehen dass MQTT GW nicht läuft. Der Mosquitto aber schon.
Mit dem "Restart" button startet der GW Dienst problemlos.
Wie wird denn der Dienst normal gestartet? In welchem log fände ich warum der ned automatisch startet? (im mqtt log steht nach dem loxberry start garnix. erst mit start von /mqttgateway.pl steht da zumindest dass der gestartet ist. Hilft aber ned weiter
)
Kommentar
-
Der Dämon erzeugt ein daemonstart.log - das müsste im Log Manager unter „Weitere Logfiles“ aufscheinen.
lg, ChristianHilfe für die Menschen der Ukraine: https://www.loxforum.com/forum/proje...Cr-die-ukraineKommentar
-
Hmm. Im Log Manager scheint nichts auf.Der Dämon erzeugt ein daemonstart.log - das müsste im Log Manager unter „Weitere Logfiles“ aufscheinen.
lg, Christian
Per SSH evenfalls nix gefunden.
In "/opt/loxberry/log/plugins/mqttgateway/" gibts nur das mqttgateway.log und mosquitto.log.
Zur Sicherheit ein find ausgeführt (root@loxberry:/# find / -type f -name "daemonstart.log") ohne Ergebnis.Kommentar
-
Houseruckiii
SehlingS
@BlScOfDe
Leider kann ich nicht beantworten, warum ihr kein Log beim Systemstart durch den Daemon bekommt -
entsteht ein Log, wenn du manuell als root
/opt/loxberry/system/daemons/plugins/mqttgateway
aufrufst?
Dieses Log MUSS beim Start erzeugt werden, denn wenn nicht, dann läuft der Daemon garnicht. Das erste, was das Daemonscript macht, ist eine Zeile in dieses Log zu schreiben.
Absolut kann ich nicht beantworten, warum ein Segmentation Fault kommt (Perl erlaubt gar keine eigene Speicherverwaltung im Code, in der ich durch falschen Speicherzugriff einen Crash auslösen könnte). Perl ist so alt, dass es so "gereift" ist, dass das sehr sehr seeehr selten ist, und oft eher am Speicher selbst (oder Strom) liegt als an Perl. Die Segfault Meldung, die oben gepostet ist, sagt jetzt auch nicht wirklich was aus, ob vielleicht irgendeines der verwendeten Perl-Module da was verhaut.
Außerdem fällt mir kein Grund ein, warum das Gateway nach ein paar Tagen nicht mehr läuft. Selbst wenn das Programm durch einen Runtime Fehler beendet wird, schreibt es noch ein "MQTT Gateway exited" danach ins Log. Bei einem SegFault allerdings nicht mehr (das ist dann richtig tot).
Was ich aber machen kann, ist, den Healthcheck, der jetzt schon täglich von LoxBerry ausgeführt wird und das Gateway prüft, als zusätzlichen Prozess laufen zu lassen, und dort zu versuchen, das Gateway wieder zu starten, sollte es nicht mehr laufen (sowas wie ein Heartbeat).
Oder zweite Idee, das MQTT als systemd Dienst zu starten, dann kümmert sich systemd um den Restart im Fehlerfall. Dann würde dort vielleicht auch mehr im systemd Log stehen.
Bitte stellt aber wirklich erst mal sicher, dass ihr keine Stromprobleme habt (LoxBerry Selbsttest zeigt das nach längerer Laufzeit auch rückwirkend an, solange ihr nicht rebootet).
lg, Christian
Hilfe für die Menschen der Ukraine: https://www.loxforum.com/forum/proje...Cr-die-ukraineKommentar
-
Moin Christian,
ich habe meinen Healthcheck nochmals angeschaut.
Alles grün bzw blau bei eine Laufzeut von 15 Tagen. Sprich das Netzteil würde ich ausschließen.
Aktuell läuft auch noch alles einwandfrei. Ich hatte die beiden Ausfälle jeweils nach ca. 10 Tagen.
Was mir aufgefallen ist (vermutlich nichts besonderes ;-)) Der PID war anafang bei ca. 1.000 für den Prozess. 10 Tage später nach meinem manuellen Restart bei 21.000. Sprich es müssten ja in der Zwischenzeit 19.000 Prozesse gestartet und wieder beendet worden sein.
Mir gefallen deine beiden Ideen. Beide würden zwar nur die Ursache beheben, aber alle 10 Tage mal ein automatischer Neustart des Gateways macht ja nichts. Das 1Wire Plugin macht das ja auch schon mit einem Healthcheck.
Ich habe den Pi wirklich schon lange am laufen. Aber das mit MQTT ist erst seit ca. 25 Tagen. Muss also mit irgendeinem Update eine Plugins oder des Loxberrys zusammen hängen.
Was jedoch auch seltsam ist, dass bei 2143 Installationen, sich nur 2 melden, bei denen der Prozess stoppt.
Grüße und auf jeden Fall schon mal vielen Dank für deine Ideen und Mühen.
Sascha
-
-
Hi,
ich nutze das Modul schon seit mehreren Jahren und es hat immer alles funktioniert. Heute wollte ich ein Shelly 1 und ein Shelly RGBW2 einbinden. Insgesamt habe ich von diesen Geräten mehrere im Einsatz (knapp 40 Stück) und alle funktionieren ohne Probleme.
Leider schaffe ich es nicht die beiden "neuen" in den Broker zu bekommen. Die schicken keine Daten und erhalten auch keine. Im Broker kommen die Nachrichten für die beiden neuen Shelly´s aber an, sie schalten aber nicht.
Habt ihr eine Idee wo ich noch suchen könnte? Was ich bereits gemacht habe:
- Shelly´s Zurücksetzen
- MQTT neu Starten
- Loxberry neu Starten
- ca. 10x MQTT Einstellungen neu eingetragen
Alles ist gleich wie bei meinen anderen (Shelly 1, 1PM, Button, RGBW2, 2.5) und die funktionieren.
Der Loxberry läuft auf einem QNAP (unverändert seit min. 1 Monat). Alle Updates durchgeführt (MQTT in Version 2.0.4)
Danke im Vorraus, LG ChrisuZuletzt geändert von chrisu159; 30.09.2021, 00:21.Kommentar
-
Wenn die Nachrichten von den Shellies im Broker ankommen, funktioniert der Broker und auch die Shellies. Dann hast Du etwas nicht richtig konfiguriert. Mit Deinen Infos kann man aber auch nichts weiter sagenMiniserver; KNX; Vitogate; EnOcean (EnOceanPi); Loxone Air; Caldav-Kalenderanbindung; RaspberryPi und für keine Frickellösung zu schade :-)Kommentar
-
Ich habe jetzt in den Details in der Incoming overview bei Last arrived einen Fehler gefunden: "MS1: HTTP 404 Input not available". Dieser Eintrag kommt wenn ich von Loxone das Shelly1 schalten möchte. Ich habe das Shelly gerade nochmal komplett zurückgesetzt.Kommentar
-
Hi,
(alles über ssh)
wenn ich den Prozess beende und neu starte, wird ein daemonstart.log erzeugt.
Hier meine Schritte
Code:loxberry@loxberry:~ $ ps waux | grep mqtt loxberry 1537 4.1 1.5 38884 31888 ? S Sep28 104:51 /usr/bin/perl /opt/loxberry/bin/plugins/mqttgateway/mqttgateway.pl loxberry@loxberry:~ $ kill -9 1537 loxberry@loxberry:~ $ /opt/loxberry/system/daemons/plugins/mqttgateway 1533 Password: loxberry@loxberry:~ $ ps waux | grep mqtt loxberry 29923 39.6 1.5 41856 32208 ? S 10:28 0:08 /usr/bin/perl /opt/loxberry/bin/plugins/mqttgateway/mqttgateway.pl loxberry@loxberry:~/log/plugins/mqttgateway $ ls -la total 20 drwxr-xr-x 2 loxberry loxberry 4096 Sep 30 10:28 . drwxr-xr-x 6 loxberry loxberry 4096 Sep 28 16:05 .. -rw-rw-rw- 1 loxberry loxberry 343 Sep 30 10:28 '20210930_102807_990_Update Configuration.log' -rw-r--r-- 1 loxberry loxberry 151 Sep 30 10:28 daemonstart.log lrwxrwxrwx 1 root root 32 Sep 28 16:08 mosquitto.log -> /var/log/mosquitto/mosquitto.log -rw-rw-rw- 1 loxberry loxberry 622 Sep 30 10:28 mqttgateway.log loxberry@loxberry:~/log/plugins/mqttgateway $ cat daemonstart.log MQTT Gateway Daemon start Running updateconfig.pl to query json Result is 1 Try {1...100}: Checking if Mosquitto is running... Starting mqttgateway.pl
Wie sollte das Skript denn überhaupt nach dem Booten gestartet werden? Wenn ich die Routine kennen würde könnt ich dem gezielter nachgehen.
Falls es irgendwie relevant ist. Loxberry läuft als VM auf einer Synology.
Kommentar
-
@BlScOfDe
Es gab eine Änderung beim Startup von Daemons und Cronjobs mit 2.2.1:
Startup behaviour of daemons and cronjobs
Die Daemons werden im Zuge des LoxBerry systemd Dienstes gestartet, der Code ist hier:
Bei einem Fehler dieser Routine würden wahrscheinlich gar keine Plugin-Daemons starten.
Einen Log-Output schreiben wir dort aber nicht in ein File, und ich weiß nicht, ob der Output "Preparing Plugin Daemons..." bzw. "Running ......." irgendwo in journald protokolliert wird.
Hilfe für die Menschen der Ukraine: https://www.loxforum.com/forum/proje...Cr-die-ukraineKommentar
-
Danke für den Tipp.@BlScOfDe
Es gab eine Änderung beim Startup von Daemons und Cronjobs mit 2.2.1:
Startup behaviour of daemons and cronjobs
Die Daemons werden im Zuge des LoxBerry systemd Dienstes gestartet, der Code ist hier:
Bei einem Fehler dieser Routine würden wahrscheinlich gar keine Plugin-Daemons starten.
Einen Log-Output schreiben wir dort aber nicht in ein File, und ich weiß nicht, ob der Output "Preparing Plugin Daemons..." bzw. "Running ......." irgendwo in journald protokolliert wird.
Nach dem Update auf 2.2.1.2 startet der MQTT GW Dienst zuverlässig (nach so 10-15 Sek.) (2x neu gestartet zum testen).
Was es auch war, es ist nun behoben.
Off Topic.
Guter Humor
Kommentar
Kommentar