NEWS
Problem nach Update auf Zigbee 1.18.10
-
@clfberlin
Also, ich für meinen Teil kann das reproduzieren. Neue Installation (iobroker-sandbox). Bis Zigbee 1.18.9 alles ok. Mit dem Update auf 1.18.10 beginnen bei mir die Probleme. Wäre es ein grundsätzliches Problem mit der 1.18.10, hätte es mehr Meldungen gegeben. Ich vermute, dass die Version und meine Umgebung (Synology/Docker) sich nicht mögen. Und es sieht nach Konnektivität mit dem USB-Stick aus.Starting zigbee-herdsman problem : "Error while opening serialport 'Error: Error Resource temporarily unavailable Cannot lock port'"
Ich kann jetzt das ganze Prozedere von oben wiederholen, aber es dürfte wohl auf dasselbe rauslaufen.
-
@clfberlin sagte in Problem nach Update auf Zigbee 1.18.10:
Ich vermute, dass die Version und meine Umgebung (Synology/Docker) sich nicht mögen.
das ist quack.. an der stelle wurde nix geändert..
installier mal die Adapter GIT version.
https://github.com/ioBroker/ioBroker.zigbee/wiki/GIT-install
. und check nochmal.. -
Was mir gerade bei dir auffällt :
Synology DS918+
und der Port für den Zigbeestick
ttyUSB0
Ich habe die gleiche Synology und es lüppt alles mit meinem Zigbeestick den ich mal vor Jahre bei @arteck erworben habe .
Auch unter der neuen DSM 7 , mit dem ganzen pi pa po .. USB Port freigeben / weiterleiten usw.
Jetzt kommt das aber ...
ich habe ihn , bzw. auch bis jetzt bekannte User hier im Forum ... mit Docker usw.
auf
ttyACM0
und nicht als
ttyUSB0
Das einzige was ich auf USB0 / USB1 habe , ist der Lesekopf für den Smartmeter und einen Stick Modus auf RS485.
Ich wurde mal da ein Augenmerk drauf werfen , warum er immer down geht !?
-
@glasfaser said in Problem nach Update auf Zigbee 1.18.10:
Ich habe die gleiche Synology und es lüppt alles mit meinem Zigbeestick den ich mal vor Jahre bei @arteck erworben habe .
ich habe ihn , bzw. auch bis jetzt bekannte User hier im Forum ... mit Docker usw.auf
ttyACM0
und nicht als
ttyUSB0
Ich wurde mal da ein Augenmerk drauf werfen , warum er immer down geht !?
Danke für den Hinweis. Ja, mir ist auch schon aufgefallen, dass Du auch eine DS918+ mit 16GB als Plattform nutzt.
Mein Stick ist ein (geflashter) CC2652P Sonoff ZigBee 3.0. Der läuft bei mir tatsächlich unter ttyUSB0. Ich behalte das mal auf der Liste, würde den Stick selbst bei der Fehlersuche aber erst einmal nach hinten stellen. Der ist seit genau einem Jahr im Einsatz und hat bislang tadellos funktioniert.
Auch jetzt ist alles bestens. Ich habe wieder eine Umgebung aufgesetzt, bei der ich vorsichtshalber noch bei Zigbee 1.18.9 bin und alles läuft bestens. Bei uns steuert ioBroker wirklich sehr viel. Auch die Heizung (IR-Paneele) sind bei uns von Logiken (Zeiten und Werte von Sensoren) abhängig. Daher ist es mir (und vor allem der Familie) ganz lieb, wenn wir eine laufende Basisversion haben. Zwischendurch kann ich aber immer mal den Container abstellen und eine Testinstanz aufsetzen und damit rumprobieren. Ginge es nur um die Ports und so, könnte ich ja was parallel aufsetzen. Aber es soll ja auch auf den Zigbee-Stick zugreifen.@arteck Ich konnte es zwar (bei mir) schon mehrfach reproduzieren, hoffe aber, dass es wirklich ein individuelles Problem ist.
Ich werde nachher (oder spätestens morgen) nochmal eine Installation aufsetzen und es testen. Ich probiere dann eine ganz frische Installation mit 1.18.10, einmal das besagte Update von 1.18.9, was mir Probleme bereitete und dann nochmal die GIT-Version. -
@clfberlin sagte in Problem nach Update auf Zigbee 1.18.10:
Starting zigbee-herdsman problem : "Error while opening serialport 'Error: Error Resource temporarily unavailable Cannot lock port'"
Nochmal zum mitschreiben :
-Container gestartet .....
-Instanz Zigbee kommt eine Meldung im LogStarting zigbee-herdsman problem : "Error while opening serialport 'Error: Error Resource temporarily unavailable Cannot lock port'"
du ziehst den Stick rein / raus , dann ist der Stick wieder erreichbar.
Die Instanz wird Grün , aber du kannst nicht steuern / empfangen .
Nur von der Logik her ,
ab Docker ioBroker Image 7.0.2 wird bei dem Eintrag eines z.b
USDBEVICES /dev/ttyUSB0 und -devices /dev/ttyUSB0 :/dev/ttyUSB0
genau geschaut ob /dev/ttyUSB0 vorhanden ist , das würde sonst heißen das er schon beim starten des Containers nicht vorhanden ist , dann würde aber der Container in einen loop gehen und das sieht man auch mit einer Fehlermeldung im Container Log , was ich auch dazu im anderen Thread geschrieben habe.Kannst du mal zum Test den Container die Einstellung privilege geben , was dann ist .
-
Nur von der Logik her ,
ab Docker ioBroker Image 7.0.2 wird bei dem Eintrag eines z.b
USDBEVICES /dev/ttyUSB0 und -devices /dev/ttyUSB0 :/dev/ttyUSB0
genau geschaut ob /dev/ttyUSB0 vorhanden ist , das würde sonst heißen das er schon beim starten des Containers nicht vorhanden ist , dann würde aber der Container in einen loop gehen und das sieht man auch mit einer Fehlermeldung im Container Log , was ich auch dazu im anderen Thread geschrieben habe.Kannst du mal zum Test den Container die Einstellung privilege geben , was dann ist .
Ich lege das gerne im *Privileged Mode" an. Ich bin aber nicht sicher, ob das zum obigen Fehlerbild passt, bei dem die Instanz erstmal ok scheint (grün), dann aber laufend zu Rot wechselt mit Loss bei "Lebenszeichen", dann zusätzlich "Verbunden mit Host" (während "Verbunden mit Gerät oder Dienst" erhalten bleibt. Der Adapter wird dann wieder von alleine grün und das Karussell dreht sich von vorn.
Wenn ich die Instanz aktiv neu starte, kommt Zigbee-Herdsman (während mir die Synology Konsole sagt, dass der Stick weiterhin unter /dev/ttyUSB0 aktiv ist). Ich ziehe den Stick, stecke ihn wieder ein, kontrolliere ob er auf /dev/ttyUSB0 ist. Dann starte ich die Instanz wieder und sie ist kurz aktiv, bevor sie wieder in den rot-grün-Zyklus verfällt.
Ja, der Stick klingt nach einem ganz heißen Kandidaten. Nur: Ohne Update auf 1.18.10 habe ich null Probleme. In der Version mit 1.18.9 funktioniert er wunderbar. Ich habe eben vier zusätzliche Geräte eingebunden, deren Firmware aktualisiert, sie umbenannt, Funktionen getestet... Da summt der Adapter wie ein fleißiges Bienchen.
Aber ich möchte auch wissen, was es ist. Wenn es keine anderen Meldungen gibt und @arteck ja auch sagt, dass da zur 1.8.10 nix geändert ist, dann scheint es ein ganz verqueres Einzelproblem zu sein. Aber solange ich das reproduzieren und eingrenzen kann, tue ich das gerne. Derweil läuft meine Haupt-Installation mit 1.18.9 problemlos weiter. -
@arteck und @Glasfaser
Es tut mir ja schrecklich leid, aber ich konnte das Phänomen (bei mir) wieder zielsicher reproduzieren.
Allerdings habe ich jetzt erstmal die "Privileged Mode" Option von @Glasfaser berücksichtigt. Die GIT Version probiere ich entweder etwas später heute - oder morgen. Ich muss jetzt erstmal wieder den Sandkasten räumen und meine "richtige" Umgebung wieder an den Start bekommen, bevor ich hier im Haus Klagen über nicht funktionierende Heizungen oder so höre.
Nur für das Protokoll meine Schritte:- Leeres Verzeichnis in Synology angelegt
- ein aktuelles Backup ins leere Verzeichnis
- In Portainer den Container angelegt mit latest-v7, den Ports, dem gemappten Pfad, In ENV den USB-Stick (und debug). Den Stick auch bei Runtimes als Device rein, dort auch "Privileged Mode".
- Nach dem Anlegen dann in Konsole Prozesse gestoppt und iob host this ausgeführt.
- Neustart. Login. Warten bis alle (51) Adapter geladen sind. Test. Zigbee tadellos.
- Vis 1.4.0 installiert
- Test
- Prozesse gekillt, iob uprade self (Host wollte aktualisiert werden). Danach iob upgrade.
- Gewartet, neu gestartet, getestet - oben beschriebene Probleme mit Zigbee. Ergänzend muss ich aber sagen, dass meine Erstaussage ("leer") nicht ganz korrekt war. Es dauert nur unerwartet lange (nach dem Start einige Minuten), bis die Devices da auftauchen. Aber funktionieren tut es dann halt auch nicht.
- Ein paar Mal Karussell gefahren. Also: Adapter grün, rot, grün, rot... Manuell gestartet. Zigbee Herdsman. Stick raus und rein. Gestartet. Wieder grün, dann rot...
-
Puhh ... ich muß dich sehr loben bei deiner ausführlichen Vorgehensweise .....
Was auch sein kann ... du testet , bzw. du bist ja auf 7.2.0 latest
was ist mit deiner alten Version v7.1.2
-
@glasfaser
Danke. Ich brauche selber etwas Struktur beim Vorgehen, um mich nicht zu verzetteln oder später nochmal nachschauen zu können.was ist mit deiner alten Version v7.1.2
Die ehemalige 7.1.2 schien ja bereits vorher nicht ganz sauber zu sein. Ich dachte zwar, mit dem Löschen des Wetter-Adapters mit den Errors sei es behoben. Aber keine zwei Tage später hatte ich nach dem Update dann wieder den Fehler, dass er Admin nicht finden könne. Dein Rat war genau richtig: Ich habe das morsche Schiff sinken lassen und ein neues vom Stapel gelassen. Mit Euren Hinweisen (host this, dem Installieren von VIS1.4.0 etc.) geht das ja dann auch recht flott. Ich hatte halt ein paar Stunden Konfigurations- und Visualisierungskram verloren - aber Schuld eigene, dass ich vor dem Update nicht nochmal ein Backup gemacht hatte.
Die jetzige Installation läuft reibungslos (ist auch im Moment wieder aktiv). Und wenn das mit dem 1.18.10 Problem bei mir reproduzierbar ist, ist das ja zunächst einmal eine gute Sache. So lässt es sich ja dann vielleicht auch eingrenzen.
Ich würde beim nächsten Mal so vorgehen wie oben, dann aber nicht in der Konsole das Upgrade laufen lassen, sondern so wie @arteck es gemeint hat (GIT-Version). Den "Privileged Mode" behalte ich aber mal bei. -
@clfberlin sagte in Problem nach Update auf Zigbee 1.18.10:
Gewartet, neu gestartet, getestet - oben beschriebene Probleme mit Zigbee. Ergänzend muss ich aber sagen, dass meine Erstaussage ("leer") nicht ganz korrekt war. Es dauert nur unerwartet lange (nach dem Start einige Minuten), bis die Devices da auftauchen. Aber funktionieren tut es dann halt auch nicht.
Ein paar Mal Karussell gefahren. Also: Adapter grün, rot, grün, rot... Manuell gestartet. Zigbee Herdsman. Stick raus und rein. Gestartet. Wieder grün, dann rot...kannst du mal bei deinem nächsten test exakt die folgende Reihenfolge einhalten:
- zigbee adapter anhalten
- sicherstellen das der zigbee adapter nicht mehr läuft
- Stick abziehen
- Stick anstecken
- log löschen oder Markierung im Log setzten
- Zigbee adapter starten - warten bis er zum 3. mal grün wird, dann wieder anhalten
- log herunter laden und posten
Zusätzlich bitte per 'npm list -a' heraus bekommen welche Versionen der folgenden Bibliotheken installiert sind:
- zigbee-herdsman-converters
- zigbee-herdsman
- serialport
Wichtig: Insbesondere die Serialport Bibliothek kann es in verschiedenen Versionen mehrfach geben - in diesem Fall wäre wichtig wo sie sich im Baum befindet (Siehe Beispiel)
└─┬ iobroker.zigbee@1.8.9 ├── @iobroker/adapter-core@2.6.7 deduped ├── serialport@10.5.0 deduped ├── tar@6.1.13 deduped
Auffällig ist das keine Serielle Schnittstelle als "available" im 1.8.10 angezeigt werden:
2023-01-05 17:16:32.648 - info: zigbee.0 (519) List of port: []
An dieser Stelle sollten eigentlich die verfügbaren seriellen Schnittstellen für den Adapter aufgelistet werden
A.
-
Das Laden der 50+ Adapter dauert immer etwas. Naja, in der Zwischenzeit kann ich mir ja noch was vom Kurs von Matthias Kleine anschauen. Das macht er echt ganz gut. Wobei ich hier auch jeden Tag was dazu lerne.
Sodele. Jetzt hat er alle Adapter geladen. Vorgehen war wie oben beschrieben. Alles vorbereitet, aber diesmal lade ich im letzten Schritt das Update von GIT anstatt über Konsolen-Upgrade. Mal schauen, ob es damit auch auftritt. Dann kann ich gleich die Hausaufgaben erledigen, die mir @Asgothian aufgegeben hat.
So, Host ist auf aktuellem Stand, Instanzen sind gestartet, VIS ist jetzt via Version 1.4.0 + Upgrade auch lauffähig.
Noch schnell einen Stand 'npm list -' vor dem Update.
├─┬ iobroker.zigbee@1.8.9 │ ├── @iobroker/adapter-core@2.6.7 deduped │ ├── serialport@10.5.0 deduped │ ├── tar@6.1.13 deduped │ ├── typescript@4.9.4 │ ├─┬ zigbee-herdsman-converters@14.0.687 │ │ ├─┬ axios@1.1.3 │ │ │ ├── follow-redirects@1.15.2 deduped │ │ │ ├── form-data@4.0.0 deduped │ │ │ └── proxy-from-env@1.1.0 deduped │ │ ├── buffer-crc32@0.2.13 │ │ ├── https-proxy-agent@5.0.1 deduped │ │ ├── tar-stream@2.2.0 deduped │ │ └── zigbee-herdsman@0.14.80 deduped │ └─┬ zigbee-herdsman@0.14.80 │ ├── @serialport/bindings-cpp@10.8.0 deduped │ ├── @serialport/parser-delimiter@10.5.0 deduped │ ├── @serialport/stream@10.5.0 deduped │ ├── debounce@1.2.1 │ ├─┬ debug@4.3.4 │ │ └── ms@2.1.2 │ ├── fast-deep-equal@3.1.3 │ ├── mixin-deep@2.0.1 │ ├─┬ mz@2.7.0 │ │ ├── any-promise@1.3.0 │ │ ├── object-assign@4.1.1 deduped │ │ ─┬ thenify-all@1.6.0 │ │ └─┬ thenify@3.3.1 │ │ └── any-promise@1.3.0 deduped │ └── slip@1.0.2
Und jetzt das Update via GIT.
Ja, es dauert wieder sehr lange, bis Devices auftauchen.Mist, ich habe was anders gemacht als vorher: Adapter war beim Update nicht gestartet. Muss ich ggf. nochmal wiederholen.
Stand jetzt aber:Adapter bleibt gelb, obwohl laut Konsole /dev/ttyUSB0 da ist.
Diesmal also gar nicht erst verbunden. Und er wirft auch nur stumpf Verbindungsfehler.2023-01-06 21:03:52.827 - info: zigbee.0 (2474) starting. Version 1.8.10 (non-npm: ioBroker/ioBroker.zigbee) in /opt/iobroker/node_modules/iobroker.zigbee, node: v16.19.0, js-controller: 4.0.24 2023-01-06 21:03:52.941 - info: zigbee.0 (2474) Starting Zigbee npm ... 2023-01-06 21:03:53.456 - error: zigbee.0 (2474) Starting zigbee-herdsman problem : "Error while opening serialport 'Error: Error: Permission denied, cannot open /dev/ttyUSB0'" 2023-01-06 21:03:53.458 - error: zigbee.0 (2474) Failed to start Zigbee 2023-01-06 21:03:53.458 - error: zigbee.0 (2474) Error herdsman start 2023-01-06 21:03:53.462 - info: zigbee.0 (2474) Installed Version: ioBroker/ioBroker.zigbee 2023-01-06 21:04:03.463 - info: zigbee.0 (2474) Try to reconnect. 1 attempts left 2023-01-06 21:04:03.464 - info: zigbee.0 (2474) Starting Zigbee npm ... 2023-01-06 21:04:03.487 - info: zigbee.0 (2474) Installed Version: ioBroker/ioBroker.zigbee 2023-01-06 21:04:03.514 - error: zigbee.0 (2474) Starting zigbee-herdsman problem : "Error while opening serialport 'Error: Error: Permission denied, cannot open /dev/ttyUSB0'" 2023-01-06 21:04:03.516 - error: zigbee.0 (2474) Failed to start Zigbee 2023-01-06 21:04:03.516 - error: zigbee.0 (2474) Error herdsman start 2023-01-06 21:04:49.295 - info: host.40b66a7f9244 "system.adapter.zigbee.0" disabled 2023-01-06 21:04:49.295 - info: host.40b66a7f9244 stopInstance system.adapter.zigbee.0 (force=false, process=true) 2023-01-06 21:04:49.308 - info: zigbee.0 (2474) Got terminate signal TERMINATE_YOURSELF 2023-01-06 21:04:49.489 - info: host.40b66a7f9244 stopInstance system.adapter.zigbee.0 send kill signal 2023-01-06 21:04:50.490 - info: host.40b66a7f9244 stopInstance system.adapter.zigbee.0 killing pid 2474 2023-01-06 21:04:49.311 - info: zigbee.0 (2474) cleaned everything up... 2023-01-06 21:04:49.499 - info: zigbee.0 (2474) Zigbee: disabling joining new devices. 2023-01-06 21:04:50.664 - warn: zigbee.0 (2474) Failed to stop zigbee during startup 2023-01-06 21:04:50.665 - info: zigbee.0 (2474) terminating 2023-01-06 21:04:50.666 - info: zigbee.0 (2474) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason 2023-01-06 21:04:51.285 - info: host.40b66a7f9244 instance system.adapter.zigbee.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION) 2023-01-06 21:05:30.524 - info: zigbee.0 (2583) starting. Version 1.8.10 (non-npm: ioBroker/ioBroker.zigbee) in /opt/iobroker/node_modules/iobroker.zigbee, node: v16.19.0, js-controller: 4.0.24 2023-01-06 21:05:30.641 - info: zigbee.0 (2583) Starting Zigbee npm ... 2023-01-06 21:05:31.119 - error: zigbee.0 (2583) Starting zigbee-herdsman problem : "Error while opening serialport 'Error: Error: Permission denied, cannot open /dev/ttyUSB0'" 2023-01-06 21:05:31.120 - error: zigbee.0 (2583) Failed to start Zigbee 2023-01-06 21:05:31.121 - error: zigbee.0 (2583) Error herdsman start 2023-01-06 21:05:31.125 - info: zigbee.0 (2583) Installed Version: ioBroker/ioBroker.zigbee 2023-01-06 21:05:41.124 - info: zigbee.0 (2583) Try to reconnect. 1 attempts left 2023-01-06 21:05:41.125 - info: zigbee.0 (2583) Starting Zigbee npm ... 2023-01-06 21:05:41.148 - info: zigbee.0 (2583) Installed Version: ioBroker/ioBroker.zigbee 2023-01-06 21:05:41.177 - error: zigbee.0 (2583) Starting zigbee-herdsman problem : "Error while opening serialport 'Error: Error: Permission denied, cannot open /dev/ttyUSB0'" 2023-01-06 21:05:41.178 - error: zigbee.0 (2583) Failed to start Zigbee 2023-01-06 21:05:41.179 - error: zigbee.0 (2583) Error herdsman start
Hier habe ich Mist gebaut. Der Fehler von oben lässt sich nicht reproduzieren. Diesmal kein Wechsel grün, rot, grün, rot... Aber da ich etwas anders gemacht habe als vorher, gibt es zwei Möglichkeiten:
- Die GIT-Version verhält sich anders
oder - Die Tatsache, dass der Adapter vor dem Update noch nicht aktiviert war, hat einen Unterschied gemacht.
Da werde ich wohl nochmal ran müssen. Hier übrigens noch 'npm list -a' nach dem Update.
─┬ iobroker.zigbee@1.8.10 (git+ssh://git@github.com/ioBroker/ioBroker.zigbee.git#ce1d50e161fe21cc2ebcf66c660b23f20c6e62b6) ├── @iobroker/adapter-core@2.6.7 deduped ├── serialport@10.5.0 deduped ├── tar@6.1.13 deduped ├── typescript@4.9.4 ├─┬ zigbee-herdsman-converters@15.0.16 │ ├─┬ axios@1.2.2 │ │ ├── follow-redirects@1.15.2 deduped │ │ ├── form-data@4.0.0 deduped │ │ └── proxy-from-env@1.1.0 deduped │ ├── buffer-crc32@0.2.13 │ ├── https-proxy-agent@5.0.1 deduped │ ├─┬ tar-stream@3.0.0 │ │ ├── b4a@1.6.1 │ │ ├─┬ bl@6.0.0 │ │ │ ├─┬ buffer@6.0.3 │ │ │ │ ├── base64-js@1.5.1 deduped │ │ │ │ └── ieee754@1.2.1 deduped │ │ │ ├── inherits@2.0.4 deduped │ │ │ └─┬ readable-stream@4.3.0 │ │ │ ├─┬ abort-controller@3.0.0 │ │ │ │ └── event-target-shim@5.0.1 │ │ │ ├── buffer@6.0.3 deduped │ │ │ ├── events@3.3.0 │ │ │ └── process@0.11.10 deduped │ │ └─┬ streamx@2.13.0 │ │ ├── fast-fifo@1.1.0 │ │ └── queue-tick@1.0.1 │ └── zigbee-herdsman@0.14.83 deduped └─┬ zigbee-herdsman@0.14.83 ├── @serialport/bindings-cpp@10.8.0 deduped ├── @serialport/parser-delimiter@10.5.0 deduped ├── @serialport/stream@10.5.0 deduped ├── debounce@1.2.1 ├─┬ debug@4.3.4 │ └── ms@2.1.2 ├── fast-deep-equal@3.1.3 ├── mixin-deep@2.0.1 ├─┬ mz@2.7.0 │ ├── any-promise@1.3.0 │ ├── object-assign@4.1.1 deduped │ └─┬ thenify-all@1.6.0 │ └─┬ thenify@3.3.1 │ └── any-promise@1.3.0 deduped └── slip@1.0.2
Jetzt die Frage: Soll ich nochmal das Vorgehen von zuvor wiederholen (diesmal mit vorherigem Laufen des 1.18.9 Adapters) und für @arteck herausfinden, ob sich die GIT Version anders verhält als das Update via Konsolen-Upgrade?
Oder soll ich das Problem nochmal reproduzieren wie zuvor? Also mit Konsolen-Upgrade, um @Asgothian die Infos zu liefern, was beim rot-grün-rot-grün Karussell passiert?Derweil habe ich wieder meine Produktivumgebung am Start - mit der 1.18.9. Da schnurrt alles gewohnt reibungslos.
PS: Den Stick hatte ich übrigens nach dem obigen Log nicht mehr angerührt. Der Container mit der 1.18.9 hat ihn sofort erkannt und genutzt.
- Die GIT-Version verhält sich anders
-
@clfberlin sagte in Problem nach Update auf Zigbee 1.18.10:
Permission denied
ls -la /dev/ttyUSB0 sudo -u iobroker group ls -lA /dev/serial/by-id
sagt?
Edit: Ach Sinnlosygy. Da ist wieder alles anders.
-
Edit: Ach Sinnlosygy. Da ist wieder alles anders.
Wollte gerade sagen: Im Bash des Portainer-Containers der Synology gibt es nur ein müdes...
root@40b66a7f9244:/opt/iobroker# ls -la /dev/ttyUSB0 crw------- 1 root root 188, 0 Jan 6 21:37 /dev/ttyUSB0
Beim Lesen Deines Namens zucke ich immer leicht zusammen. Hatte einen gleichnamigen Klassenkameraden.
-
@clfberlin sagte in Problem nach Update auf Zigbee 1.18.10:
Hatte einen gleichnamigen Klassenkameraden.
Lustig. Ich auch. Hat unsere Lehrer immer bei der Rückgabe von Klausuren verwirrt. 'Welcher Braun issen das jetzt?!?!'
-
@clfberlin sagte in Problem nach Update auf Zigbee 1.18.10:
Jetzt die Frage: Soll ich nochmal das Vorgehen von zuvor wiederholen (diesmal mit vorherigem Laufen des 1.18.9 Adapters) und für @arteck herausfinden, ob sich die GIT Version anders verhält als das Update via Konsolen-Upgrade?
Aus meiner Sicht ist das nicht notwendig. Sofern es Probleme mit der aktuellen Version im Stable gibt die in der .git Version behoben sind kann @arteck die auf NPM austauschen.
Ursache sind die Zugriffsrechte auf den Port.
2023-01-06 21:03:52.941 - info: zigbee.0 (2474) Starting Zigbee npm ... 2023-01-06 21:03:53.456 - error: zigbee.0 (2474) Starting zigbee-herdsman problem : "Error while opening serialport 'Error: Error: Permission denied, cannot open /dev/ttyUSB0'" 2023-01-06 21:03:53.458 - error: zigbee.0 (2474) Failed to start Zigbee
Am Zigbee-Adapter selber wurde nicht viel geändert, einzig die verwendeten Bibliotheken (Zigbee-Herdsman-Converters) wurden aktualisiert. Im Bereich des Zigbee-Herdsman wurde an der Auswahl des Serialports gedreht.
Warum der 1.8.9 läuft (im gleichen container ???) kann ich nicht sagen. Wenn es ein anderer Container ist sollte klar sein wo klar sein wo das Problem liegt.
A.
-
@clfberlin
Bei den Rechten ist es auch kein Wunder, dass der 'iobroker' da nix darf.
Hier sieht das so aus:echad@chet:~ $ ls -la /dev/ttyUSB0 ls -lA /dev/serial/by-id crw-rw---- 1 root dialout 188, 0 Jan 6 21:13 /dev/ttyUSB0
Und da der 'iobroker' in der Gruppe 'dialout' ist schaut der da auch nicht in die Röhre. Wie das jetzt auf dem krüppeligen Container/Docker/was-weiß-ich läuft: Keine Ahnung. Muss wohl irgendwie anders durchgereicht werden.
-
@thomas-braun
Ja, in meinem funktionierenden Container:root@8eb11a223384:/opt/iobroker# ls -la /dev/ttyUSB0 crw-rw---- 1 root dialout 188, 0 Jan 6 22:14 /dev/ttyUSB0
Das Witzige: im Sandkasten-Container funktioniert alles tadellos - solange ich auf 1.18.9 bin. Sobald ich das Update auf 1.18.10 mache, ist der Schlamassel da.
-
Container-Mumpitz halt...
-
Warum der 1.8.9 läuft (im gleichen container ???) kann ich nicht sagen. Wenn es ein anderer Container ist sollte klar sein wo klar sein wo das Problem liegt.
Ja, genau das ist das Problem: Selber Container - 1.18.9 - alles schnurrt. Update auf 1.18.10 - Verbindungsprobleme. Ließ sich alles wunderbar reproduzieren.
-
Container-Mumpitz halt...
Ja, ist nicht jedermanns Sache. Ich mag die Container und die Synology. Die Kiste läuft eh (Foto-Speicher, Kameras, Cloud). Da ist es für mich sinnvoller, die Anwendungen (Unifi Controller, ioBroker, InfluxDB etc.) gleich mit laufen zu lassen. RasPi ist schöner (und spricht auch eher meinen Spieltrieb an), wäre für mich aber nur eine zusätzliche Sache, die laufen muss.