NEWS

@homoran

Besser: Man nutzt npm gar nicht direkt sondern installiert mit iobroker add
Dann ist es egal.

Das Spuckt das Log aus
lcn.0
2022-08-06 00:59:48.920 error [CONN] No data. Reconnecting...
lcn.0
2022-08-06 00:59:48.919 debug [CONN] Changing state: WAIT_PASS => WAIT_AUTH_OK
lcn.0
2022-08-06 00:59:48.919 debug [CONN] received: Password:
lcn.0
2022-08-06 00:59:48.918 debug [CONN] Changing state: WAIT_USER => WAIT_PASS
lcn.0
2022-08-06 00:59:48.918 debug [CONN] received: Username:
lcn.0
2022-08-06 00:59:48.908 debug [CONN] Changing state: WAIT_PROMPT => WAIT_USER
lcn.0
2022-08-06 00:59:48.908 debug [CONN] received: nullLCN-PCK/IP 1.0
lcn.0
2022-08-06 00:59:48.907 debug [CONN] Changing state: CONNECTING => WAIT_PROMPT
lcn.0
2022-08-06 00:59:18.404 debug [CONN] Changing state: WAIT_AUTH_OK => CONNECTING

@mickym
Ja ich kann Pingen und auch vom Pi auf der Fritzbox alles machen. Das mit den netzmasken past.
Ich habe dies auch schon. Ich habe auch schon auf /16 umgestellt, auch ohne Erfolg.
Wie kann ich überprüfen ob die Box auf den Port reagiert?

ABER:
Ich habe den Fehler gefunden:😀
Ich habe eine FW im Netzt welche eine DMZ bedient. Hier habe ich expliziert die Route iobroker fritz box gesperrt, und siehe da, es geht jetzt.
Ich habe es mit traceroute gefunden, das ein falscher Weg eingeschlagen wurde. Warum auch immer ich die box anpingen konnte und mit chromium die Fritz Box vom Pi erreichen konnte?

Netzwerkwege sind schon seltsam

Danke deine Gedanken haben mich auf den richtigen Weg gebracht

Das Problem hatte ich letzte Woche und wurde durch ein Sonderzeichen im Passwort verursacht (vermutlich - zumindest bei mir).
Nachdem ich das Sonderzeichen entfernt , die CLients aktualisiert und den Adapter neu gestartet hatte , kam keine Meldung mehr

@p-lang

iobroker stop iobroker fix iobroker start

und die jetzt verbogenen Rechte sollten wieder passen.
Darüber hinaus bitte im GitHub ein issue hinterlegen, da muss sich vielleicht nochmal jemand die Deps anschauen.

@padi0-000
puTTY ist auch nur ein Terminal. Du musst die Datei schon editieren, geht z.B. mit
nano

@jörg-heilig sagte in Cannot install any adaptors 190:

I would really appreciate help here.

warum auf Englisch?
und das auch noch im deutschen Teil 😂

@jörg-heilig sagte in Cannot install any adaptors 190:

ERROR: Process exited with code 25

gibt es einige Threads zu.

@jörg-heilig sagte in Cannot install any adaptors 190:

If I do it from the admin UI I get:
$ iobroker add knx --host JoergsMac.fritz.box

und was bekommst du über die Konsole mit angehängtem --debug

@oliverio im Prinzip schon ... aber etwas spooky mit Austausch im Live-Betrieb

@andi-luma
Nachtrag , der Adapter ist komplett grün , für die vorher vorhandenen BLE Geräte werden keine aktualisierten Daten angezeigt , auch nicht wenn die Suche mit * eigentlich ja alle Geraete in der Naehe "finden" sollte
Adapter bereits wieder deinstalliert und noch einmal die Version 0.12 wieder installiert ( hatte monatelang funktioniert ) aber die findet dann auch nichts / aktualisiert nicht mehr.
Driverstate is poweredOn
AllowNew device : true

Log vom Start
starting scan for services []

ble.0
2022-08-02 16:43:08.007 info starting scanner process...
ble.0
2022-08-02 16:43:07.986 info monitoring all services
ble.0
2022-08-02 16:43:07.985 info enabled plugins: _default
ble.0
2022-08-02 16:43:07.984 info loaded plugins: Xiaomi, mi-flora, ruuvi-tag, _default
ble.0
2022-08-02 16:43:07.920 info starting. Version 0.13.0 in /opt/iobroker/node_modules/iobroker.ble, node: v16.16.0, js-controller: 4.0.23

@holgerwolf
Also ich habe jetzt bestimmt 20 Datenpunkte unterschiedlichster Art aufgerufen und bei Allen gab es das Phänomen...leider.

Super, DANKE FÜR EURE HILFE! Meine Scripte laufen wieder !!! 🙂 GELÖST!

@homoran sagte in täglich ein Fehler im Log - UV Protect Adapter:

HTML 503 ist service not available

ah, verstehe. dachte es geht um den iobroker.
als "echte" Lösung müsste also der Adapter bei diesem 503 Fehler erneut eine Anfrage schicken?
achso, das geht ja nicht da es nur eine begrenzte Anzahl gibt die man täglich stellen darf.
dann werd ich wohl damit leben. Aber wie erwähnt, es ist kein großes Problem.

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.

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

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 😉
SC18-Visu.jpg
meine Visualisierungsseite mit den Statistiken ...