So ich denke, ich habs sauber bekommen, auch wenn die Pakete keine Fehler erzeugt haben: Iobroker gestoppt (iob stop) Alle direkten "root"-Pakete aus der package.json rausgeschmissen: pi@MWHome:/opt/iobroker $ cat package.json { "name": "iobroker.inst", "version": "2.0.3", "private": true, "description": "Automation platform in node.js", "scripts": { "install": "node lib/checkVersions.js", "postinstall": "node lib/install.js", "test": "node node_modules/mocha/bin/mocha --exit" }, "dependencies": { "iobroker.admin": "5.4.9", "iobroker.backitup": "2.4.9", "iobroker.dwd": "2.8.3", "iobroker.flot": "^1.10.7", "iobroker.info": "^1.9.19", "iobroker.javascript": "5.7.0", "iobroker.js-controller": "4.0.23", "iobroker.linux-control": "1.1.3", "iobroker.mercedesme": "0.0.56", "iobroker.mqtt": "4.0.7", "iobroker.node-red": "3.3.1", "iobroker.pi-hole": "^1.3.4", "iobroker.ping": "1.5.3", "iobroker.simple-api": "2.7.0", "iobroker.socketio": "4.2.0", "iobroker.sourceanalytix": "0.4.14", "iobroker.sql": "2.1.7", "iobroker.tr-064": "4.2.16", "iobroker.vis": "1.4.15", "iobroker.vis-hqwidgets": "1.2.0", "iobroker.vis-materialdesign": "0.5.9", "iobroker.web": "4.3.0", "iobroker.yahka": "^0.13.1" } } das iob rebuild durchgeführt: pi@MWHome:/opt/iobroker $ iobroker rebuild self Rebuilding native module "self" ... rebuilt dependencies successfully Rebuilding native modules done Dann mit npm list kontrolliert: pi@MWHome:/opt/iobroker $ npm list iobroker.inst@2.0.3 /opt/iobroker ├── camelcase@3.0.0 extraneous ├── cliui@3.2.0 extraneous ├── code-point-at@1.1.0 extraneous ├── colors@1.4.0 extraneous ├── decamelize@1.2.0 extraneous ├── error-ex@1.3.2 extraneous ├── find-up@1.1.2 extraneous ├── fs-extra@7.0.1 extraneous ├── get-caller-file@1.0.3 extraneous ├── hosted-git-info@2.8.9 extraneous ├── invert-kv@1.0.0 extraneous ├── iobroker.admin@5.4.9 ├── iobroker.backitup@2.4.9 ├── iobroker.dwd@2.8.3 ├── iobroker.flot@1.11.0 ├── iobroker.info@1.9.19 ├── iobroker.javascript@5.7.0 ├── iobroker.js-controller@4.0.23 ├── iobroker.linux-control@1.1.3 ├── iobroker.mercedesme@0.0.56 ├── iobroker.mqtt@4.0.7 ├── iobroker.node-red@3.3.1 ├── iobroker.pi-hole@1.3.4 ├── iobroker.ping@1.5.3 ├── iobroker.simple-api@2.7.0 ├── iobroker.socketio@4.2.0 ├── iobroker.sourceanalytix@0.4.14 ├── iobroker.sql@2.1.7 ├── iobroker.tr-064@4.2.16 ├── iobroker.vis-hqwidgets@1.2.0 ├── iobroker.vis-materialdesign@0.5.9 ├── iobroker.vis@1.4.15 ├── iobroker.web@4.3.0 ├── iobroker.yahka@0.13.1 ├── iobroker@2.0.3 extraneous ├── is-core-module@2.9.0 extraneous ├── jsonfile@4.0.0 extraneous ├── lcid@1.0.0 extraneous ├── load-json-file@1.1.0 extraneous ├── normalize-package-data@2.5.0 extraneous ├── number-is-nan@1.0.1 extraneous ├── os-locale@1.4.0 extraneous ├── parse-json@2.2.0 extraneous ├── path-exists@2.1.0 extraneous ├── path-parse@1.0.7 extraneous ├── path-type@1.1.0 extraneous ├── pify@2.3.0 extraneous ├── pinkie-promise@2.0.1 extraneous ├── pinkie@2.0.4 extraneous ├── read-pkg-up@1.0.1 extraneous ├── read-pkg@1.1.0 extraneous ├── require-main-filename@1.0.1 extraneous ├── resolve@1.22.1 extraneous ├── spdx-correct@3.1.1 extraneous ├── spdx-exceptions@2.3.0 extraneous ├── spdx-expression-parse@3.0.1 extraneous ├── spdx-license-ids@3.0.11 extraneous ├── supports-preserve-symlinks-flag@1.0.0 extraneous ├── validate-npm-package-license@3.0.4 extraneous ├── which-module@1.0.0 extraneous ├── wrap-ansi@2.1.0 extraneous ├── y18n@3.2.2 extraneous ├── yargs-parser@5.0.1 extraneous └── yargs@7.1.2 extraneous Kamen eine Menge extraneous Pakete. npm prune durchgeführt pi@MWHome:/opt/iobroker $ npm prune removed 54 packages in 7s 102 packages are looking for funding run `npm fund` for details npm list - scheint nun sauber zu sein: pi@MWHome:/opt/iobroker $ npm list iobroker.inst@2.0.3 /opt/iobroker ├── iobroker.admin@5.4.9 ├── iobroker.backitup@2.4.9 ├── iobroker.dwd@2.8.3 ├── iobroker.flot@1.11.0 ├── iobroker.info@1.9.19 ├── iobroker.javascript@5.7.0 ├── iobroker.js-controller@4.0.23 ├── iobroker.linux-control@1.1.3 ├── iobroker.mercedesme@0.0.56 ├── iobroker.mqtt@4.0.7 ├── iobroker.node-red@3.3.1 ├── iobroker.pi-hole@1.3.4 ├── iobroker.ping@1.5.3 ├── iobroker.simple-api@2.7.0 ├── iobroker.socketio@4.2.0 ├── iobroker.sourceanalytix@0.4.14 ├── iobroker.sql@2.1.7 ├── iobroker.tr-064@4.2.16 ├── iobroker.vis-hqwidgets@1.2.0 ├── iobroker.vis-materialdesign@0.5.9 ├── iobroker.vis@1.4.15 ├── iobroker.web@4.3.0 └── iobroker.yahka@0.13.1 Auch package-lock.json wird wieder fleißig mitgeschrieben: pi@MWHome:/opt/iobroker $ ls -la insgesamt 656 drwxrwxrwx+ 8 iobroker iobroker 4096 29. Jul 18:47 . drwxr-xr-x 6 root root 4096 21. Feb 08:33 .. lrwxrwxrwx 1 iobroker iobroker 21 20. Dez 2019 backups -> /data/backup/iobroker drwxrwxrwx+ 2 iobroker iobroker 4096 20. Dez 2019 backups.org -rwxrwxrwx+ 1 iobroker iobroker 1049 8. Sep 2019 CHANGELOG_FIXER_LINUX.md -rwxrwxrwx+ 1 iobroker iobroker 3556 8. Sep 2019 CHANGELOG_INSTALLER_LINUX.md -rwxrwxrwx+ 1 iobroker iobroker 23988 8. Sep 2019 fix_installation.sh drwxrwxrwx+ 3 iobroker iobroker 4096 8. Sep 2019 install -rwxrwxrwx+ 1 iobroker iobroker 1087 26. Apr 14:43 INSTALLER_INFO.txt lrwxrwxrwx 1 iobroker iobroker 22 26. Apr 14:43 iob -> /opt/iobroker/iobroker -rwxr-xr-x+ 1 iobroker iobroker 305 26. Apr 14:43 iobroker drwxrwxrwx+ 10 iobroker iobroker 4096 29. Jul 18:49 iobroker-data drwxrwxrwx+ 2 iobroker iobroker 4096 8. Sep 2019 lib -rwxrwxrwx+ 1 iobroker iobroker 1137 8. Sep 2019 LICENSE drwxrwxrwx+ 2 iobroker iobroker 4096 29. Jul 18:50 log drwxrwxr-x+ 732 iobroker iobroker 69632 29. Jul 18:48 node_modules -rwxrwxrwx+ 1 iobroker iobroker 175 29. Jul 13:35 .npmrc -rwxrwxrwx+ 1 iobroker iobroker 1093 29. Jul 18:47 package.json -rw-rw-r--+ 1 iobroker iobroker 498074 29. Jul 18:48 package-lock.json -rwxrwxrwx+ 1 iobroker iobroker 6101 8. Sep 2019 README.md -rwxrwxrwx+ 1 iobroker iobroker 5693 23. Dez 2021 reinstall.js Alle Instanzen grün, keine Fehlermeldungen im Log. Sorry @kBrausew, dass ich Deinen Thread etwas missbraucht habe. Aber ich würde Dich nach diesen Erfahrungen durchaus ermutigen, Dein node_module Verzeichnis neu aufzubauen, wie hier beschrieben: https://forum.iobroker.net/topic/56543/nach-nodejs-update-kein-adapter-mehr-updatebar/23?_=1658914381795 An alle anderen - vielen Dank für die direkte und indirekte Hilfe. @Thomas-Braun Sorry fürs Nerven. ;)

@deachte said in S7 Adapter Problem nach Update auf Node.js 16: iobroker rebuild s7 --install npm install --production Das hat funktioniert. Vielen Dank!

So komme wieder rein. habe mal einfach das Passwort neu über die Console neu vergeben iobroker passwd admin und dann konnte ich mich wieder einloggen. Mh.

@ingob Ich hab jetzt nochmal was neues versucht, um den Aufbau ganz trivial einfach zu halten. Habe eine neue Linux VM installiert, sie hat nur ein Netzwerkinterface, das steckt in einer Fritzbox. Ein Shelly, ist am Wlan der Fritzbox. Beide sind im selben Subnet 192.168,178,0/24 Die Server IP steht im Shelly unter CoIoT peer. Der Shelly Adapter bleibt gelb.

@asgothian vielen Dank für Deine Antwort. Aber wie kann man denn das Problem am besten umgehen, d.h. den state dann in solchen Fällen korrigieren? trigger auf brightness change setzen und dann den state manuell auf true setzen? das erscheint mir schon eher die Brechstangenmethode zu sein, oder? Anscheinend machen das alle meine Zigbee Lampen so. :-(

@chris299 sagte in [gelöst] Zigbee Ikea Styrbar Problem: @holgerwolf evtl. habe ich dann das Konzept der Trigger noch nicht verstanden. Bisher dachte ich, dass Trigger sowieso nur bei Änderungen des Objekts ausgelöst werden. (die verfügbaren Optionen scheinen das zu untermauern) Nein. Die Trigger werden aktiv wenn das Objekt 'beschrieben' wird - das kann eine Änderung oder eine Aktualisierung mit dem gleichen Wert sein. Um die verschiedenen Optionen abzufangen gibt es die Einstellungen 'ist wahr', 'ist falsch' und so weiter. Der Punkt 'auslösung durch hat mit dem "acknowledge" status zu tun. Um den zu erklären muss ich ausholen: Wenn der ioBroker Hardware steuern will macht es sinn wenn die Software erkennt welche Änderungen von Werten eines Datenpunktes als "Aufforderung zum Schalten" interpretiert werden - im Gegensatz zu den Meldungen das ein Gerät seinen Status geändert hat. Dazu gibt es das "Acknowledge". Steuerbefehle werden immer ohne Acknowledge (also als unbestätigte Änderung) gesetzt. In Blockly gibt es dazu beim SetState die Auswahl "steuere" (ohne acknowledge als unbestätigte Änderung) und "aktualisiere" (mit acknowledge, als bestätigte Änderung). Wenn der Adapter die information bekommen hat das der Steuerbefehl ausgeführt wurde aktualisiert dieser überlicherweise den Datenpunkt (mit acknowledge). im Admin 5 wird dieses farblich dargestellt. Wertänderungen ohne acknowledge werden in rot dargestellt, Wertänderungen mit acknowledge in grün. [image: 1658831836485-80415b2b-efc8-4fac-ac74-d08d87095044-grafik.png] Aber wenn ich Euch richtig verstehe, dann wird auch bei einer "Änderung" von "wahr" auf "wahr" ausgelöst, richtig? wenn ja, was genau verursacht denn "Änderungen" von "wahr" auf "wahr"? der Wechsel von unbestätigt auf bestätigt? Bisher hatte ich nicht den Eindruck, dass mein Skript zu oft auslöst... :relaxed: Fun fact: Bei JS (und vielen anderen Programmiersprachen) gilt: true > false. Damit löst ein Trigger auf "ist grösser als" nur aus wenn sich der Wert von false auf true ändert. Ein Trigger auf "true" wird immer dann aktiv wenn der Datenpunkt mit dem Wert true beschrieben wird (also bei Änderung UND Aktualisierung) A.

@tom63 jetzt kann ich wieder kontrollieren wer zu lange duscht :wink: [image: 1658832775337-sc18-visu.jpg] meine Visualisierungsseite mit den Statistiken ...

Evtl. falls auch andere dasselbe Problem haben. Habe gerade IOB geupdatet und Node.js auf 16.16.0 gebracht -> selbes Problem wie oben beschrieben. Aber auch hier hat die Lösung von @thomas-braun geklappt, ble läuft wieder ;)

@tilly Theoretisch ja. In der Praxis können Fallstricke lauern. Je mehr am System 'rumgefrickelt' würde, umso höher die Wahrscheinlichkeit da in Stolperfallen zu laufen Auch deswegen halt der Rat, das System nicht mutwillig auf links zu drehen Das 'do-release-upgrade-Skript' geht nämlich von einem unverfummelten System aus.

Ich muss das nochmal hochholen. Es liegt definitiv am 3.xx Adapter. Ich habe die Anzahl der Werte jetzt reduziert und schreibe nur noch einmal pro Minute. Trotzdem steigt die DB beim Abrufen der Werte aus. Egal ob mit einem echart Diagramm oder im Objekt Viewer: Error in query "from(bucket: "iobroker") |> range(start: 2021-07-25T06:47:00.000Z, stop: 2022-07-25T06:46:59.999Z) |> filter(fn: (r) => r["_measurement"] == "javascript.0.Photovoltaik.Leistung_DC_komplett") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> group() |> sort(columns: ["_time"], desc: true) |> limit(n: 1)": RequestTimedOutError: Request timed out Irgendwas in dem Request passt der Datenbank nicht. Wenn ich die Abfrage auf der DB mache, zuckt die Leistung der VM noch nicht mal. Testweise nochmal 2.xx probiert. Hier läuft der Request durch.

@bananajoe war für mich bis jetzt nicht notwendig. COiOT mit der GEN1 ja alles ok. (Standard MQTT ist 1833, der Sonoff oder der Shelly-Adapter greifen sich den aber dann schon gerne) nuja, shelly verwendet 1882 als standard. mqtt adapter 1885. genau deswegen hab ich mqtt nicht verwendet. muss mich wohl mehr damit beschäftigen...

@homoran @paul53 Danke euch für eure (wie immer) perfekte Hilfe!! Ich glaube da wäre ich in 100 Jahren nicht drauf gekommen den Wert zu verändern. Jetzt geht es wieder! Danke!!

@mcu Perfekt! Vielen Dank! Das hat geholfen :D

Ich kann das bestätigen. Im Objektbaum geht es nicht. Flot gehts hab ich gestern durch echart ersetzt klasse Teil. In Echart geht es auch. Welche Datenbank nimmt ihr? History oder eine andere und warum? cu Deta

@glasfaser sagte in Adapterupdate schlägt fehl > Version dennoch hochgezogen: Nicht Böse sein ....aber : wenn man sich wie du im Beta -Zweig aufhält , kann es schon sein das es so zu diesem kommen kann . Da muß man schon sein System kennen bzw. auch mal was einstecken das sowas kommen kann . Danke für die Blumen, dessen bin ich mir durchaus bewusst und auch nicht böse. Diese Aussagen lassen sich sehr häufig hier im Forum lesen. Kann ich deiner Aussage denn entnehmen bzw. würdest du diese so umformulieren? "Wenn du NICHT im Beta-Zweig unterwegs gewesen wärst, dann wären diese Fehler NICHT aufgetaucht"? Ich danke dir.

@int17 Dann passt doch alles. Und trotzdem gibt es KEINEN Grund für ein login als root.

@haselchen Ja genau. So siehts aus :) Danke dir für deine Hilfe!

@schranzistor sagte in Zigbee DJT11LM Keine Verbindung: Namen hatte er auch sofort den gleich wie bevor die Probleme angefangen haben. ja da dieser nach der ieee id gespeichert werden...

@oliverio enter drücken! Die Vorschau ist grausam