[gelöst] Plötzliches deconz-Problem

Begonnen von alanblack, 07 Juni 2020, 09:12:17

Vorheriges Thema - Nächstes Thema

alanblack

Einen schönen Sonntag Morgen an alle!

Hoffentlich besser als für mich gerade.  :o

Bis gestern Abend liefen alle Lichter und Sensoren einwandfrei.
Heute morgen bemerkte ich, dass keine Lichter angehen. Strom war da, aber die automatisch über FHEM und deconz gesteuerten Lichter gingen nicht an.
FHEM lief ohne Mucken.
Der Pi, auf dem deconz/Phoscon läuft war pingbar (daher keine Warnung von FHEM, welches diesen Pi per PRESENCE überwacht), aber weder per Phoscon noch über SSH erreichbar.
Also zog ich schweren Herzens kurz den Stecker. Nach dem Booten waren auch Phoscon und SSH wieder da. Die Sensoren arbeiten auch wieder sauber und es kommt auch alles aus Phoscon in FHEM an. Auch wenn ich in FHEM ein Licht schalte, kommt das in Phoscon an... nur die physikalische Lampe bleibt aus. Und dabei ist es egal, ob es eine HUE, eine Tradfri oder eine SMART-Steckdose ist. (Auch dem Kaffee musste ich manuell anwerfen.   >:()

Ich habe auch mal zwei Lampen versucht zu reseten und neu zu verbinden, was aber nicht funktionierte. Diese zeigt Phoscon jetzt als nicht erreichbar an.

Das syslog auf dem Pi ist unauffällig. Der letzte Eintrag vor dem Coldboot war ein cron-Job. Ob der die Ursache für den teilweisen Freeze war, prüfe ich noch, bezweifle ich aber.

Hat hier dazu eine eine Idee?

Danke im Voraus!
FHEM 6.0 auf raspi3&ODROID XU4 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433, Xiaomi Aqara+div. Zigbee via deCONZ, Dooya via SIGNALDuino, ZWave mit Danalock
Jeder Witz kann ein Einzeiler sein mit genügend Semikolons

MadMax-FHEM

Welche Version von deCONZ läuft denn?

Hatte (ganz) früher mal einen "Speicherfresser" bemerkt...

Weiß nicht, ob ich danach mehr als Booten musste...

Zurücksetzen: warum immer so fix so "brutal"!? ;)

Bei mir reicht bei "sowas": Lampe vom Strom, WARTEN und wieder "anklemmen"...
(hab letztens geupdated auf Buster und neuestes deCONZ und ein wenig "rumexperimentiert", danach ähnlich: fhem sagt ok, deCONZ eigentlich auch aber Lampe nix)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

alanblack

Hallo Joachim,

danke für die schnelle Antwort!

Zitat von: MadMax-FHEM am 07 Juni 2020, 09:52:31
Welche Version von deCONZ läuft denn?
2.05.73 stable - also nicht ganz aktuell

Zitat
Hatte (ganz) früher mal einen "Speicherfresser" bemerkt...

Weiß nicht, ob ich danach mehr als Booten musste...
Auf diesem Pi laufen nur deconz und Logitech-Mediaserver. Speichertechnisch war hier nie etwas auffälliges. Inzwischen tippe ich darauf, dass die Ursache für den Absturz die SD-Karte war. Die klone ich gerade.

Zitat
Zurücksetzen: warum immer so fix so "brutal"!? ;)

Bei mir reicht bei "sowas": Lampe vom Strom, WARTEN und wieder "anklemmen"...
(hab letztens geupdated auf Buster und neuestes deCONZ und ein wenig "rumexperimentiert", danach ähnlich: fhem sagt ok, deCONZ eigentlich auch aber Lampe nix)
Sorry, das hatte ich als selbstverständlich angesehen und damit nur mit "Strom war da,..." beschrieben.
Dass ab und zu mal EINE Lampe ein Zombie wird, bin ich fast schon gewohnt. Meistens ist es eine HUE. Manchmal reicht das trennen vom Strom, manchmal muss ich den HUE-Dimmschalter holen. Ich denke, dass dies hier https://github.com/dresden-elektronik/deconz-rest-plugin/issues/33 immer noch nicht ganz gelöst ist. Allerdings habe ich es noch nicht gehabt, dass ALLE Lampen und Steckdosen nicht mehr reagieren.

Grüße, Rüdiger
FHEM 6.0 auf raspi3&ODROID XU4 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433, Xiaomi Aqara+div. Zigbee via deCONZ, Dooya via SIGNALDuino, ZWave mit Danalock
Jeder Witz kann ein Einzeiler sein mit genügend Semikolons

MadMax-FHEM

Gut ich muss gestehen: so viel ZigBee hab ich nicht...

Aber ein Ausfall OHNE dass ich was getan habe (siehe "Bastelei" ;) ) hatte ich noch nicht.

Bis auf eben das mit dem Speicher.

Bei mir läuft auf dem PI auch nur deCONZ mit dem RaspBee-Modul.
Und noch was "selbst programmiertes" bzgl. CO2... ;)

Speicher war aber schon eine deutlich ältere Version von deCONZ...

Wenn du die SD-Karte als Problem annimmst, dann ist clonen KEINE gute Idee!

Weil du dann Probleme ja "mit clonst"!!

Besser: einfach ein Backup von deCONZ, neu aufsetzen (Buster) und dann eben deCONZ neu installieren, Backup einspielen und gut.
Zumindest bin ich die letzten Tage so schon einige Male "umgezogen", siehe "Basteln" ;)

Bzgl. Media-Server: keine Ahnung was da möglich ist...

Aber wie geschrieben: clonen ist keine gute Idee! (sollte wirklich die SD einen "Treffer" haben)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

alanblack

Zitat von: MadMax-FHEM am 07 Juni 2020, 10:31:04
Gut ich muss gestehen: so viel ZigBee hab ich nicht...
Was ist (nicht) viel?
Hier sind es 26 Lampen und Steckdosen, 36 Sensoren und 8 Fernbedienungen/Funktaster.

Zitat
Wenn du die SD-Karte als Problem annimmst, dann ist clonen KEINE gute Idee!

Weil du dann Probleme ja "mit clonst"!!

Besser: einfach ein Backup von deCONZ, neu aufsetzen (Buster) und dann eben deCONZ neu installieren, Backup einspielen und gut.
Zumindest bin ich die letzten Tage so schon einige Male "umgezogen", siehe "Basteln" ;)
Da ich mir noch nicht sicher bin, ob ich ein oder zwei mitunter voneinander unabhängige Probleme habe, habe ich den Pi runtergefahren, die SD-Karte schreibgeschützt in einen anderen Rechner gesteckt, mit dessen OS die Karte geklont und prüfe gerade den Klon auf Probleme. Das Kopieren ist ohne Leseprobleme durchgelaufen. Kann also höchstens ein Konsistenzfehler sein. Die Prüfung wird aber noch etwas dauern.

Währenddessen habe ich deconz auf einem anderen Pi installiert, den Conbee umgesteckt und mit dem Restore auf dem Stand von gestern gestartet => Sensoren sind da und funktionieren, Lichter hingegen sind zwar da, funktionieren aber nicht.  :(

Grüße, Rüdiger
FHEM 6.0 auf raspi3&ODROID XU4 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433, Xiaomi Aqara+div. Zigbee via deCONZ, Dooya via SIGNALDuino, ZWave mit Danalock
Jeder Witz kann ein Einzeiler sein mit genügend Semikolons

MadMax-FHEM

#5
Nicht viel heißt: eine HUE Iris und 2 Sensoren ;)

Und dann (eigentlich an einem Testsystem) noch eine Paulmann LED und einen Osram Lightstipe...
...und die "abwechselnd" an einem Tradfri und dem deCONZ (Testsystem)...

Weil ich mal begonnen hatte eine IKEA-FB als "Lichtschalter" umzubauen, da es ja für ZigBee nichts gescheites zum "unter einen Lichtschalter schrauben" gibt.
Und ich meine KEINEN Schaltaktor, sondern "nur" einen Sender mit dem man direkt die Lampen steuern kann...

Daher habe ich auch noch nicht viel ZigBee...


Womit hast du denn geklont!?

Weil wenn z.B. 'dd', dann gibt es klar keinen Fehler, weil einfach Block für Block übertragen wird. Egal was in dem Block steht. Wenn also "Dateisystem-Müll" drin steht, dann wird der einfach mit übertragen.

Daher clone ich NIE. Nicht mal, wenn ich denke, dass das System noch ok ist.
Außer, um schnell ein Testsystem aufzusetzen.
Also ich setze ein neues System auf (wenn z.B. ein neues OS rauskommt) und installiere was ich da so brauche (u.a. fhem) und dann mache ich einen Komplettabzug.
Aber nur damit ich eben schnell wieder auf diesen Stand komme, wenn beim "Rumspielen" was schief ging... ;)

Ansonsten mache ich eine Sicherung mit tar und nur von den "wichtigen" Dingen und auch öfter und hebe die auf.
Da ist die Wahrscheinlichkeit "Müll" mitzukopieren geringer aber dennoch auch hier gegeben.

Aber jeder muss nat. sein Backup-Restore Konzept finden.
Weil er muss es verstehen und wissen wie ein Restore geht und auch wissen was zu tun ist, wenn beim Restore was hängt/schief geht...

Aber es gibt Dinge die gehen meist schief und dazu gehört: dd bei laufendem System und dd (oder vergleichbarer Clone-Mecahnismus) bei einer evtl. "defekten" SD...

Hmm, allerdings eigenartig, dass es teilweise läuft.

Ja, ich weiß, vom Strom nehmen der Lampen usw. hast du schon gemacht...
...aber auch LANGE (also schon mal eine oder auch 2 Min) gewartet bevor du sie wieder an den Strom genommen hast!?

Ich habe das zunächst auch nur kurz gemacht bei meiner "Iris" und dann ging sie auch noch nicht.
Als ich sie dann echt lang vom Strom genommen und wieder dran gesteckt hatte ging es wieder...
(ich war auch schon kurz davor sie zurück zu setzen ;)  )

EDIT: mittlerweile laufen alle wichtigen Systeme (die auf PI sind) auf SSD. Nur Systeme wo ein Neuaufsetzen ohne "Schmerzen" und schnell geht laufen auf SD. Und mein deCONZ gehört zu den SD-Systemen. Weil eben Backup deCONZ einspielen reicht und ein OS flashen und deCONZ installieren ratz fatz geht ;) Daher wird es Zeit, dass der PI4 auch endlich (ohne "Hack") von SSD booten kann :)

EDIT: wobei ich mit einer SD zum Booten und alles weitere von SSD auch leben kann... ;)

Viel Erfolg, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

alanblack

Zitat von: MadMax-FHEM am 07 Juni 2020, 11:59:30
Nicht viel heißt: eine HUE Iris und 2 Sensoren ;)

Und dann (eigentlich an einem Testsystem) noch eine Paulmann LED und einen Osram Lightstipe...
...und die "abwechselnd" an einem Tradfri und dem deCONZ (Testsystem)...
Das ist wirklich nicht viel.

Zitat
Womit hast du denn geklont!?
MiniTool Partition Wizard auf ein virtuelles Laufwerk
Danach habe ich ein zweites virtuelles Laufwerk mit dem letzten Vollbackup und dem Differentialbackup von gestern erstellt. Die beiden Laufwerke habe ich verglichen: außer ein paar Logs waren sie identisch.
=> SD-Karte heile

Zitat
Ja, ich weiß, vom Strom nehmen der Lampen usw. hast du schon gemacht...
...aber auch LANGE (also schon mal eine oder auch 2 Min) gewartet bevor du sie wieder an den Strom genommen hast!?
Aufgrund dieser Frage habe ich auch mal Lampen 60Min+ vom Strom getrennt. Das war aber nicht das Problem.

Inzwischen habe ich noch:
deconz inkl. Firmware aktualisiert
sowohl die "alte" als auch die aktualisierte Version auf zwei Pis getestet
dem ursprünglichen Pi eine GUI gegeben und deconz von headless auf GUI umgestellt

Hier ergaben sich erste neue Erkenntnisse:
Im deconz-Programm konnte ich beobachten, wir der "network-discovery-process" nach dem Neustart langsam das Mesh aufbaute, bis... es sich wieder abbaute. Am Schluss bleiben immer nur so 8-15 Links über. Bei 71 Nodes ist das "etwas zu wenig".
Also: Pi, deconz und das Zigbee-Netz laufen, haben aber seit heute morgen ein Problem. Nur welches?

Der Verdacht auf neue Funkstörungen liegt nahe. Aber hier ist diesbezüglich sehr wenig los; ich habe mal gerade auf einem von vier APs ein fremdes Netz.  ;)

Der neueste Verdacht, den ich hege, ist ein Stromproblem: mir ist zwischenzeitlich aufgefallen, dass den ganzen Tag über die Netzspannung zwischen 210 und 216V liegt. Erlaubt sind zwar offiziell sogar Spannungen von minimal 207V, aber vielleicht haben manche Zigbee-Router schon früher Schwierigkeiten. Da wird es aber schwierig, das zu testen bzw. zu beheben.

Zitat
EDIT: mittlerweile laufen alle wichtigen Systeme (die auf PI sind) auf SSD. Nur Systeme wo ein Neuaufsetzen ohne "Schmerzen" und schnell geht laufen auf SD. Und mein deCONZ gehört zu den SD-Systemen. Weil eben Backup deCONZ einspielen reicht und ein OS flashen und deCONZ installieren ratz fatz geht ;) Daher wird es Zeit, dass der PI4 auch endlich (ohne "Hack") von SSD booten kann :)

EDIT: wobei ich mit einer SD zum Booten und alles weitere von SSD auch leben kann... ;)
Ich habe im Haus inzwischen sieben Kleincomputer laufen. Ich mag nicht wirklich die Vorteile wie geringe Anschaffungskosten, Größe und Stromverbrauch durch den Einsatz von SSDs zunichte machen. Der TV-Server braucht eh viel Speicherplatz und hat daher ein externes Laufwerk - allerdings eine HDD. Der XU4 mit FHEM hat eine SSD. Der Rest läuft nur mit SD. Gesichert werden die sieben alle auf ein NAS und die Backups funktionieren. Da bekommt halt jeder so alle zwei bis vier Jahre eine neue Karte verpasst und gut.

Mal schauen, was ich noch für Hinweise finde.

Schönen Abend an alle!
FHEM 6.0 auf raspi3&ODROID XU4 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433, Xiaomi Aqara+div. Zigbee via deCONZ, Dooya via SIGNALDuino, ZWave mit Danalock
Jeder Witz kann ein Einzeiler sein mit genügend Semikolons

jsChris

Hi,

hast du schon folgendes ausprobiert?

https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Network-lost-issues

Das hat mir bei meinem Umzug vom ConBee auf RaspBee || geholfen, bzw. das war der entscheidende Punkt, um alle ZigBee Devices wieder anzusprechen. Ich habe einfach die letzte Network-Config mal geladen und dann lief alles. Ist natürlich ein anderer Ausgangspunkt und vielleicht hast du auch anderes Problem, aber ein Versuch ist es wahrscheinlich Wert.

lg
Chrtis

alanblack

Hallo Chris,

Zitat von: jsChris am 08 Juni 2020, 09:39:27
Hi,

hast du schon folgendes ausprobiert?

https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Network-lost-issues

Das hat mir bei meinem Umzug vom ConBee auf RaspBee || geholfen, bzw. das war der entscheidende Punkt, um alle ZigBee Devices wieder anzusprechen. Ich habe einfach die letzte Network-Config mal geladen und dann lief alles. Ist natürlich ein anderer Ausgangspunkt und vielleicht hast du auch anderes Problem, aber ein Versuch ist es wahrscheinlich Wert.

lg
Chrtis
Den hatte ich noch nicht gefunden. Liest sich eigentlich nicht so, als ob das irgendetwas mit meinem Problem zu tun hat.
Auf jeden Fall ist das ein "hidden feature" was der eine oder andere deconz-User noch nicht kennt. Ich habe mal die letzte sicher vor dem Beginn des Problems liegende Config geladen. Das war beim letzten Update auf die 2.05.73. Da fehlen dann zwar zwei Devices, aber das wäre ja verschmerzbar.

Was soll ich sagen....?

DANKE! @jsChris

TREFFER!

Das Zigbee-Mesh erholt sich zwar noch und ich renne immer noch ab und zu durch das Haus, um Nodes mal "anzuschubsen", aber ich kann jetzt schon sagen, dass dies die Lösung war. Die Router-Nodes haben schon alle einen Link und die Endpoints fast alle. Die automatischen Schaltvorgänge über FHEM gehen weitgehend schon wieder.

Also: wenn das über deconz gesteuerte Zigbee-Mesh spinnt, erreicht Ihr über einen Alt+linken Mausklick auf "Erweitert" beim Gateway eine Möglichkeit vergangene Mesh-Konfigurationen zu laden. Kann helfen!!!!

Grüße, Rüdiger
FHEM 6.0 auf raspi3&ODROID XU4 mit HMLAN und HM-MOD-RPI-PCB, LaCrosse via JeeLink, COC868 und CUL433, Xiaomi Aqara+div. Zigbee via deCONZ, Dooya via SIGNALDuino, ZWave mit Danalock
Jeder Witz kann ein Einzeiler sein mit genügend Semikolons