alle ca.36 Stunden Stürzt der IObroker ab -HILFE

[Dellishelly]

@wendy2702

ist eine Intallation ohne Desktop, daher Monitor und Tastatur nicht möglich
wie komme ich ins Syslog ?
Ist ein 4er Pi mit 4GB RAM
Und ja es läuft nur der IOB drauf.
Als Netzteil hab ich ein normales 2A Handynetzteil dran.

@Homoran
Der Shelly ist einmal als MQTT und einmal als COAP

Der Crash war ja um ca 13.07Uhr
Das sind die letzten Logs. alles was davor an Logs existiert sind nur infos oder warns (keine relevanten glaube ich)

Noch eine Idee ? hierzu ?

[wendy2702]

@dellishelly bei direktem Anschluss wird kein Desktop benötigt. Da arbeitet man mit Befehlszeile wie bei SSH.

Es gibt keine Handynetzteile. Das sind Ladegeräte welche zum Betrieb eines PIs in der Regel nicht geeignet sind.

2A dürften dem PI4 auch zu wenig sein.

Das Netzteil sollte 3A können.

https://www.raspberrypi.com/products/type-c-power-supply/

Möglicherweise ist das schon die Ursache

[Dellishelly]

@wendy2702
wird umgehend ausgetauscht

[Thomas Braun]

@dellishelly sagte in alle ca.36 Stunden Stürzt der IObroker ab -HILFE:

ist eine Intallation ohne Desktop, daher Monitor und Tastatur nicht möglich

Klar ist das möglich. Das läuft dann im FrameBuffer, ohne Desktop.

Bis auf die doppelte Portbelegung bei den shelly-Instanzen sehr ich da aber nix wirklich wildes.

[Thomas Braun]

@dellishelly sagte in alle ca.36 Stunden Stürzt der IObroker ab -HILFE:

Als Netzteil hab ich ein normales 2A Handynetzteil dran.

Besorg dir da ein richtiges Netzteil, kein Handyladeteil

[Dellishelly]

@thomas-braun

die doppelte Portbelegung habe ich jetzt auch beseitigt.
Richtiges Netzteil ist nun auch dran.

Ich hoffe da war was bei was funktioniert.

Vielen Dank auch jeden Fall schonmal.

[wendy2702]

@dellishelly sagte in

Ich hoffe da war was bei was funktioniert.

Wobei? Bei den Netzteilen die du zur Auswahl hattest oder bei Beseitigung der doppelten Port Belegung?

[Dellishelly]

@wendy2702
@Thomas-Braun
@Homoran

Es ist ein richtiges Netzteil dran.
Wars auch leider schon vorher. Hatte vergessen, dass ich mir das letztes Jahr schon bestellt hatte.
Damit scheidet der Fehler leider aus.

Die Portbelegung habe ich auch geändert.

Hab die 2. Instanz nun auf den 1890 gelegt.

Aber ich befürchte, dass dies leider nicht der Fehler war.
Das lief bei mir schon immer so.

Habe die Probleme erst, seitdem ich ein paar zusätzliche Shellymini und ShellyPLugS eingebunden habe.
Zumindest ists mir da erst aufgefallen.

Kann da aber auch leider keine Fehler erkennen.

[wendy2702]

@dellishelly wie gesagt, Monitor Tastatur dran und oder mal ins Linux Syslog schauen

[da_Woody]

@dellishelly sagte in alle ca.36 Stunden Stürzt der IObroker ab -HILFE:

Der Shelly ist einmal als MQTT und einmal als COAP
Hab die 2. Instanz nun auf den 1890 gelegt.

was erzählst du da?
bei coap kannst du nirgends eine portnummer eingeben...

[Dellishelly]

@da_woody

du kannst aber kurzfristig auf mqtt umstellen, den Port ändern und dann wieder auf Coap stellen.
das habe ich gemacht.
glaube aber dass es auf das Problem keine Auswirkung hat, da wie du auch schon sagst im COAP modus garkein Server auf dem Port ist.

[da_Woody]

@dellishelly dann aber nicht wundern wenn was bei den Shelly spinnt... Da hast du dann in beiden Instanzen Geräte drinnen eventuell. Kommst drauf an, wie die Shelly konfiguriert sind. Sind die coap Shelly richtig? Die mqtt? Richtig Eingerichtet?
Aber du hast Recht, sollte nix mit deinen Abstürzen zu tun haben.

[Dellishelly]

@da_woody

Hi, ja da ist alles korrekt hinterlegt.
Habe halt noch n paar Shelly’s die kein mqtt können.
Die sind dann in der anderen Instanz.
Aber wie gesagt, in Summe alles richtig eingestellt.

Bin echt Ratlos woher die Abstürze kommen….

[da_Woody]

@dellishelly sagte in alle ca.36 Stunden Stürzt der IObroker ab -HILFE:

Habe die Probleme erst, seitdem ich ein paar zusätzliche Shellymini und ShellyPLugS eingebunden habe.

Eigentlich unlogisch, doppelte IPs?
Wie viele Shelly hast du? Fixe IPs, oder zumindest IP an Mac gebunden?
Zwar Aufwand, aber Adapter deinstallieren, DPSs löschen, Adapter neu Instanz, .0 auf coap, .1 auf mqtt. Alles richtig eintragen und neu erkennen lassen. Dauert halt.
Alle Shelly kontrollieren ob dort alles richtig ist.

Habe halt noch n paar Shelly’s die kein mqtt können.
Ähm, alle können mqtt, nur die alten können halt dann keine Cloud

[Dellishelly]

@da_woody
@Thomas-Braun
@Homoran

ja sorry hast du recht, KÖNNEN tun sie das alle.

Ich habe einen Ansatz gefunden an dem der Fehler liegen könnte.
Bei der Neu Installation habe ich ja, da ich eine SD Karte nutze die Schreibvorgänge begrenzt.

Und das hier habe ich kurz nach dem Neustart im Log gefunden:
Kann es sein dass hier die Grenze der Schreibvorgänge erreicht wurde und der Raspi das System deswegen die knapp 2 Stunden lahmgelegt hat ? Oder welche Gründe kann die Fehlermeldung EPIPE noch haben ?

2023-12-08 14:54:37.934  - info: govee.0 (26786) Function: get current device info by API
2023-12-08 14:54:37.935  - info: govee.0 (26786) Request send: get device list
2023-12-08 14:54:37.935  - info: govee.0 (26786) Server Response: 200 (OK)

In diesem Zeitraum war das System nicht erreichbar

2023-12-08 16:49:44.562  - info: govee.0 (26786) Request send: get device info (******************8:C5)
2023-12-08 16:49:44.591  - error: botvac.0 (26736) States database error: write EPIPE
2023-12-08 16:49:44.584  - error: fb-checkpresence.0 (26766) States database error: write EPIPE
2023-12-08 16:49:44.650  - error: nanoleaf-lightpanels.0 (26854) States database error: write EPIPE
2023-12-08 16:49:44.653  - warn: nanoleaf-lightpanels.0 (26854) Connection to '192.168.72.102:16021' lost, Error: No ssdp:alive detected. Try to reconnect...
2023-12-08 16:49:44.776  - info: nanoleaf-lightpanels.0 (26854) Shutting down Nanoleaf adapter 'nanoleaf-lightpanels.0'...
2023-12-08 16:49:44.791  - info: fb-checkpresence.0 (26766) cleaned everything up ...
2023-12-08 16:49:44.777  - info: vis-inventwo.0 (27297) cleaned everything up...
2023-12-08 16:49:44.563  - info: govee.0 (26786) Server Response: 200 (OK)
2023-12-08 16:49:44.564  - info: govee.0 (26786) Values for object: ******************8:C5 updated
2023-12-08 16:49:44.627  - error: govee.0 (26786) Objects database error: write EPIPE
2023-12-08 16:49:44.782  - error: govee.0 (26786) States database error: write EPIPE
2023-12-08 16:49:44.923  - info: govee.0 (26786) Request send: get device info (******************4:63)
2023-12-08 16:49:44.924  - info: govee.0 (26786) Server Response: 200 (OK)
2023-12-08 16:49:44.940  - info: govee.0 (26786) Values for object: ******************4:63 updated
2023-12-08 16:49:44.942  - info: govee.0 (26786) Request send: get device info (******************5:8F)
2023-12-08 16:49:44.943  - info: govee.0 (26786) Server Response: 200 (OK)
2023-12-08 16:49:44.943  - info: govee.0 (26786) Values for object: ******************5:8F updated

[Dellishelly]

@da_Woody
@Thomas-Braun
@Homoran

Habt ihr hier noch eine Idee zu ?

Vielen Dank schonmal für euren Input!

[Thomas Braun]

@dellishelly

Nee, aber bei EPIPE knicken dir die Verbindungen weg.

EPIPE (Broken pipe): A write on a pipe, socket, or FIFO for which there is no process to read the data. Commonly encountered at the net and http layers, indicative that the remote side of the stream being written to has been closed.