plötzliche Probleme mit Zigbee CC2531 USB Stick
-
also wenn ich unter iobroker unter den logs gehe, sehe ich bei zigbee nur so was wie:
zigbee.0 2021-07-22 15:45:38.963 debug (998) Non-pingable device 0x001788010647d97c SML002 was last seen '7.011' seconds ago.aber es kann ja nciht sein, dass nach und nach alle Adapter die Verbindung verlieren...
-
könnte ich den Zigbee Stick eigentlich auch durch einen ConBee tauschen, und den COM-Anschlussnamen "einfach" im Zigbee Adapter dann tauschen oder kann das so nicht funktionieren ? Wahrscheinlich nicht so unproblematisch, oder ? Sonst würde ich das glaube ich gerne mal testen wollen...
-
Dann muss neu angelernt werden.
-
@thomas-braun
Und die Objekte wären dann auch neu ?
Ich frag, weil ich überlege, den Slave mit Zigbee auf einer VM auf Proxmox zu installieren, da dort usb durchgereicht werden kann - und ich im Fehlerfall leicht zurückrollen kann. Wenn die Objekte dann eh neu wären, würde ich das wohl gleich auf einer neuen Slave-Installation testen. -
Das weiß ich nicht. Hab ich noch nie gemacht.
-
@kamikazemimmi sagte in plötzliche Probleme mit Zigbee CC2531 USB Stick:
Und die Objekte wären dann auch neu ?
Nein. Solange du den Zigbee Adapter nutzt werden die Objekte und States basierend auf der Hardware-ID des Gerätes angelegt. Diese ändert sich nicht.
A.
-
@asgothian
Alles klar, danke. Conbee Stick kam an - und ich wollte es jetzt ja gerne auf einer VM (nicht auf dem Pi) installieren.
hab daher einen neuen Slave eingebunden, usb durchreichen klappte bei Proxmox.
Teste gerade das erste Anlernen (wobei ich gleich noch mal recherchieren wollte, ob ich vielleicht noch Einstellungen ändern sollte).
Da ich ja eine neue Instanz jetzt habe, werden die Objekte ja unter zigbee.1 (alte ist zigbee.0) angelegt - ist ja auch logisch. Haben aber ja in der Tat, die gleiche ObjektID.Denke mal irgendwo die beiden Instanznamen tauschen, kann ich wohl nicht, oder ?! Dann würde ja die Scripte und Einstellungen in Vis gleich richtig sein;-)
Muss gestehen löschen wollte ich die alte Instanz nicht unbedingt - finde es gerade ncoh nett, anhand der ObjektID den Namen des Geräts (also wie wir es benannt haben) zu erkennen.Und andere Frage, falls das jemand weiß: sind die Scripte von blockly unter /opt/iobroker/iobroker-data/objects.json ? Ich habe es mal mit dem vi geöffnet, aber da scheinen mir manche Zeichen nicht anzeigt zu werden. Ich dachte, ich könnte zigbee.0. durch zigbee.1. ersetzen und dann müssten die Scripte ja laufen. "Trau" mich das da gerade nur nicht;-)
Vielleicht noch mal der Vollständigkeit halber: also ich habe die VM jetzt auf Proxmox mit ZFS laufen. Wenn mir noch mal die Verbindung der Geräte verloren gehen, würde ich die Maschine gerne von einem vorherigen Zeitpuntk wieder starten. Erst mal, um zu gucken, ob es damit dann auch klappt udn so vielleicht den Fehler zu entdecken (sofern der Fehler dann mit Conbee auch auftritt).
Danke und Gruß
Melanie -
@kamikazemimmi sagte in plötzliche Probleme mit Zigbee CC2531 USB Stick:
Da ich ja eine neue Instanz jetzt habe, werden die Objekte ja unter zigbee.1 (alte ist zigbee.0) angelegt - ist ja auch logisch. Haben aber ja in der Tat, die gleiche ObjektID.
Was du tun kannst:
- In beiden Zigbee Instanzen die Konfigurationsoberfläche öffnen, und alle Werte sichern (Screenshot)
- Beide Zigbee Instanzen anhalten
- Den Inhalt der Verzeichnisse /opt/iobroker/iobroker-data/zigbee_0 und /opt/iobroker/iobroker-data/zigbee_1 gegeneinander austauschen
- die Einstellungen der beiden Instanzen tauschen (Die von 0 bei 1 eintragen und umgekehrt
- danach erst beide Instanzen wieder starten.
A.
-
@asgothian said in plötzliche Probleme mit Zigbee CC2531 USB Stick:
@kamikazemimmi sagte in plötzliche Probleme mit Zigbee CC2531 USB Stick:
Da ich ja eine neue Instanz jetzt habe, werden die Objekte ja unter zigbee.1 (alte ist zigbee.0) angelegt - ist ja auch logisch. Haben aber ja in der Tat, die gleiche ObjektID.
Was du tun kannst:
- In beiden Zigbee Instanzen die Konfigurationsoberfläche öffnen, und alle Werte sichern (Screenshot)
- Beide Zigbee Instanzen anhalten
- Den Inhalt der Verzeichnisse /opt/iobroker/iobroker-data/zigbee_0 und /opt/iobroker/iobroker-data/zigbee_1 gegeneinander austauschen
- die Einstellungen der beiden Instanzen tauschen (Die von 0 bei 1 eintragen und umgekehrt
- danach erst beide Instanzen wieder starten.
A.
Jo - das hat gut funktioniert, danke !!! Ich hab zwar nicht den alten Ordner immer umbenannt und dann den anderen Ordner dahin kopiert (bin einfach oft zu feige zum löschen...) - aber war ja selbe Ergebnis. In meinem Fall hab ich dann aber bevor ich die Instanzen wieder gestartet hab, auch noch den "Server" geändert. Beide Instanzen laufen bei mir ja jeweils auf einem anderen Slave.
Aber jetzt sind auch schon alle Geräte wieder gepairt und Skripte laufen.
Dann bin cih jetzt ja mal gespannt, ob der Fehler wieder passiert.Wenn Interesse besteht, könnte ich ansonsten auch noch eine VM mit dem alten Zigbee machen - um zu gucken, ob der Fehler da auch wieder auftritt.
Was ich mich ansonsten noch gefragt hab: der ursprüngliche Slave läuft ja auf einem pi - ob die SD Karte vielleicht kaputt ist ? Und, wenn er vielelicht nicht zurückschreiben kann, dass dann Geräte verloren gehen ?!
LG
Melanie -
also bisher läuft die Konstellation recht stabil. In der Übersicht werden manche Geräte zwar mit durchgestrichenem WLAN Symbol angezeigt, allerdings stehen sie bei Objekte auf verbunden und sie reagieren auch.
Was uns heute aber erst auffiel: der Bewebungsmelder von Phillips Hue wird zwar als Verbunden angezeigt, aber er zeigt keine weiteren Werte an. Wenn wir den auch neu pairen sehe bei den unterschiedlichen Werten dann immer Einträge wie:
2021-08-02 13:23:59.750 - ^[[33mwarn^[[39m: zigbee.0 (8575) Failed to read state '"occupancy_timeout"'of '0x001788010647d97c' after query with '{}'Also scheint der die ja nicht richtig lesen zu können... Wir haben Zigbee Adapter in der Version 1.5.6 installiert. Ist da was bekannt, dass das Gerät mit der Version vielleicht nicht mehr so funzt ?!
Danke und Gruß
Melanie
