Vergleich der Antwortzeiten des Speichers

[hambue]

Ich habe gerade im geschlossenen Issue #3484 ein interessantes Thema entdeckt. Dies betrifft die Antwortzeiten des Speichers, welche unter der Variable response_duration in Influx gespeichert wird. In der Grafik von @ledermann sieht man, dass seine NPU nur sehr selten länger 8ms benötigt:

Noch ein Hinweis: Der SENEC-Collector speichert die Antwortzeit auch in InfluxDB ab (im Field response_duration). Du kannst also über das InfluxDB-Admin-UI herausfinden, wie oft solche Verzögerungen überhaupt auftreten.

Bei mir sahen die letzten 30 Tage so aus:

Das Problem tritt also auch bei mir manchmal auf - ganz ohne LFP-Akkus. Stichproben zeigen, dass NPU-Probleme die Ursache sind.

Mit jetzigem Kenntnisstand neige ich dazu, in SOLECTRUS und im Collector gar nichts zu verändern. Die Probleme liegen im Speicher und werden von SOLECTRUS korrekt angezeigt. Man kann nur hoffen, dass SENEC die NPU-Probleme irgendwann in Griff bekommt.

Zum Vergleich hier mal meine Daten der letzten 24h:

Bei mir stelle ich fest, dass in regelmäßigen Abständen von 100 Abfragen der TLS-Handshake neu ausgeführt wird und eine Abfrage dann etwa 250ms dauert. In unregelmäßigen Abständen kommt es jedoch auch zu Verzögerungen von 1-2s, die allerdings dann exakt alle 5 Minuten erfolgen. Ich vermute hier einen Zusammenhang mit den an die App gesendeten Werten, da dies auch im Intervall von 5 Minuten geschieht.
Da ich keine NPU-Fehler hatte in letzter Zeit, sind keine größeren Ausschläge zu sehen. 95% meiner Werte liegen unter 13ms und der Live-Charakter von Solectrus ist somit gegeben.

Mich würde nun interessieren, wie das bei anderen Nutzern aussieht? Muss hier auch öfter der Handshake erneuert werden? Kann jemand die manchmal in 5min Abständen auftretenden Verzögerungen reproduzieren?

[Zeppelin-PV]

ich würde das gerne auch bei unserem Speicher mal anschauen, weiß aber nicht wie
was sind die Voraussetzungen, wie lauten die Befehle/Eingaben dazu ?
ich versuche immer über das LOG File vom Speicher eine Regelmäßigkeit festzustellen, aber das wird nix
ich wünsche mir die Zeit zurück als alles über http lief, ohne jegliche Aussetzer
warum das mit https so ein Problem ist versteh ich nicht

[ledermann]

Das obige Diagramm wurde direkt mit InfluxDB erstellt. InfluxDB hat eine eigene, schicke Benutzeroberfläche, mit der man ganz individuelle Abfragen erstellen und auch als Diagramm visualisieren kann. Also auch Dinge, die SOLECTRUS selbst gar nicht kennt - wie das hier besprochene Diagramm der Antwortzeiten des Speichers.

Voraussetzung ist, dass auf deinem Raspi das Frontend von InfluxDB auch freigegeben ist. Hierzu ist Port 8086 zu öffnen, es muss also in der compose.yaml so aussehen:

influxdb:
  image: influxdb:2.7-alpine
  ....
  ports:
    - 8086:8086

Wenn du bei dir keine Port-Angabe siehst oder diese mit # auskommentiert ist, muss das also geändert werden. Anschließend - wie immer nach einer Compose-File-Änderung - neu starten mit docker compose up -d.

Jetzt kannst du dich bei InfluxDB einloggen. Rufe die URL http://raspi-ip:8086 auf. Also Port 8086 explizit angeben, dort läuft InfluxDB, auf http://raspi-ip:3000 läuft unverändert SOLECTRUS.
Du wirst jetzt nach Username und Password gefragt. Welche das sind, steht in deiner .env unter INFLUX_USERNAME (default: "admin") und INFLUX_PASSWORD (default: "ExAmPl3PA55W0rD").

Nun kannst du dich durchklicken. Links auf "Data Explorer", dann Bucket aussuchen (z.B. "my-pv"), dann Measurement (z.B. "SENEC"), dann Field (hier also "response_duration"), dann Button "Submit".

Im Logfile des Speichers steht übrigens NICHTS zur Antwortzeit, das ist ein Messwert des SENEC-Collectors.

[gereons]

Bei mir stelle ich fest, dass in regelmäßigen Abständen von 100 Abfragen der TLS-Handshake neu ausgeführt wird und eine Abfrage dann etwa 250ms dauert.

Kann ich bestätigen:

Tatsächlich erscheint der Peak grob gesagt im 8-Minuten-Takt, was ziemlich genau 500 Sekunden entspricht, also alle 100 Requests. Hier wäre dann die Frage, wer von den beiden Parteien den Socket dichtmacht, das kann ja sowohl vom Server als auch vom Client kommen.

Grössere Ausschläge habe ich seit dem Reboot meiner Anlage gestern nachmittag nicht mehr beobachtet.

[ledermann]

Finde ich auch spannend, die IP 6.25.107.145 taucht bei mir im Log ebenfalls auf. Genau zweimal in meiner vollständigen Log-Sammlung von vier Jahren, innerhalb der letzten Wochen, immer im Kontext von NPU-Fehlern. Bei früheren NPU-Fehlern aber nicht, dort auch keine andere externe IP.

Bezüglich DoD: Verschwörungstheorie in 3,2,1, .... ;-)

[GalOR7]

Zumindest habe ich gerade bei Reddit gesehen scheinen DOD IPs durchaus öfter Verwendung zu finden vor allem wenn keine Privaten und Public IP Adressen mehr zur Verfügung stehen. Also eher wie geroens schon schreibt einfache Lösung quick und dirty (schlampig).
Wahrscheinlich haben die Amis jetzt alle Standorte unserer Speicher ;-) Hoffe der Mossad bekommt die nicht :-D

[gereons]

Auch das ergibt keinen Sinn. Private IPs stehen immer zur Verfügung, die können per Definition nicht ausgehen (ausser du brauchst mehr als knapp 18 Mio von denen gleichzeitig). Geroutete public IPs von anderen Leuten einfach so zu verwenden bringt überhaupt nix, wenn man nicht auch die Routing-Tabellen entsprechend anfasst, und das ist alles andere als einfach.

Und die Amis kriegen unsere Daten sehr viel einfacher als einen Senec-Programmierer damit zu beauftragen, immer mal wieder eine DoD-IP-Adresse zu verwenden... :-)

[Zeppelin-PV]

bei unserem Speicher passiert dies auch, wobei hier immer kurzfristig auf 0.0.0.0 gewechselt wird und wieder zurück
Ich frage mich immer wieder warum der Speicher unter http problemlos lief, verbindungstechnisch
mit https jedoch solche Probleme hat. Ergibt für mich keinen Sinn, oder gibt es hierfür eine Erklärung ?

2024-09-24 01:17:35 [I|NET] IP address changed from 192.168.1.230 to 0.0.0.0.
2024-09-24 01:17:36 [I|NET] IP address changed from uninitialized (0.0.0.0) to 192.168.1.230.
2024-09-24 01:28:01 [I|BAT Interface] Battery temp: 23.00 to 25.30 °C, case temp: 28.35 °C
2024-09-24 01:50:17 [I|NET] IP address changed from 192.168.1.230 to 0.0.0.0.
2024-09-24 01:50:17 [I|NET] IP address changed from uninitialized (0.0.0.0) to 192.168.1.230

[gereons]

Ergibt für mich keinen Sinn, oder gibt es hierfür eine Erklärung ?

Die Entwickler bei Senec sind nicht die hellsten Kerzen auf der Torte, ganz einfach.

[ledermann]

Ja, ich beobachte da bei mir auch - die Verbindung wird offenbar für 100 Requests offen gehalten. Das regelt der Server aber selbst, der SENEC-Collector schickt per Header Connection: Keep-Alive nur den Wunsch, die Verbindung offenzuhalten, also keine eigene Limitierung.

In der vom SENEC-Collector verwendeten Library findet sich dieser Hinweis:

Typically many keep-alive capable servers tune this to 100 or less, so the 101st request will fail with ECONNRESET.

Es sieht also so aus, als würde der SENEC-Speicher das genauso handhaben. Nach 100 Abfragen erfolgt ein Reset und der nächste Request dauert etwas länger (um die 250ms). Der SENEC-Speicher verwendet übrigens nginx 1.17.7, der diese 100 auch als Default hat, wenn ich den Source richtig verstehe.

Aus meiner Sicht ist das alles korrekt so und kein Grund zur Sorge. Wenn ein Requests außer der Reihe deutlich länger dauert (mehrere Sekunden), so hat der Speicher in diesem Moment vermutlich viel anderes zu tun. Dass sich, wie im Fall von @gereons, der Speicher in eine Situation aufschaukelt, in der ein Request bis zu einer Minute dauert, scheint etwas zu sein, was sich SENEC mal ansehen sollte.

Noch etwas zu InfluxDB: Beim Zusammenklicken der Abfrage kann man sich übrigens leicht ins Knie schießen und ein Diagramm produzieren, das die Peaks unterdrückt oder abflacht. InfluxDB definiert (bei Verwendung des Query Builders) standardmäßig eine Glättung über ein Zeitfenster, das umso größer ist, je länger der betrachtete Zeitraum ist.

Ich empfehle daher folgende Abfrage ohne Glättung, sodass die Originalmesswerte angezeigt werden:

from(bucket: "my-pv")
  |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
  |> filter(fn: (r) => r["_measurement"] == "SENEC")
  |> filter(fn: (r) => r["_field"] == "response_duration")

Einzugeben ist das über den "Script Editor", Bucket und/oder Measurement sind ggfs. anzupassen.

[hambue]

Ja, bei meiner Grafik hatte ich das so ohne aggregateWindow gemacht. Wahrscheinlich habe ich deshalb in deiner Grafik die 250ms Requests nicht erkannt und dachte, dass wäre eine Eigenart meines Speichers.

Bzgl nginx:

Prior to version 1.19.10, the default value was 100.

[Zeppelin-PV]

zu diesem Thema meine Frage:
kann SENEC sehen dass an dem Speicher anderweitig Daten abgegriffen werden ?

... und noch eine Frage hinterher:
wenn zwei Solectrus Instanzen auf den Speicher zugreifen, hat das auch einen Einfluss auf die Antwortzeiten ?

[ledermann]

Ja, SENEC könnte z.B. die API-Requests zählen. Dann wüssten sie, dass der Speicher vom Ernst täglich 2 * 24 * 60 * 60 / 5 = 34.560 Requests am Tag bearbeitet. Es wäre auch möglich, halbwegs sicher zu unterscheiden, ob die Requests von der integrierten Website kommen oder von einem externen Client (wie dem SENEC-Collector, einem ioBroker-Adapter oder ähnlichem).

Aber das wird kaum eine Konsequenz haben. Man kann schlecht dem Kunden ein Netzwerkgerät ins Haus stellen, das eine ungesicherte API bereitstellt und sich dann beschweren, wenn da Requests eingehen.

Meine Prognose: Wir alle, die einen V3 zu Hause haben, bekommen lange vor Ablauf der 20-Jahres-Garantie ein günstiges Angebot unterbreitet, auf den Home 4 (oder 5 oder 6, ...) zu upgraden. Der hat dann gar keine lokale API mehr und das Thema ist erledigt. Den SENEC-Collector stellt man dann auf Cloud-Access um und erhält Messwerte fortan nicht mehr alle 5s, sondern nur noch einmal pro Minute.

Wenn mehrere Clients (wie z.B. zwei parallel laufende SENEC-Collectoren oder iobroker/HomeAssistant-Clients oder Browser mit geöffneter lokaler Website) zeitgleich auf den Speicher zugreifen, setzt das diesen natürlich unter größere Last. Auf die Antwortzeiten selbst wird es vermutlich kaum eine Auswirkung haben, da ja kein exakt synchroner Zugriff stattfindet. Jeder Client führt (unabhängig von den anderen) 100 schnelle Keep-Alive-Requests aus, dann einen langsamen (wie oben herausgefunden), dann wieder 100 schnelle usw.

Aber wenn es tatsächlich ein Memory-Leak im Server-Modul des Speichers gibt (wie oben allseits vermutet), dann könnten zusätzliche Clients zu häufiger auftretenden NPU-Fehlern führen.

[gereons]

kann SENEC sehen dass an dem Speicher anderweitig Daten abgegriffen werden ?

Ja, wie Georg schon sagte, theoretisch könnten sie das sehen. Praktisch glaube ich das allerdings nicht, da nach meinem Verständnis nur die Logfiles, die wir selber auch sehen können täglich zu Senec hochgeladen werden, und aus denen geht das m.E. nicht hervor ob, wie und wie oft die interne API abgerufen wurde.

[Zeppelin-PV]

ich möchte das Thema jetzt nicht überstrapazieren
aber folgende Idee/Frage
wenn ich die Redundanz mit zwei Raspi's haben möchte, wie bisher,
wäre es möglich dass nur einer den Speicher abfragt und der zweite sich die Daten vom ersten holt ???

[ledermann]

Ich denke auch nicht, dass SENEC solche Daten erhebt. Aber: Ich gehe davon aus, dass es außer dem Log-File noch mehr gibt, was zu SENEC hochgeladen wird. Denn sie müssen ja zumindest die Messwerte bekommen, um sie in der App anzeigen zu können. Die stehen nicht im Logfile.

Weiteres Indiz dafür ist folgende Zeile im Logfile, die täglich auftaucht:

2024-09-24 00:00:00 [I|Statistics] Created statistics file 2024-09-24

Manchmal findet sich auch so etwas:

2024-09-10 23:41:17 [I|Statistics] Continue statistics file /stat/2024_09/24-09-10.csv

Über den Webserver kommt man da aber nicht ran. Da müsste man schon die SD-Karte entnehmen.

[ledermann]

wäre es möglich dass nur einer den Speicher abfragt und der zweite sich die Daten vom ersten holt ???

@Zeppelin-PV Theoretisch könnte man einen Proxy bauen, der die Messwerte vom Speicher abfragt, eine gewisse Zeit zwischenspeichert und für andere Clients bereitstellt - und sich dabei nach außen selbst wie ein SENEC-Speicher verhält. Da müsste man aber einiges an Hirnschmalz investieren. Das ist nichts, was ich verfolgen würde.

[Zeppelin-PV]

zu diesem Thema habe ich noch folgende Erkenntnis -
mein Laptop öffnet nach dem Hochfahren im Firefox vordefinierte Tabs. Dabei ist auch der Speicher mit seiner IP Adresse
und die beiden Raspi's mit Solectrus. Den Speicheraufruf habe ich nun seit zwei Tagen entfernt und bin der Meinung dass die Zeiten
mit keine Verbindung weniger geworden sind. Ich werde das noch weiter beobachten ...

[ledermann]

Die lokale Website des Speichers dauerhaft offen zu haben, ist auf jeden Fall nicht zu empfehlen. Die Seite bombardiert den Speicher mit 3 Requests pro Sekunde. Gegenüber dem SENEC-Collector (ein Request alle 5s) ist das die 15-fache Belastung.

Die Requests der SENEC-Seite laufen scheinbar auch weiter, wenn der Tab im Hintergrund ist. Bei SOLECTRUS ist das übrigens nicht der Fall: Wenn ein SOLECTRUS-Tab im Hintergrund ist, wird die Aktualisierung pausiert.

[Zeppelin-PV]

wenn ich SENEC wäre, würde ich dies ganz dick und fett publizieren, die wissen doch dass viele technisch affine Controllfreaks da draussen sitzen
... bedeutend, um Welten besser, nachdem ich den Speicher lokal nicht mehr aufrufe

[gereons]

Noch mal als ein kleiner Nachtrag meine durchschnittlichen Antwortzeiten der letzten 30 Tage.

Man sieht einen kleinen Peak am 10.9., um diesen Tag herum hatte ich auch mehrere NPU-Fehler in den Logs. Der krasse Peak am 22.9. war ja der Auslöser für #3484 und dann diese Diskussion hier. Am 4.10. wurde es dann wieder schlimm, und ich hab erneut die Anlage neu gestartet.

Seit dem Reboot am 22.9. hatte ich keine NPU-Fehler mehr. Sieht für mich sehr nach einem Zusammenhang aus - wenn die Kiste immer lahmer wird gibt's über kurz oder lang diese Fehler, und irgendwann greift dann irgendein interner Reset-Mechanismus. Wenn man dem zuvorkommen will scheint es mit der akutellen Firmwareversion hilfreich zu sein, die Kiste ungefähr alle 12 Tage mal durchzustarten, das geht ja zum Glück flott.

Sehen andere diesen 12-Tage-Rythmus auch?

[ledermann]

Ich beobachte hier bei mir auch einen regelmäßigen Turnus. Zumindest in der jüngeren Vergangenheit waren das ebenfalls 12 Tage. Vorher trat es auch öfter auf, allerdings laufen bei mir immer wieder irgendwelche Experimente und der SENEC-Collector läuft ein paar Tage doppelt und dreifach (mit variablem SENEC_INTERVALL). Das macht die Vergleichbarkeit sehr schwierig, insofern halte ich meine Beobachtungen nicht für repräsentativ.

Meine Firmware ist immer noch auf 0826 (alte Akkus, die nicht ausgetauscht werden müssen).

[GalOR7]

Sehen andere diesen 12-Tage-Rythmus auch?
Ja sehe ich auch bei mir. Immer etwa 10-12 Tage je nach dem wie oft ich die Geräteseite des V3 aufrufe. Dann startet der Speicher in der Regel nach einigen Stunden neu.

[Zeppelin-PV]

ich hatte, wie man sehen kann, den Speicher lokal immer im Firefox Task aktiv, vor ca. einer Woche geändert,
jetzt sieht es um Welten besser aus.
ob sich auch bei mir eine Regelmäßigkeit einstellt, werde ich beobachten.

die letzten zwei Peaks haben diesen Abstand

und das sind die Einträge im LogFile (-2Std)

2024-09-28 14:53:12 [E|System Update] Sending HTTP message server status failed with error: read from input failed
2024-09-28 14:53:22 [E|ServerCommunicator] Sending HTTP GET message failed with error: read from input failed
2024-09-28 14:53:42 [E|System Update] Sending HTTP message server status failed with error: read from input failed
2024-09-28 14:58:14 [E|System Update] Sending HTTP message server status failed with error: read from input failed
2024-09-28 14:58:24 [E|ServerCommunicator] Sending HTTP GET message failed with error: read from input failed
2024-09-28 14:58:31 [I|BAT Interface] Battery temp: 25.00 to 29.00 °C, case temp: 36.74 °C
2024-09-28 14:58:31 [I|PV Interface] Protocol: 0xa0, No external inverter. INV_LV:[452.8W] INV_HV:[445.1W] Total production: 897.8W current feed-in limit: 100.00 %
2024-09-28 14:58:44 [E|System Update] Sending HTTP message server status failed with error: read from input failed
2024-09-28 14:58:45 [I|MQTT-Client] Connected to server
2024-09-28 15:03:16 [I|ServerCommunicator] Reconnected.

2024-10-03 03:50:34 [E|System Update] Sending HTTP message server status failed with error: read from input failed
2024-10-03 03:50:44 [E|ServerCommunicator] Sending HTTP GET message failed with error: read from input failed
2024-10-03 03:51:04 [E|System Update] Sending HTTP message server status failed with error: read from input failed
2024-10-03 03:54:56 [I|MQTT-Client] Connected to server
2024-10-03 03:55:36 [E|System Update] Sending HTTP message server status failed with error: read from input failed
2024-10-03 03:55:46 [E|ServerCommunicator] Sending HTTP GET message failed with error: read from input failed
2024-10-03 03:56:19 [I|MQTT-Client] Connected to server
2024-10-03 03:56:54 [E|System Update] Sending HTTP message server status failed with error: read from input failed
2024-10-03 03:57:29 [I|MQTT-Client] Connected to server
2024-10-03 03:57:30 [E|System Update] resolving IP failed
2024-10-03 03:58:48 [I|MQTT-Client] Connected to server
2024-10-03 03:59:58 [I|MQTT-Client] Connected to server
2024-10-03 04:00:38 [E|System Update] Sending HTTP message server status failed with error: read from input failed
2024-10-03 04:00:48 [E|ServerCommunicator] Sending HTTP GET message failed with error: read from input failed
2024-10-03 04:05:22 [I|MQTT-Client] Connected to server

[hambue]

Vielen Dank für die vielen Beispiele mittlerweile. Interessant finde ich, dass niemand die 5 Minuten Intervalle, welche bei mir auftreten reproduzieren kann. Es ist nicht wirklich störend, dass alle 5 Minuten mal ein Messwert erst nach 1-2s ankommt, aber verstehen würde ich es natürlich trotzdem gern, warum der Upload der Daten zu Senec nur in meinem Fall für eine kleine Verzögerung sorgt.

[gereons]

Ja das ist tatsächlich komisch. Kannst du das 5-Minuten-Intervall auch direkt nach einem Neustart beobachten, oder ist das auch eher etwas was nach längerer Laufzeit erst auftritt?

[hambue]

Nein, nach einem Neustart sieht es so aus:

Edit nach 2 Tagen: Nach 36h mit maximal 250ms hat nun der mir bekannte Rhythmus mit dem 5-Minuten-Intervall begonnen.

[hambue]

Ha, ich habe anscheinend die Ursache gefunden. Der Switch an dem unter anderem die NPU des Speichers hängt, war mit einem Lan-Port der FritzBox verbunden, welcher im Eco-Modus (100 Mbit/s statt 1 Gbit/s) betrieben wurde. Ich verstehe zwar nicht genau, wie das nach 2 Tagen zu den Verzögerungen führte, aber seit der Umstellung auf Power-Modus sind nun 10 Tage vergangen und das 5-Minuten-Intervall tritt nicht mehr auf.

[gereons]

Ich bin vorsichtig optimistisch dass dieses Problem mit der aktuellen Firmware-Version 0831 gelöst oder zumindestens umgangen wird.

Der Graph zeigt die Antwortzeiten meiner Anlage in den letzten 48 Stunden, man sieht dass die Zeiten am 15.11. immer schlechter wurden, bis sich dann heute morgen gegen 04:00h alles wieder normalisiert hat. Der 15.11. ist ziemlich genau 12 Tage nach dem letzten Reboot (durch den Firmware-Update) und im Log von heute finden sich erst die üblichen MQTT-Meldungen

2024-11-16 02:47:19 [I|MQTT-Client] Connected to server
2024-11-16 02:49:01 [I|MQTT-Client] Connected to server
2024-11-16 02:49:53 [W|MQTT-Client] Disconnected from server
2024-11-16 02:50:05 [W|MQTT-Client] Connection timed out
2024-11-16 02:51:01 [I|MQTT-Client] Connected to server
2024-11-16 02:51:41 [W|MQTT-Client] Disconnected from server
2024-11-16 02:52:05 [W|MQTT-Client] Connection timed out
2024-11-16 02:52:59 [I|MQTT-Client] Connected to server
2024-11-16 02:53:57 [I|MQTT-Client] Connected to server
2024-11-16 02:54:37 [W|MQTT-Client] Disconnected from server
2024-11-16 02:54:56 [I|MQTT-Client] Connected to server
2024-11-16 02:55:36 [W|MQTT-Client] Disconnected from server
2024-11-16 02:56:00 [W|MQTT-Client] Connection timed out
2024-11-16 02:56:56 [I|MQTT-Client] Connected to server
2024-11-16 02:57:50 [W|MQTT-Client] Disconnected from server
2024-11-16 02:58:05 [W|MQTT-Client] Connection timed out
2024-11-16 02:59:05 [W|MQTT-Client] Connection timed out

und dann

2024-11-16 02:59:40 [I|NPU] Switched off
2024-11-16 03:00:33 [I|NPU] Switched on

Und danach ist Ruhe im Karton.

Das sieht für mich so aus als ob der interne Watchdog, der die NPU neu startet jetzt sehr viel besser und vor allem früher zuschlägt.

[gereons]

Bei meiner Anlage (identische Firmware-Versionen wie bei @GalOR7 und auch nur rund 2000 Betriebsstunden mehr) hat in der Nacht auf heute der interne Neustart zum zweiten Mal zugeschlagen und wieder alles bereinigt. Komisch dass sich die Systeme so unterschiedlich benehmen...

[GalOR7]

Ja ist wirklich seltsam. Ob das vielleicht auch noch mit der HW Revision der NPU zusammenhängt? Da sollen wohl auch mehrere Versionen draußen sein. Dennoch bin ich immer noch überzeugt von meinem System von Senec. Ich beoabachte mal weiter...

[GalOR7]

Ging dann vor zwei Tagen wieder mit den MQTT Meldungen los. Dann ist der Speicher kaum mehr erreichbar. Solectrus ist oft "Disonnected" und auch die Senec App warnt. Aber heute morgen hat dann tatsächlich der NPU PowerCycle geklappt ohne das ich einen Reset durchführen musste. Es geschehen "Zeichen und Wunder" 👍😊 - mal sehen wie es in 11 Tagen wieder aussieht
2024-12-06 08:04:55 [I|NPU] Switched off
2024-12-06 08:05:47 [I|NPU] Switched on
2024-12-06 08:05:58 [I|MQTT-Client] Connected to server
2024-12-06 08:05:58 [I|NPU] image version 2408-8293ede4

[GalOR7]

Gestern Abend war es wieder soweit nach dem am 16.12. die MQTT Fehler wieder losgegangen sind hatte ich am 17.12. insgesamt 5 re-boots des Systems die alle die NPU nicht korrekt zurück gesetzte haben. Dann am Abend wieder die Sequenz wie vor zwei Wochen (siehe oben)
Bedeutet für mich das nur die NPU resets ohne das System korrekt zurück setzen. Würde auch erklären warum manche ihren Speicher wirklich stromlos machen müssen weil die System Neustarts gar nicht helfen. Aber da sind wir laut anderen Foren in bester Gesellschaft 🙄

[GalOR7]

Heute war PatchDay habe eine neue FW für die MCU und NPU
2024-12-19 12:45:01 [I|Main] 832.0-0 McuImg:bb89c92b83efb2ad64aa39bdbc0c7d98a9a2a891 - MCU_0832 - 2024-11-19T10:08:11+01:00
2024-12-19 15:32:06 [I|NPU] image version 2411-68e254fb
Bin schon gespannt was sich ändern wird...

[GalOR7]

Der Neustart dauert genauso lange wie ein normaler Einschaltvorgang über das Bedienpanel. Ein paar Minuten mit allen Selbstests.
Nehme einfach einen kleinen Imbusschlüssel als Haken und ziehe die linke Verkleidung über einen Kühlschlitz ab. Der blaue Knopf ist dann oben auf der rechten Seite gut zu sehen. Die rechte Platine mit dem Netzwerkanschluss ist die NPU. Die linke Platine mit dem Resetknopf ist die Main Control Unit (MCU).

[hambue]

Danke für die Erläuterung. Hatte gedacht, dass nur die NPU schnell neugestartet wird und man so die Selbsttests umgehen kann.