Neues YouTube-Video: Visualisierung im Devices-Adapter

[Zarello]

@andreas-s Könnte es evtl. ein Hardware-Problem sein? Hast Du mal geguckt, ob der Adapter noch erkannt wird (z.B. mit lsusb in der Shell auf dem Raspi)?

[arteck]

@andreas-s sagte in Ausfall einer Zigbee Instanz:

Hat jemand eine Idee abseits von komplett neu Aufbauen?

klar viele.... lass die finger von Backup zurückspielen.. wenn was nicht läuft..

also zigbee.1 oder zigbee.0 läuft nicht ? das kann ich aus deinem Post nicht erkennen..

[Andreas.S]

@arteck zigbee.0 läuft nicht

[Andreas.S]

@zarello said in Ausfall einer Zigbee Instanz:

lsusb

scheint alles noch da zu sein - insbesondere der CC1352R1

Bus 002 Device 002: ID 04e8:61f5 Samsung Electronics Co., Ltd Portable SSD T5
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0451:bef3 Texas Instruments, Inc. CC1352R1 Launchpad
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

[arteck]

@andreas-s

ok dann auf dem master

auf der konsole

ls /opt/iobroker/iobroker-data/zigbe.0

ergebniss posten

[Andreas.S]

@arteck said in Ausfall einer Zigbee Instanz:

ls /opt/iobroker/iobroker-data/zigbe.0

Nach einigen Neustarts ist nun plötzlich die Zigbee.0 Instanz wieder GRÜN.
Mit einem Klick auf den Schraubenschlüssel sind nun auch alle Geräte wieder da.
Einziger Wermutstropfen - keines dieser Zigbee-Geräte antwortet.
Beispiel - wenn ich einen Switch umstelle, tut das wohl auf dem Bildschirm, aber noch nicht an Schalter.

das mit ls war auch nicht sehr erfolgreich...

pi@raspberrypi:~ $ ls /opt/iobroker/iobroker-data/zigbe.0
ls: cannot access '/opt/iobroker/iobroker-data/zigbe.0': No such file or directory

[arteck]

@andreas-s
da fehlt ja auch ein e

ls /opt/iobroker/iobroker-data/zigbee.0

[Asgothian]

@arteck sagte in Ausfall einer Zigbee Instanz:

@andreas-s
da fehlt ja auch ein e

ls /opt/iobroker/iobroker-data/zigbee.0

und an Stelle des . muss noch ein _ hin:

 ls /opt/iobroker/iobroker-data/zigbee_0

[Andreas.S]

@asgothian said in Ausfall einer Zigbee Instanz:

ls /opt/iobroker/iobroker-data/zigbee_0

Da kommt jetzt was...

pi@raspberrypi:~ $  ls /opt/iobroker/iobroker-data/zigbee_0
backup_2022_04_05-15_48_43.tar.gz  backup_2022_04_05-16_32_23.tar.gz  backup_2022_04_05-17_55_03.tar.gz  nvbackup.json  shepherd.db

[Andreas.S]

@andreas-s
Gerade stellt sich mir die Frage, da die Fehler jetzt weg sind, auch beim Aufruf von der Backup-Instanz, ob ich einfach Zigbee_0 von vor einem Monat zurückspiele. Bis dahin habe ich eine täglich Sicherung auf meiner NAS. Das hat erst am 10.3. mit Fehlerauftritt aufgehört.

[arteck]

@andreas-s da sind 3 backups... drin... kein plan was da du angestellt hast..
kopiere den zigbee_0 ordner aus DEINER Sicherung zurück

[Andreas.S]

@arteck
Sorry aber jetzt bin ich nicht ganz sicher...
Den Zigbee_0 Ordner von der Sicherung auf der NAS vor einem Monat oder von der Sicherung heute?
Meinst du mit Kopieren via Menü im Backup-Tool vom iobroker oder über WinSCP direkt?

[arteck]

@andreas-s DEINE vom NAS die vor einem monat..mit winscp..evtl musst du die Geräte die du vermisst neu anlernen.. aber nur anlernen nix löschen

[Andreas.S]

@arteck
Danke für deine Antwort.
Wie oben erwähnt, sind seit Gestern ALLE Geräte wieder da.
Nur haben die jeweils keine Verbindung.

Ich habe es bei einem mal mit dem Button "Reconfigure" versucht. Muss ich dazu das Gerät wieder in den Pairing Modus bringen?

[Andreas.S]

@andreas-s
Heute Morgen habe ich dieses seltsame Protokoll gesehen

zigbee.0 8855	2022-04-06 07:46:34.596	info	Zigbee started
zigbee.0 8855	2022-04-06 07:46:34.594	info	0x60a423fffeb29ead (addr 22336): ZTS-EU_3gang - Moes Wall touch light switch (3 gang) (EndDevice)
zigbee.0 8855	2022-04-06 07:46:34.575	info	Currently 1 devices are joined:
zigbee.0 8855	2022-04-06 07:46:34.559	info	--> transmitPower : normal
zigbee.0 8855	2022-04-06 07:46:34.541	info	Unable to disable LED, unsupported function.
zigbee.0 8855	2022-04-06 07:46:34.534	info	Coordinator firmware version: {"type":"zStack3x0","meta":{"transportrev":2,"product":1,"majorrel":2,"minorrel":7,"maintrel":1,"revision":20200805}}
zigbee.0 8855	2022-04-06 07:46:34.280	info	Installed Version: iobroker.zigbee@1.6.16
zigbee.0 8855	2022-04-06 07:46:33.772	info	Starting Zigbee npm ...
zigbee.0 8855	2022-04-06 07:46:33.656	info	starting. Version 1.6.16 in /opt/iobroker/node_modules/iobroker.zigbee, node: v12.22.7, js-controller: 4.0.21
zigbee.0 7051	2022-04-06 07:45:59.337	warn	Terminated (UNCAUGHT_EXCEPTION): Without reason
zigbee.0 7051	2022-04-06 07:45:59.332	info	terminating
zigbee.0 7051	2022-04-06 07:45:58.841	info	Zigbee: disabling joining new devices.
zigbee.0 7051	2022-04-06 07:45:58.831	info	cleaned everything up...
zigbee.0 7051	2022-04-06 07:45:58.816	error	Cannot read property 'mapped' of undefined
zigbee.0 7051	2022-04-06 07:45:58.815	error	TypeError: Cannot read property 'mapped' of undefined at Zigbee.publishFromState (/opt/iobroker/node_modules/iobroker.zigbee/main.js:499:36) at runMicrotasks (<anonymous>) at processTicksAndRejections (internal/process/task_queues.js:97:5)
zigbee.0 7051	2022-04-06 07:45:58.812	error	unhandled promise rejection: Cannot read property 'mapped' of undefined
zigbee.0 7051	2022-04-06 07:45:58.810	error	Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().

[Andreas.S]

@andreas-s
Ich habe nun das eine Gerät gesucht, das im Protokoll angezeigt wird.
Und tatsächlich ist seit heute Morgen eines der 37 Geräte wieder verbunden.
Dafür wurde das benannte Objekt offenbar rausgeschmissen und das Gerät neu ohne Namen eingefügt.
Mal sehen wie das weiter geht. Da ich alles über den Alias Adapter gemacht habe, sind die benannten Datenpunkte für diesen einen Taster auch wieder verfügbar.

[arteck]

@andreas-s sagte in Ausfall einer Zigbee Instanz:

zigbee.0 8855 2022-04-06 07:46:34.575 info Currently 1 devices are joined:

dir fehlt die alte (deine Monatssicherung) shepherd.db da stehen die Gerätedefinitionen drin..

[Andreas.S]

@arteck
also das mit dem Sicherung zurückspielen geht nicht über den Backup Adapter. Der löscht das Verzeichnis Zigbee_0 hört dann aber mit Error auf.
Beim kompletten Verzeichnis manuell kopieren, meckert er auch mit extrem vielen Fehlern.

ABER den Stand von Gestern Abend und nur die shepherd.db austauschen --> das funktioniert!!!!!

Nur die dev_names.json scheint neu seit Adapter-Update. Da stehen jetzt noch nicht die korrekten Namen drin.

Aber ich bin erst mal Happy --> Vielen Dank

Heute Abend wird die komplette SSD wieder mit belenaEtcher gecloned. Die Art der Sicherung hat sich als sehr stabil erwiesen.

[Andreas.S]

@andreas-s
Es ist zum heulen!
Heute Morgen iob gestoppt und die SSD auf das baugliche Modell gecloned.
Neustart - nun geht die Instanz Zigbee_1 (am slave) nicht mehr. Der slave wurde nicht angerührt.
Die Instanz Zigbee_1 bleibt auf gelb (Ausrufezeichen) stehen. Es gibt KEINEN Protokolleintrag. Die Instanz lässt sich nicht stoppen oder neu starten. Die shepherd.db ist am Slave und am Host im Verzeichnis vorhanden. Aber es tut sich nix.
Übrigens bei beiden SSDs gleiches Ergebnis.

[Asgothian]

@andreas-s sagte in Ausfall einer Zigbee Instanz:

Die Instanz Zigbee_1 bleibt auf gelb (Ausrufezeichen) stehen. Es gibt KEINEN Protokolleintrag. Die Instanz lässt sich nicht stoppen oder neu starten. Die shepherd.db ist am Slave und am Host im Verzeichnis vorhanden. Aber es tut sich nix.

Es muss einen Protokolleintrag geben, es sei denn du hast den Log-Modus so eingestellt das ausschliesslich Fehlermeldungen protokolliert werden.

Bitte das Log vom Startversuch posten.

A.