MQTT-Störung auf dem Raspi3, dadurch SML-Fehler sowie Gosund Steckdosen Fehler

    Hallo,

    ich betreibe einen Raspi 3 mit der Software "Buster", halte den auch immer relativ aktuell! Darauf läuft auch mein IOBroker und ein MQTT Server.

    Ziel des ganzen ist Verbrauchsdaten und Wetterdaten zu sammeln und mit Grafana auszuwerten/ansehen!

    Auf einem esp8266 NodeMCU läuft mein Verbrauchsdatensammler für Strom "SML", Gas "Counter"und Wasser "Counter" sehr gut, eigentlich Problemlos!

    Mehrere Gosund SP1 Steckdosen mit Tasmota

    Doch immer nach ein paar Tagen hat mein MQTT Server scheinbar ein problem.

    Meine Lösung bisher war jeden Tag den Raspi über ein Crontab neu zu starten, bringt aber nicht die Lösung da es trotzdem auch dann mal an einem Tag zur Störung kommt.


    Jetzt bin ich nicht der beste in Sachen Fehlersuche auf dem Raspi, evtl. können wir gemeinsam was finden um das Problem auszumerzen

    • alle Gosund Steckdosen mit "Tasmota Firmware 8.1.0.9" blinken blau
    • mein esp8266 NodeMCU "Tasmota Firmware 8.4.0.2" zeigt in der Konsole auch MQTT Fehlermeldungen
    • Konsole des Node MCU:

    In Sachen "SML" läuft die Sache mit dem Treiber von gemu2015 , aus diesem Beitrag ,daran liegt es aber wahrscheinlich nicht.

    Hat von Euch jemand eine Idee wie ich den Fehler finden kann?

    Hallo JoergZ,

    ja die Daten zum MQTT Server stimmen (IP, Port), kommen ja auch immer an.

    Ja die IP vom Raspi ist die 192.168.56.150:1883.

    Das komische ist ja manchmal läuft es fast eine Woche ohne Fehler, da ich ja alle 24 Stunden einen Reboot mache,
    doch trotzdem passiert es wie heute dass der MQTT Server nicht erreichbar ist.

    Mein MQTT Server auf dem IOBroker ist:

    Versuche beim nächsten Störfall mal die Fehlermeldung einer Gosund Steckdose aus der Konsole zu kopieren!

    Die Frage ist auch warum sich dieser MQTT Server aufhängt,

    • nach einem Reboot geht es sofort,
    • ganz hart auch am Raspi Stecker ziehen paar Sekunden warten einstecken, läuft dann.

    Ich habe immer noch nicht ganz verstanden, ob du einen oder zwei MQTT-Server betreibst? Wenn zwei, dann müssen die sich miteinander synchronisieren bzw. aufeinander replizieren. Meine Erfahrungen mit MQTT sind, dass es sehr robust ist. D. h. die Geräte sind eher über HTTP nicht erreichbar als über MQTT. Ich tippe eher - falls nicht konkurrierende MQTT-Server das Problem sind - dass WLAN- bzw. TCP/IP-Probleme zugrunde liegen.

    Hallo JoergZ,

    nein ich betreibe nur einen MQTT Server.

    WLAN und TCP/IP Probleme sollte ich auch nicht haben,

    über Wlan sind auch immer alle Gosund Steckdosen sowie mein NodeMCU im Fehlerfall erreichbar !

    Deshalb denke ich ja das es mit dem MQTT Server was zu tun hat.


    Ich habe in dem Bild gesehen, dass es wohl verschiedene Log-Levels gibt. Suche im IOB doch mal die Konfiguration für das Logging des mqtt0-Adapter und drehe das hoch auf verbose oder all - ich weiß nicht, wie IOB das bezeichnet. Vielleicht siehst du dann, was passiert.

    Hi.

    Schau dir mal in der FB die up/download bitraten deiner Tasmota Geräte an.

    ich hatte auch schon ähnliches. Irgendeiner in der Nachbarschaft klopf beim mir das WLAN zeitweise in den Eimer.

    Auf Kanal 10 ging gar nichts mehr obwohl keine Störsignale in der FB angezeigt wurden. Zwar war die WLAN verbidnung da aber die down/uploadrate sank auf 1b/s ... und genau da kam dann der MQTT timeout.

    Besserung hatte ich nachdem ich Autokanal deaktiviert hatte und mir nen hübschen festen Kanal gesucht habe, die Störsicherheit höhergeschraubt und in den betroffenen Tasmnota Geräten WIFIPOWER von 17db auf 19 gesetzt hab.

    benzino77 Tasmocompiler

    Gitpod Master Release

    Gitpod Development Release

    Sonoff-Basic / Sonoff-RF / Sonoff-Touch / Sonoff S20 / PowStro Basic / MagicHome / Sonoff-RF-Bridge mit diversen 433MHz RF Sender/Empfänger / Shelly_1 / ESP-WiFi-Dimmer / Gosund SP111 / ESP12E / WEMOS D1 Mini / ESP32Cam

    Sensoren: BME280/BMP280/HC-SR501/HC-SR04/ACS712/INA219/MHZ19B/DS3231

    Alexa Sprachsteuerung

    mosquitto/bash/html/cgi auf Wyse5070

    Hallo,

    heute Nachmittag/Abend hatte ich mal Zeit und ich hatte leider mal wieder eine Störung an meinem Raspberry.

    So hat es sich dargestellt:

    Raspberry lässt sich anpingen ist aber nicht über ssh erreichbar, Passwortabfrage kommt auch nicht

    IP des Raspberry 192.168.56.150

    ioBroker über Webseite aufrufen funktioniert nicht

    Grafana über Webseite aufrufen funktioniert nicht

    Also der Raspberry ist nicht erreichbar , obwohl er sich anpingen lässt.

    Ist als nicht ein Problem von MQTT sondern von meinem Raspberry, nur warum und wie finde heraus was da passiert oder nicht funktioniert!

    In Grafana fehlen dann auch von 17:19 Uhr bis 17:50 Uhr dann auch die Datenpunkte


    So zeigt sich der Fehler an den Gosund SP1 "Tasmota Konsole" Steckdosen

    Aus heiterem Himmel ohne was zu tun läuft es dann wieder :/

    Weitergesucht in ioBroker im Log,

    folgendes gefunden:

    am/um

    2020-09-21 17:51:33.448 - error: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().

    2020-09-21 17:51:36.759 - error: host.ioBroker instance system.adapter.telegram.0 terminated with code 6 (UNCAUGHT_EXCEPTION)

    2020-09-21 17:51:43.699 - error: influxdb.0 (1201) Error: connect ECONNREFUSED 127.0.0.1:8086

    meierchen006

    Ist der Raspberry über WLAN oder über Ethernet angeschlossen? Es "riecht" nach einem Wifi-Problem auf höheren Protokollebenen. Ping ist ziemlich low level von den Protokollanforderungen. Sagt eigentlich nur, dass es eine Verbindung gibt. Was sagt den Tante Google zu den IOB Fehlermeldungen?

    Zitat von meierchen006

    Raspberry lässt sich anpingen ist aber nicht über ssh erreichbar, Passwortabfrage kommt auch nicht

    Da wären CPU und RAM Auslastung interessant.

    Mein Raspi läuft mit diversen Anwendungen teils ziemlich am Limit wenn ich die parallel nutze.

    Wenn dann noch eine CPU/Ram intensive Anwendung dazu kommt, habe ich exakt Dein Fehlerbild.

    CPU Last liegt dann bei 100% und der RAM hat noch kaum Speicher frei. Sehen kann ich das zum Glück noch über meinen HTTP Server auf dem ich ne Systemübersicht mit nem Bash-CGI Script darstellen lasse, Offenbar ist der Timeout da etwas geduldiger und die Rechnerlast des CGI Script's so klein das es trotzdem noch abgearbeitet wird.

    Anpingbar, aber weder SSH noch sonst groß wie mehr erreichbar ... bis dann entweder der überlastende Prozess in einen timeout geht und stoppt und wieder Kapazität freigibt oder eben irgend ein anderer.

    Ich kannmir gut vorstellen das das vom IoBroker kommt wenn da ein Adapter, warum auch immer, den Raspi "überlastet"

    benzino77 Tasmocompiler

    Gitpod Master Release

    Gitpod Development Release

    Sonoff-Basic / Sonoff-RF / Sonoff-Touch / Sonoff S20 / PowStro Basic / MagicHome / Sonoff-RF-Bridge mit diversen 433MHz RF Sender/Empfänger / Shelly_1 / ESP-WiFi-Dimmer / Gosund SP111 / ESP12E / WEMOS D1 Mini / ESP32Cam

    Sensoren: BME280/BMP280/HC-SR501/HC-SR04/ACS712/INA219/MHZ19B/DS3231

    Alexa Sprachsteuerung

    mosquitto/bash/html/cgi auf Wyse5070

    Hallo JoergZ  HoerMirAuf

    JoergZ

    der Raspi ist über Ethernet an einen Switch (Netgear GS108Ev3) an einer Fritzbox 7490 angeschlossen.

    HoerMirAuf

    Speicherabfrage:

    pi@ioBroker:~ $ free

    total used free shared buff/cache available
    Mem: 948280 739524 28488 17188 180268 227744
    Swap: 102396 65024 37372

    pi@ioBroker:~ $ free -m -t

    total used free shared buff/cache available
    Mem 926 724 31 16 170 218
    Swap 99 64 35
    Total 1026 789 66


    CPU Abfrage:

    pi@ioBroker:~ $ cat /proc/cpuinfo

    processor : 0

    model name : ARMv7 Processor rev 4 (v7l)

    BogoMIPS : 76.80

    Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32

    CPU implementer : 0x41

    CPU architecture: 7

    CPU variant : 0x0

    CPU part : 0xd03

    CPU revision : 4

    processor : 1

    model name : ARMv7 Processor rev 4 (v7l)

    BogoMIPS : 76.80

    Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32

    CPU implementer : 0x41

    CPU architecture: 7

    CPU variant : 0x0

    CPU part : 0xd03

    CPU revision : 4

    processor : 2

    model name : ARMv7 Processor rev 4 (v7l)

    BogoMIPS : 76.80

    Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32

    CPU implementer : 0x41

    CPU architecture: 7

    CPU variant : 0x0

    CPU part : 0xd03

    CPU revision : 4

    processor : 3

    model name : ARMv7 Processor rev 4 (v7l)

    BogoMIPS : 76.80

    Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32

    CPU implementer : 0x41

    CPU architecture: 7

    CPU variant : 0x0

    CPU part : 0xd03

    CPU revision : 4

    Hardware : BCM2835

    Revision : a22082

    Serial : 00000000

    Model : Raspberry Pi 3 Model B Rev 1.2


    Aktuelle Frequenz des Prozessors:

    pi@ioBroker:~ $ vcgencmd measure_clock arm

    frequency(45)=600062000

    Aktuelle Spannung des Prozessors:

    pi@ioBroker:~ $ vcgencmd measure_volts

    volt=1.2000V

    Taktfrequenz-Unterstützung:

    pi@ioBroker:~ $ dmesg | grep -i bcm2835-cpufreq

    [ 0.825613] bcm2835-cpufreq: min=600000 max=1200000

    Aktuelle Temperatur des SoC in Celsius:

    pi@ioBroker:~ $ vcgencmd measure_temp

    temp=50.5'C

    pi@ioBroker:~ $ top

    top - 08:33:37 up 0 min, 1 user, load average: 2,19, 0,60, 0,21

    Tasks: 182 total, 2 running, 152 sleeping, 0 stopped, 28 zombie

    %Cpu(s): 30,0 us, 6,4 sy, 0,0 ni, 18,4 id, 45,0 wa, 0,0 hi, 0,2 si, 0,0 st

    MiB Mem : 926,1 total, 282,5 free, 327,8 used, 315,7 buff/cache

    MiB Swap: 100,0 total, 100,0 free, 0,0 used. 541,3 avail Mem

    Unknown command - try 'h' for help

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

    494 influxdb 20 0 1323400 85856 32964 S 0,3 9,1 0:12.64 influxd

    605 iobroker 20 0 173108 79992 26400 S 1,3 8,4 0:06.43 io.admin.0

    497 iobroker 20 0 155912 68508 25148 D 28,1 7,2 0:09.85 iobroker.js-con

    686 iobroker 20 0 151632 57192 26300 S 2,6 6,0 0:04.56 io.telegram.0

    617 iobroker 20 0 146744 48536 24956 S 0,0 5,1 0:02.69 io.discovery.0

    705 iobroker 20 0 137576 47920 25116 S 20,2 5,1 0:02.68 io.text2command

    667 iobroker 20 0 148844 47452 26004 S 28,1 5,0 0:03.65 io.info.0

    495 grafana 20 0 946076 33196 23028 S 0,0 3,5 0:01.18 grafana-server

    806 iobroker 20 0 86572 28796 23040 R 13,2 3,0 0:00.40 node

    552 root 20 0 48668 16048 14100 S 0,0 1,7 0:00.38 smbd

    493 root 20 0 33848 10080 8604 S 0,0 1,1 0:00.29 nmbd

    1 root 20 0 33732 8044 6484 S 0,0 0,8 0:04.12 systemd

    628 pi 20 0 14596 6668 5824 S 0,0 0,7 0:00.19 systemd

    122 root 20 0 18984 6516 5664 S 0,0 0,7 0:00.74 systemd-journal

    559 root 20 0 12236 6236 5464 S 0,0 0,7 0:00.17 sshd

    330 root 20 0 13040 5564 4940 S 0,0 0,6 0:00.17 systemd-logind

    570 root 20 0 48668 5368 3420 S 0,0 0,6 0:00.00 lpqd

    557 root 20 0 45428 5284 3400 S 0,0 0,6 0:00.00 smbd-notifyd

    508 root 20 0 10724 5268 4716 S 0,0 0,6 0:00.07 sshd

    492 mosquit+ 20 0 8940 4828 4240 S 0,0 0,5 0:00.08 mosquitto

    558 root 20 0 45420 4136 2252 S 0,0 0,4 0:00.00 cleanupd

    345 root 20 0 10740 3956 3584 S 0,0 0,4 0:00.04 wpa_supplicant

    155 root 20 0 18048 3876 3032 S 0,0 0,4 0:00.86 systemd-udevd

    meierchen006

    Einmal editiert, zuletzt von meierchen006 (22. September 2020 um 10:51)

    Ok, Mem ist gut voll aber m. E. noch nicht bedrohlich voll. Gegen Überlastung spricht auch Taktfrequenz und Temperatur. Wobei es schon besser wäre, diese Parameter über einen längeren Zeitraum zu beobachten. Wenn möglich Raspi neu booten und nach ca. 5 Minuten die Erreichbarkeit testen. Bis dahin sollten alle Prozesse hochgefahren sein. Mal die oben ermittelten Werte mit den dann aktuellen vergleichen. Vielleicht schaukelt sich da was auf, was man durch gelegentliche Neustarts "einfangen" könnte. Mir ist in den Daten oben nichts wirklich Auffälliges begegnet, außer der relativ hohen Prozess- und Zombiezahl. Aber ich habe keine Ahnung vom IOB und was der alles braucht.

    Zitat von JoergZ

    Ok, Mem ist gut voll aber m. E. noch nicht bedrohlich voll.

    Seh ich anders. 31 ist so gut wie gar nichts wenn eine Speicherintensive Anwendung ausgeführt wird. ( Und java [iobroker] ist bekanntlich ein absoluter Speicherfresser)

    D.h. alles wird in Mini Portionen durch den Speicher gepresst bzw. auch noch durch den Swap der beim Raspi ja als Swap Datei angelegt ist. da addieren sich dann Kompremierung, Schreib Lesevorgänge auf die SD, die eh nicht schnell ist. Das kostet dann echte CPU Prformance, die sieht man hier ja nicht weil gerade kein Extremfall da ist. Da reicht ein mittelgroßes Update im Hintergrund schon aus und dann nudelt der Raspi ewig bis das durch ist, die anderen Anwedungen finden gar keinen Platz mehr, darum dann kein SSH etc. bis der Speicherfresser Prozess eeeeendlich durch ist.

    Im extrem Fall beendet der Raspi sogar andere Prozesse wegen Timeout Fehlern.

    EDIT:

    Die Swap Datei hab ich bei mir deshalb auch deaktiviert. Zuviele Lese Schreibzugriffe die viel zu langsam sind. Bei großen Anwendungen bei denen die 100MB Daten im Swap liegen und mit 31mb RAM verarbeitet werden müssen und hin un her geschrieben und gelesen, schadet der mehr als er nutzt.

    benzino77 Tasmocompiler

    Gitpod Master Release

    Gitpod Development Release

    Sonoff-Basic / Sonoff-RF / Sonoff-Touch / Sonoff S20 / PowStro Basic / MagicHome / Sonoff-RF-Bridge mit diversen 433MHz RF Sender/Empfänger / Shelly_1 / ESP-WiFi-Dimmer / Gosund SP111 / ESP12E / WEMOS D1 Mini / ESP32Cam

    Sensoren: BME280/BMP280/HC-SR501/HC-SR04/ACS712/INA219/MHZ19B/DS3231

    Alexa Sprachsteuerung

    mosquitto/bash/html/cgi auf Wyse5070

    Einmal editiert, zuletzt von HoerMirAuf (22. September 2020 um 09:05)

    Hallo

    ioBroker

    Platform--linux

    Betriebssystem--linux

    Architektur--arm

    CPUs--4

    Geschwindigkeit--1200 MHz

    Modell--ARMv7 Processor rev 4 (v7l)

    RAM--926.05 MB

    System Betriebszeit--00:25:00

    Node.js--v10.20.1 (Es gibt eine neuere Version: v10.22.1 - Empfohlene Version v12.18.4)

    NPM--6.14.4

    Festplatte Größe--28.98 GB

    Festplatte frei--25.21 GB

    Anzahl der Adapter--365

    Betriebszeit--00:24:45

    Aktive Instanzen--10

    Hostname--ioBroker


    Beim Node.js

    müsste ich evtl. ein Update machen auf 12.18.4,

    habe dafür noch keine genaue Anleitung gefunden

    Wie gesagt, keine Ahnung von IOB, aber was du sagst, leuchtet ein. Andererseits ist SSH nicht so ein Speicherfresser und recht schlank und es soll schließlich eigentlich "immer" funktionieren, damit man mit dem Host immer noch was machen kann aus der Entfernung und sei es ein Neustart. Aber wenn es mal geht und mal nicht, dann muss man sich mit solchen try and error - Verfahren und Beobachtung von Situationen herantasten, um herauszubekommen, woran es wirklich liegt. Beim Raspi auch immer wieder für Überraschungen gut: schlappe Stromversorgung. Also mal dmesg und journalctl einsetzen und nach undervolting Ereignissen suchen.

    Hallo,

    nach dem löschen der beiden Adapter nochmal Speicherabfrage gemacht:

    pi@ioBroker:~ $ free

    total used free shared buff/cache available

    Mem: 948280 570672 180312 7188 197296 318608

    Swap: 102396 4352 98044

    pi@ioBroker:~ $ free -m -t

    total used free shared buff/cache available

    Mem: 926 564 168 7 193 304

    Swap: 99 4 95

    Total: 1026 568 264

    pi@ioBroker:~ $