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

[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.