@Backe03 sagte: Da ja oben im Liznez Manager auch die richtige von iobroker.net drinne steht . Was richtig ist scheint hier diskussionsfähig zu sein 😉 Also nochmal: Du hast eine Lizenz für die in iobroker.net eingetragene UUID! Anscheinend hat sich aber die UUID deines aktuellen ioBrokers geändert, warum auch immer. Woher glaubst du zu wissen, @Backe03 sagte: zieht sich wieder die falsche UUID Nicht die "richtige" UUID deiner Installation sein soll? Und ebenfalls noch einmal: Das hat nichts mit der vis-2 Installation zu tun! Da kannst du neuinstallieren bis du schwarz wirst, das ändert nicht die UUID deines ioBrokers. Deswegen sollte auch das Update nichts damit zu tun haben. @Backe03 sagte: wo auch immer er die hernimmt Das hat man dir bereits gezeigt.

@SaiBot1981 https://forum.iobroker.net/topic/83298/iobroker-visu-android-app

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

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

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.

@klausiob ich bin jetzt nicht sicher ob ich dein Problem richtig verstanden habe, aber man kann in den Einstellungen von iot festlegen ob man standardmäßig Umschalten oder nicht Umschalten will. Kannst ja mal hier schauen: [image: 1776933022574-1000019557.jpg]

@voodoo2man köntest du mir helfen - in github hast du geschrieben, das es bei dir wieder funktioniert - https://github.com/ioBroker/ioBroker.matter/issues/714