Hi zusammen, erstmal ein dickes Dankeschön für den Adapter und die generelle Arbeit an iobroker! Ich bin nach langer Zeit auch mal wieder auf den Fehler gestoßen. Bei mir ist ein ganzer Zoo aus allen Generationen von Shelly im Betrieb. Die einzigen, die aktuell den Fehler werfen sind Shelly Plug m Gen 3. Aktuelle Firmware ist drauf (1.8.99-plugmg3prod0). Die beiden, die bei mir im Netz sind, werfen den Fehler ziemlich genau jede Minute. Ansonsten liefern die beiden Stecker fleißig Daten und machen keine merkbaren Fehler. Passwort im Adapter habe ich nochmal geprüft bzw. wollte ich neue setzen, aber da es gleich ist, kommt der Speichern-Button nicht. Ideen was ich machen kann? Gruß Max

Hi, ich habe auch grade mal die Version installiert. Gibt eine 2.8.7 Fehlermeldung ist weg und es kommen auch wieder Daten soweit ich das sehen konnte bis jetzt. [image: 1779384208476-282ba3ec-e229-426c-afad-388db4e435e3-image.jpeg]

@Berlon sagte: wollte den MQTT Adapter nehmen Dann mach das

@OliverIO sagte: meine vermutung ist wohl richtig Ist gut wenn du eine solche hattest ;-) Ich hatte diese erst gar nicht. Und, was heißt das jetzt "einfach ausgedrückt".

Danke, hat funktioniert. 1.Einstellungen des Adapters exportiert 2.Instanz gelöscht 3.Adapter gelöscht 4.Neue Instanz installiert 5.Einstallungen aus .json Datei wieder importiert Instanz ist grün und läuft, alle Objekte wieder da. Leider muss ich jetzt für alle Datenpunkte die ich in die InfluxDB gelogt habe das logen wieder von Hand aktivieren. Ich danke euch für die Hilfe.

@crunchip Hab den DP grad manuell angelegt vom Typ object. Scheint zu klappen. Edit Wurde in 1.1.6 gefixt, wurde nur nie veröffentlicht..... https://github.com/Scrounger/ioBroker.linux-control/pull/57 So weit in die Vergangenheit hab ich nicht nachgeschaut....

@badsnoopy667 sagte: Ich vermute aber auch, dass das eher mit BMW zusammenhängt als mit meinem System. Richtig. Allerdings ist der Zustand deines Systems die Grundlage für alles was dann darauf laufen soll.

Danke für den schnellen Fix, läuft wieder mit der 2.0.4 Mike

@Satmedia sagte: Nodejs-Version: 20.19.2 Vom 'Problem' abgesehen: Unbedingt JETZT SOFORT auf node nodejs@22 hieven. Am besten per iob nodejs-update

@Peter-V. sagte: Frage dazu: hattet ihr etwas an der IP Configuration des Hosts geändert? Hatte den gleichen Fehler und nach 2 Tagen testen und grübeln bin ich dann alle (und wirklich alle) Änderungen durch gegangen. Bei mir war in Proxmox LXC (iobroker) etwas in der 99-sysctl.conf (Debian 13) verbogen, hatte wegen Matter einiges geändert. Hab mal dann eins nach dem anderen deaktiviert und plötzlich ging es wieder. In Debian 12 ist es die sysctl.conf. Nein, habe nichts der gleichen getan … immer nur fleißig die Adapter-Updates eingespielt

@Thomas-Braun kenne ich, jedoch hab ich extra Proxmox dazu geschrieben, denn komischerweise hatte sich das eben nicht richtig verhalten mit den default 60 bei mir und das auf drei unterschiedlichen Servern. Mittlerweile bin ich schon lange von Proxmox weg

Vielleicht reden wir auch aneinander vorbei? Ich meine diese Funktion: [image: 1777888593785-90d5fd5f-cb64-48ec-93f2-2d975002c5f9-image.jpeg] Da steht nichts von Upload, sondern von installieren. Den von Dir eingefügten Hinweistext kenne ich nicht und weiß auch nicht, wo ich den finden soll. Aber in diesem Thread geht es eigentlich um das Problem bei iCal, wir sollte wieder dahin zurück....

Kein STress. Läuft ja mit der anderen Version.

ok, dann werde ich das mal ändern und beobachten. Danke!

@D3ltoroxp sagte: Ist das dann was ich alles händisch gemacht habe, pfusch, oder kann man das nur so machen, aktuell ? Bitte in Zukunft nicht mit manuellen Befehlen herumpfuschen, das führt nur immer wieder zu Problemen! In den Adaptereinstellungen gibt es mittlerweile eine Option die Pillow Version anzupassen.

@BenX5 bitte mal mit 0.7.0-beta.4 testen

Für die interessierten Mitlesenden möchte ich abschließend noch mal zusammenfassen: Die eigentliche Ursache für das aufgetretene Phänomen hat @asgothian in diesem Post erläutert. Hab dann recherchiert. Und tatsächlich: Mein Nachbar auf der gegenüberliegenden Straßenseite hat auch ein Zigbee-Netzwerk und nutzt dafür den gleichen Sonoff-Stick mit Zigbee2MQTT im HA. Offensichtlich hatte er bereits vergleichbare Beobachtungen gemacht und auch ständig unbekannte Geräte auf seine "Blockliste" gesetzt. Bei einem Abgleich stellten wir amüsiert fest, dass ich seine und er meine Geräte ständig rauswerfen musste. 🤣 Wir haben uns dann auf neue IDs und Kanäle verständigt. Seit dem keine Probleme mehr.

Ich denke, es ist irgendetwas in der Formatierung der Telemetrie-Nachrichten, die Sentry schicken will. Bei mir zickt Sentry nur bei einer von zwei ical Instanzen