Mein Workaround zu diesem Problem auf dem iPhone: Wlan Aus, VPN Verbindung zur Fritzbox herstellen, dann lädt die VIS2 Runtime und ioBroker wie gewohnt.

@homoran said in NodeRed 5.2.1 startet nicht Node.js 24.11.0 *gelöst*: @surfer09 warum hast du den Fragebogen gelöscht statt ihn auszufüllen? und warum node24? Warum antwortest du ihm noch? Wenn er den Fragenbogen löscht - ok. Für mich ist damit ein Posting in der Rubrik 'Fehlermeldungen' erledigt und wird einfach ignoriert :-)

@mcm1957 said in Fehler bei mehreren Adaptern nach öffnen der Instanz: Mach mit den jeweiligen Meldungen ein Issue beim betroffenen Adapter auf - sofern noch kein Issue dazu existiert. Obige Meldung betrifft vis-2 Hast du bitte für die 'has an invalid jsonConfig' Meldungen ein Issue in den einzelnen Adapter Repos gemacht? Ohne Issue ist keine Analyse und keine Behebung zu erwarten.

Ich habe leider auch das Problem, dass seit einiger Zeit mein cloud-Adapter morgens startet und nach einigen Fehlversuchen im "geht halt nicht" Status hängen bleibt. Starte ich ihn dann später manuell, gehts auch erst nicht, ein reconnect ist aber später ab und an erfolgreich. So schaut das im Log aus (habe den aufgrund von Fehlversuchen gestoppten Adapter einfach gestartet): cloud.0 2025-11-03 20:57:55.043 info Connection changed: disconnect cloud.0 2025-11-03 20:57:55.042 info Adapter redirected temporally to "https://iobroker.net:10556" in one minute. Reason: command from server cloud.0 2025-11-03 20:57:54.785 info Trying to connect as system.user.admin to cloud cloud.0 2025-11-03 20:57:54.719 info Connecting with https://iobroker.net:10555 with "xxx@example.de_API-KEY" cloud.0 2025-11-03 20:57:54.671 info starting. Version 5.0.1 in /opt/iobroker/node_modules/iobroker.cloud, node: v22.21.0, js-controller: 7.0.7 cloud.0 2025-11-03 20:57:54.785 info Trying to connect as system.user.admin to cloud cloud.0 2025-11-03 20:57:54.719 info Connecting with https://iobroker.net:10555 with "xxx@example.de_API-KEY" cloud.0 2025-11-03 20:57:54.671 info starting. Version 5.0.1 in /opt/iobroker/node_modules/iobroker.cloud, node: v22.21.0, js-controller: 7.0.7 Was sind die Ursachen für dieses Verhalten, dass bis vor wenigen Wochen/Monaten noch nicht aufgetreten ist (cloud war immer verlässlich, um von überall aufs System zu schauen) und was kann ich selbst tun, um das wieder zu stabilisieren (ich hab hier im Thread schonmal "sentry" gelesen und das auch nachgeschaut - das ist aber bereits disabled)?

@buflug453 sagte in Zigbee Gerät wird direkt nach Kopplung wieder entfernt: @asgothian Ich bin wieder zurück auf die Version 3.1.2. Bei dieser Version gibt es bei mir keine Kopplungsprobleme. Als Info was mir in der Zwischenzeit mit den neuen Versionen (> 3.1.2) noch aufgefallen ist: Livarno LED Leiste wird bei Kopplung interviewed, aber es passiert sonst nichts (keine "Successfully interviewed" Meldung). Ich habe 2 Stück, identisches Verhalten. Aqara Temperatursensor verlässt ähnlich wie der Vibrationssensor das Netzwerk. Das ist mir nur bei einem Sensor aufgefallen. Ein Batteriewechsel hat nicht geholfen. Alle anderen funktionieren weiterhin. Wenn ich irgendetwas testen soll, gib Bescheid. Ansonsten bleibe ich vorerst auf dieser Version. Wenn du testen magst kannst du kannst folgendes machen: Adapter anhalten in der Datei /opt/iobroker/node_modules/iobroker.zigbee/package.json den Eintrag für den ZH und ZHC auf die neuste Version anheben: "zigbee-herdsman": "^6.1.0", "zigbee-herdsman-converters": "^25.50.0" dass müsste dann so aussehen. Wie es bei der 3.1.5 ist weiss ich aktuell nicht. auf der Konsole im Verzeichnis /opt/iobroker/iobroker-data/node_modules/iobroker.zigbee den Befehl npm i ausführen. Adapter starten Kachel vom Koordinator anschauen - da müsste ZHC 25.50.0 oder neuer und ZH 6.1.0 oder neuer geladen sein. Dann die Geräte die sich seltsam verhalten neu pairen - ist das verhalten wie bei 3.1.5 oder wie bei den neueren. A. Nachtrag 1: Ich hab nochmal eine Frage dazu wie du das Pairing gestartet hast - an einem Router ? Über den Button oben rechts ? Über den Button am Koordinator ? Nachtrag 2: Wie kommst du von der Version wieder runter ? Ganz einfach - über das Interface des ioBroker wieder die aktuelle 3.1.5 installieren. A

@tschirpke36 bei mir hat der erste Teil aus dieser Anleitung geholfen https://bobbyhadz.com/blog/npm-err-code-enotempty#:~:text=To resolve the issue%2C delete your node_modules directory,npm ERR! syscall rename npm ERR! path %2Fhome%2Fborislav%2FDesktop%2Fbobbyhadz-rest%2Fbobbyhadz-react%2Fnode_modules%2Facorn-globals (falls jemand nochmal das selbe Problem hat)

@wolkenloser die meisten Fragen hast du beantwortet, aber nicht alle: was steht im iobroker log beim Start was steht im iobroker log beim Versuch das pairing zu starten das Thema ‘keine Netzwerk verbindungen’ ist in der Anleitung erklärt - du musst das Netz erst abfragen - das passier nicht mehr automatisch und dauert gerne mal etwas. Wen die states im Objekt-Browser aktualisiert / geändert werden, nicht aber die Skripte triggern dann passt da was außerhalb des. zigbee Adapters nicht. A.

Hallo zusammen Ich habe noch einige Seiten im Forum gelesen und habe einen Hinweis bekommen vermutlich gibt es noch ein altes system.adapter.vis* objekt, das löschen Das habe ich gemacht und nun bekomme ich keine Fehler mehr.

Und nicht vergessen danach die Geräte neu zu flashen. Bin begeistert. .... schon Stunden heute an dem Fehler verbracht: [image: 1761832370757-afa2e9e4-eda4-492a-bebc-c136a4d622b3-1760975618027-23f3d0ce-9b62-47d9-865d-693d9c26bd15-image.png] Und alle Versionen xfach ausprobiert die die Verschlüsselungseinstellungen hergeben. Nun den Beitrag hier gefunden und nach 5 Minuten läuft alles

@fiddle npm geht immer über den gesamten tree. Da kannste nix ausschließen, weil npm immer versucht das ganze konsistent zu halten. Wenn es dich stört, schmeiß den radar2 halt raus. Die Installation läuft ja trotzdem durch: Process exited with code 0 Edit: Und warum läuft das (zumindest bei mir) durch? Weil die beiden Module, die bei mir nicht gebaut werden können, nur eine SubDependency eines optionalen Moduls (hier: net-ping) sind: "optionalDependencies": { "@stoprocent/noble": "1.19.1", "net-ping": "^1.2.4" Und net-ping scheint mir nicht mehr gepflegt zu werden: https://github.com/nospaceships/node-net-ping/blob/master/README.md Kann also gut sein, dass es mit aktuellen Setups nicht mehr baut.

@wendy2702 scheinbar nicht, zumindest nicht aufmerksam genug. Und auf die Frage VM oder LXC... Ist Geschmackssache und hängt immer von den Gegebenheiten eines Einzelnen ab.

@wrod said in netatmo-bezogene Log-Einträge "info" host: @mcm1957 ja, genau. Die Frage ist, ob solche Meldungen gefiltert werden können, so dass diese stetigen Start-Stop-meldungen dieses Adapters herausgefiltert werden, andere aber durchgehen. So gefragt - nein. Es gibt keine Möglichkeit einzelne Infomeldungen zu filtern. Du kannst den Loglevel ändern - das blockiert dann allerdinsg ALLE Info Meldungen des js-controllers.

@bbtown Ok dann wüsste man wo man eingrenzen kann. Bitte Issues anlegen

Hab gerade festgestellt dass es im Inkognito Modus funktionert, dann nochmal alle Webseitendaten gelöscht und jetzt gehts.

@jdard sagte in ioqontrol und z.B. vis zeigen nichts an: Was muss ich einstellen, dass der Port 8082 nach aussen durchgereicht wird? Du musst einen weiteren Port durchreichen: [image: 1761215492744-867bdc79-b877-4752-89bc-c31e584f1c21-image.png] [image: 1761215506515-7f4a2805-502e-4c2c-b725-9bacbcc261a9-image.png] Oder alternativ den Container entweder im Host-Mode oder gleich mit eigener IP betreiben. [image: 1761215582417-4c4d7784-3a45-4f18-8879-aa960f623190-image.png] Dann bist Du das Thema "Ports" dauerhaft los.

@thomas-braun Nein ich schimpfe definitiv nicht. Es ist Sache des Maintainers zu entscheiden ob etwas für Stabel reif ist. Aber ich frage nach.

@stefan341 sagte in Zigbee Adapter und NOUS A1Z: Wie mache ich das? Es gibt da einen Datenpunkt 'device_query'. Sieht man sogar in deinem Screenshot. Wenn du die 'devices' nicht im Expertenmodus aufgemacht hättest, dann wäre da sogar ein toller Button zum klicken. Ansonsten - mit dem Wert 'true' beschreiben, dann löst man den aus. A

Leute bleibt doch bitte sachlich! Ich habe eine schnelle Antwort auf meine Frage gesucht und hier um Hilfe gebeten. Sicherlich kann ich auch die gewünschten Infos nachreichen. Ich habe mir schon gedacht, dass der Fehler mit zu vielen Anfragen an den Server zu tun hat. Ich habe jetzt mal alle Blockly Scripte angehalten, um zu schauen, ob der Fehler weiterhin besteht. Ich gebe morgen Bescheid, ob es was geholfen hat. wenn nicht kann ich fehlenden Infos gerne nachreichen.

@smalltower1 NEIN - von direkten Installationen von Github wird EXPLIZIT ABGERATEN Die Version 2.4.3 ist im LATEST Repository verfügbar - aber leider nicht fürs Stable vom Dev freigegeben. [image: 1760300228436-3cbe80a1-bdbf-444e-87d2-dbb4720075d6-image.png] Also entweder auf LATEST Repository umstellen oder im Expertenmodus "von npm" auswählen. Alternativ auf der commandline 'iob upgrade iobroker.viessmanapi@2.4.3' verwenden. Aber Achtung: Nicht einfach alle neueren Adapter aus dem Stable in einer produktiven Umgebung installieren. Das kann auch unerwünschte Änderungen auslösen.