NEWS
Test Adapter NSPanel-lovelace-ui v0.17.x
-
Die AI hats so schön geschrieben deshalb kopiere ich das hier rein :)
ich hab mir deinen Log mal genau angeschaut – und ich glaube nicht, dass es am WLAN liegt. Es ist auch kein echter „Absturz" der Panels. Was du siehst, ist eine eingebaute Sicherheitsfunktion:
Der Adapter „spricht" im Normalbetrieb regelmäßig mit jedem Panel. Das Panel hat einen kleinen Wächter eingebaut: Hört es 140 Sekunden lang nichts vom Adapter, lädt es sich selbst neu (es springt auf die
Startseite). Das ist absichtlich so, damit ein Panel sich von selbst fängt, falls mal was klemmt.In deinem Log sieht man genau das:
- Normal schickt der Adapter jede Minute Daten an die Panels.
- Zweimal hat er das nicht getan – einmal ~2 Minuten lang gar nichts.
- Nach genau 140 Sekunden Stille haben sich beide Panels gleichzeitig neu geladen.
Und genau hier ist der Punkt: beide gleichzeitig = es liegt nicht an den Panels (zwei Geräte verlieren nicht sekundengenau zusammen das WLAN), sondern daran, dass der Adapter für ~2 Minuten ausgesetzt hat.
In der Zeit kam von ihm einfach nichts mehr – und der Wächter hat zugeschlagen.Das erklärt auch deine zweite Beobachtung mit der Uhrzeit: Die Uhr auf dem Screensaver wird vom Adapter einmal pro Minute nachgestellt. Wenn der Adapter aussetzt, läuft die angezeigte Zeit logischerweise
hinterher, bis er sich wieder meldet. Gleiche Ursache, nur ein anderes Symptom.Die Frage ist also: Warum setzt der Adapter bei dir alle paar Minuten für so lange aus? Das ist meistens kein Adapter-Fehler, sondern dein ioBroker-Rechner ist in dem Moment überlastet. Kannst du mir dazu bitte ein paar Sachen rausfinden:
- Welcher Raspberry Pi ist das (Pi 3 / Pi 4 / wie viel RAM)?
- Läuft auf der Kiste viel anderes (viele Adapter, History/InfluxDB, Backups zur vollen Stunde …)?
- Schau dir in ioBroker mal die Werte unter System → Host an, besonders CPU-Auslastung, freier Speicher (RAM/Swap) und – wenn vorhanden – den „Event Loop Lag". Idealerweise beobachtest du die genau dann,
wenn die Panels neu starten.
Ich vermute stark, dass genau zu diesen Zeitpunkten die CPU/der Speicher am Anschlag ist und ioBroker für ein-zwei Minuten „einfriert".
Parallel schaue ich mir auf meiner Seite an, ob ich den Wächter etwas toleranter machen kann, damit ein kurzer Hänger nicht gleich zum Neustart führt – aber die eigentliche Ursache liegt vermutlich in der Auslastung deines Systems.
-
Die AI hats so schön geschrieben deshalb kopiere ich das hier rein :)
ich hab mir deinen Log mal genau angeschaut – und ich glaube nicht, dass es am WLAN liegt. Es ist auch kein echter „Absturz" der Panels. Was du siehst, ist eine eingebaute Sicherheitsfunktion:
Der Adapter „spricht" im Normalbetrieb regelmäßig mit jedem Panel. Das Panel hat einen kleinen Wächter eingebaut: Hört es 140 Sekunden lang nichts vom Adapter, lädt es sich selbst neu (es springt auf die
Startseite). Das ist absichtlich so, damit ein Panel sich von selbst fängt, falls mal was klemmt.In deinem Log sieht man genau das:
- Normal schickt der Adapter jede Minute Daten an die Panels.
- Zweimal hat er das nicht getan – einmal ~2 Minuten lang gar nichts.
- Nach genau 140 Sekunden Stille haben sich beide Panels gleichzeitig neu geladen.
Und genau hier ist der Punkt: beide gleichzeitig = es liegt nicht an den Panels (zwei Geräte verlieren nicht sekundengenau zusammen das WLAN), sondern daran, dass der Adapter für ~2 Minuten ausgesetzt hat.
In der Zeit kam von ihm einfach nichts mehr – und der Wächter hat zugeschlagen.Das erklärt auch deine zweite Beobachtung mit der Uhrzeit: Die Uhr auf dem Screensaver wird vom Adapter einmal pro Minute nachgestellt. Wenn der Adapter aussetzt, läuft die angezeigte Zeit logischerweise
hinterher, bis er sich wieder meldet. Gleiche Ursache, nur ein anderes Symptom.Die Frage ist also: Warum setzt der Adapter bei dir alle paar Minuten für so lange aus? Das ist meistens kein Adapter-Fehler, sondern dein ioBroker-Rechner ist in dem Moment überlastet. Kannst du mir dazu bitte ein paar Sachen rausfinden:
- Welcher Raspberry Pi ist das (Pi 3 / Pi 4 / wie viel RAM)?
- Läuft auf der Kiste viel anderes (viele Adapter, History/InfluxDB, Backups zur vollen Stunde …)?
- Schau dir in ioBroker mal die Werte unter System → Host an, besonders CPU-Auslastung, freier Speicher (RAM/Swap) und – wenn vorhanden – den „Event Loop Lag". Idealerweise beobachtest du die genau dann,
wenn die Panels neu starten.
Ich vermute stark, dass genau zu diesen Zeitpunkten die CPU/der Speicher am Anschlag ist und ioBroker für ein-zwei Minuten „einfriert".
Parallel schaue ich mir auf meiner Seite an, ob ich den Wächter etwas toleranter machen kann, damit ein kurzer Hänger nicht gleich zum Neustart führt – aber die eigentliche Ursache liegt vermutlich in der Auslastung deines Systems.
-
Dafür solltest du einen eigenen Topic öffnen, hier gibt es leute die sich damit besser auskennen. Aber das ist schon etwas ernstes - vielleicht kanal optimieren, zigbee auf dem falschen kana.l
-
Dafür solltest du einen eigenen Topic öffnen, hier gibt es leute die sich damit besser auskennen. Aber das ist schon etwas ernstes - vielleicht kanal optimieren, zigbee auf dem falschen kana.l
@ticaki
Habe mein Wlan heute mal geprüft , und neu eingestellt, heute habe ich bei dem IObroker und NAS sowie Fritzbox nur noch 1-2ms .
Aber bei den Nspanels bleit die ping Antwort variable von 2-200ms bis zur Zeitüberschreitung , obschon das NSPanel_1 3 Meter vom Repeater weg ist , kann es nicht sein dass im NSpanel intern es zu dies verschiedenen Verzögerungen kommt? -
das ist ein normaler tasmota der funkt nur auf 2.4ghz kann sein das das bei dir überlaufen ist oder sich mit zigbee beißt - das wird eher nicht am adapter oder nspanel liegen (hw defekt mal aussen vor gelassen)
-
das ist ein normaler tasmota der funkt nur auf 2.4ghz kann sein das das bei dir überlaufen ist oder sich mit zigbee beißt - das wird eher nicht am adapter oder nspanel liegen (hw defekt mal aussen vor gelassen)
@ticaki
Danke noch für deinen support.
Leider habe ich noch mit der Uhrzeit Probleme , die läuft hinterher , denke mal , habe vor kurzen auf Node.js: v22.22.3 ge-updated.
Kann dies nicht das Problem sein?
Zigbee habe ich nicht , also dann ein Überlauf. -
@ticaki
Danke noch für deinen support.
Leider habe ich noch mit der Uhrzeit Probleme , die läuft hinterher , denke mal , habe vor kurzen auf Node.js: v22.22.3 ge-updated.
Kann dies nicht das Problem sein?
Zigbee habe ich nicht , also dann ein Überlauf.Die Uhrzeit ist simpel - die kommt vom adapter und wenn die nachricht vom adapter verloren geht, hängt die Uhrzeit - nach 2:30 geht das panel dann in den "waiting for data". Ich bin wegen dem uhrzeit problem schon mal zu spät gekommen.
Das hauptproblem ist, dass tasmota kein 1 und 2 bei MQTT anbieten (weiß die option nicht mehr auswendig) das ist immer fire and forget. Ich hab das im adapter etwas abgefangen, aber wenns panel die nachricht nicht bekommt kann ich da auch nix machen.
hab ein ähnliches Problem gerade mit einem pi 3b der verliert laufend das wlan - keine ahnung wieso.
-
Ich habe gesehen, dass es eine Möglichkeit gibt, die Abfahrtstabelle und die Verbindungen aus dem public-transport Adapter aufs NS Panel zu bekommen.
Hat da jemand ne Beschreibung/Anleitung zu? -
@tt-tom
hier fragt ein Nutzer, wie man deinen adapter mit deinem anderen mit adapter benutzen kann@holgerwolf
ich würde mal sagen ja ^^ muss aber Tom beantworten, der kümmert sich um beides. Anleitung sollte aber morgen da sein, wenn er etwas zeit hat.
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden
