NEWS
Zigbee Adapter und Conbee Unterstützung
-
@helfi9999
Ja, Stick einstecken, fertig. -
@helfi9999 Heyy. Ja, kann ich bestätigen: Stick rein und läuft, wenn Du den ConnBee 2 vorher nicht mit DeConz genutzt hast. Falls doch, dann musst Du vorher alle angelernten Geräte in der DeConz Web-UI löschen.
-
@arteck Ich hatte den ConBee 2 auch schon mit ioBroker in einem Container laufen. Musste nur das Device durchreichen. Klappt bei VMware und Microsoft Hyper-V vergleichbar, nur eben spezifisch im Sinne des Hypervisors anders. Zu Proxmox und KVM, etc. kann ich nichts sagen.
-
Da habe ich hier ja mal genau den richtigen Thread gefunden
Bin gerade in der Umstellung von Pimatic/deCONZ/ConBee II nach ioBroker/...?.../ConBee II.
Aktuell läuft tatsächlich alles zusammen, sehr stabil, auf einem einzigen Raspi4B.
Meine bisher weiche Migration lief so, dass ich in ioBroker mit dem deCONZ-Adapter sukzessive, über Wochen, nach und nach alle Devices (>60) mit dem zugehörigen Regelwerk (mehre Dutzend), alles von Pimatic nach ioB/Blockly herüber geholt habe.
Der letzte Schritt werden dann jetzt die ganzen EG-Shutter, welche gleichzeitig von 433Mhz nach ZigBee migrieren werden.
Da der ZigBee Adapter so eine schöne Admin Oberfläche, im Vgl. zu Phoscon/deCONZ-GUI mitbringt, hatte ich nun überlegt, auch diesen Schritt noch zu machen.
Ich verstehe aber, dass ich dann alles neu anlernen muss (vielleicht noch machbar), aber ich danach wahrscheinlich auch noch wieder das gesamte Regelwerk anfassen müsste, oder? - weil ich gehe mal davon aus, dass die ganzen Devices sicherlich neue Namen bekommen werden, oder? -
@pedder007 Heyy. Aus eigener Erfahrung kann ich Dir sagen, dass Du alle Zigbee Devices neu anlernen musst; das geht relativ schnell. Vergiss bitte nur nicht, die Bindung der Geräte vorher in deConz / Phoscon aufzuheben. Allerdings haben auch die einzelnen Datenpunkte abweichende Namen bzw. dann auch IDs. Du wirst also ggf. auch praktisch alle beteiligten Skripte, etc. anpassen müssen.
Wenn Du mich fragen würdest, ob sich das für mich gelohnt hat: Ja, das hat es. Zigbee läuft nun deutlich stabiler, da der ioBroker nicht noch auf eine deConz API zugreifen muss. Ich würde es wieder tun. -
@migoller
Danke für Dein Feedback, dass habe ich so befürchtet, püüh...
Na mal sehen, dass wird dann ja nochmal ein größerer Schritt, zumal ich befürchte, dass ich dann so einige Devices, die ja überall verteilt sind, manuell in den Anlermodus werde versetzen müssen...
Wie gesagt, bisher läufts bei mir auch mit deCONZ sehr stabil, und das, obwohl ich noch Pimatic-, als auch ioBroker-seitig gleichzeitig auf dieselbe deCONZ Instanz zugreife. -
@migoller lassen sich der ZigBee Adapter und der deCONZ Adapter eigentlich ohne bekannte Probleme parallel betreiben? - am selben ConBee II Stick?
Weil dann könnte man die ganze Migration ja sehr weich organisieren ... -
@Pedder007
Nicht gleichzeitig. -
@thomas-braun
ok danke, hatte ich mir fast schon gedacht -
@pedder007 sagte in Zigbee Adapter und Conbee Unterstützung:
@thomas-braun
ok danke, hatte ich mir fast schon gedachtLese mal die ersten Beiträge ... bis Beitrag 27
-
@glasfaser said in Zigbee Adapter und Conbee Unterstützung:
Lese mal die ersten Beiträge ... bis Beitrag 27
quer-gelesen hatte ich schon von wegen Vor- und Nachteile und so ...
Aber das muss mir durchgegangen sein ...Ich denke ich werde aber erst einmal bei der deCONZ Lösung bleiben, weil auf die 6-7 Shutter-Devices kommt es jetzt bei einer späteren Migration dann auch nicht mehr an. Da liegt bei mir die Prio aktuell zunächst einmal darauf insgesamt von 433Mhz weg zu kommen und die Pimatic (mit Arduino-RF) außer Betrieb zu nehmen ...
Ich befürchte der Wechsel von deCONZ zu ZigBee wird dann sowieso ein größerer Aufwand, da manche Devices ja noch nicht einmal freiwillig nach einem Batteriewechsel zurück ins Mesh kommen - hatte ich letztens erst wieder bei einem Osram/Ledvance Bewegungsmelder ...
-
@pedder007 Es ist zumindest keine Migration für mal eben zwischendurch. Aufwand wird es geben. Dass die Devices aber nach Batterietausch nicht wieder ins Mesh kommen... seltsam. In einem Forum zu der Zigbee-Bibliothek für JavaScript bzw. Node.js habe ich auch zu den Osram bzw. Ledvance Geräten von diversen Problemen gelesen. Gerade bei den Steckdosen gibt es wohl ein Routing-Thema, dass z.B. Tür- bzw. Fensterkontakte nicht immer zuverlässig funktionieren. Habe auch so eine Steckdose gegen eine Ikea Smart-Bulb getauscht... und keine Probleme mehr mit den Fensterkontakten.
-
@migoller wahrscheinlich gibt es da 1000sende individuelle Erfahrungswerte, bei den ganzen Herstellern ...
Die Osram-Plugs laufen bei mir wiederum recht zuverlässig als Router, bzw. die Meldungen der ganzen China-Tür-/Fenstersensoren kommen quasi ohne Verzögerung rein.
Tradfri läuft hier aber auch zuverlässigDas mit der deCONZ -> ZigBee Migration werde ich wohl noch ein Weilchen vor mir herschieben. Das Regelwerk ist hier mittlerweile (für mein Begriffe) recht gewaltig, da die Geräte oft von mehreren Stellen gesteuert werden (VIS: Tablet/Smartphone, Buttons, Wandschalter, Blockly, ...) Wenn ich da überall die Device-Namen neu eintragen muss, dann wird das heftig bei nun >70 Gerätchen Ist halt alles nun über >2 Jahre gewachsen ...
Als Nächstes werde ich mich wahrscheinlich zunächst mal damit befassen die ganze vorhandene Installation einmal komplett neu aufzusetzen, da ich nur so (denke ich) wirklich sauber von meiner Mix-Installation mit ioBroker und Pimatic (inkl. RF-Arduino) auf einem Raspi wegkomme (würde ich so heute auch nicht mehr machen ...)
Ich habe schon überlegt ob ich das nicht lieber über eine parallele neue ioBroker Installation (auf einem extra Raspi) mache, um das auch wieder Schrittweise durchführen zu können. Dieses, da ich 1. immer mal wieder von Häkchen und Ösen bei der Benutzung des ioBroker Backups gelesen hatte (habe mich da ehrlicherweise aber auch noch nicht so richtig eingelesen) und 2. da das ohnehin nicht an einem Abend zu machen sein wird.
Mal sehen, alles nicht so ganz trivial als non-Developer und mit nur rudimentären Linux-Kenntnissen
-
@migoller
Ich habe bzgl. Neuinstallation mal ein wenig 'herum-gelesen'.Das scheint der Weg der Wahl zu werden:
- BackUp mit BackitUp auf aktueller Installation durchführen.
- Neuen Raspi mit ioBroker und nur Admin- und BackitUp-Adapter installieren
- Dem dann noch die Dresden-Elektronik Phoscon/deCONZ-Installation, nebst Device-Restore via Phoscon, gönnen.
- ConBee Stick u. Broadlink rüberziehen
- Restore von BackitUp auf dem neuen Raspi durchführen.
- Sonstige Grafiken und Bilddateien (vor allem für VIS) nachziehen
Kann das so klappen?
Alternative hatte ich auch darüber nachgedacht, den neuen als Raspi als ioBroker-Master aufzusetzen und ihm direkt einen eigenen ConBee Stick (ist vorhanden) via ZigBee-Adapter zu gönnen.
Dann den bisherigen Raspi als ioBroker-Slave da dran hängen und dann sukzessive alles herüber zu ziehen (inkl. Schritt für Schritt auch aller anderen Adapter). Dann könnte ich parallel auch die Devices Schritt für Schritt (mit jeweiligem Regelwerk) umlernen/umziehen und das Ganze im Zweifelsfall auch über Wochen sehr weich migrieren.
Müsste doch auch gehen, oder? -
@MiGoller @Glasfaser
sorry wenn ich hier nochmals nervig nachfrage
Ich habe gerade versucht Backitup zu installieren, was aber abgebrochen wird, mit dem Hinweis im Log:iobroker npm ERR! notsup Unsupported engine for fs-extra@10.0.0: wanted: {"node":">=12"} (current: {"node":"10.23.3","npm":"6.14.11"})npm ERR! notsup Not compatible with your version of node/npm
Ok, der Rückstand bzgl. meiner Node Version war ja unter anderem auch ein Grund mich von Pimatic zu trennen, was auch schon fast geschafft ist
Was mich aber nochmals interessieren würde: Wäre mein skizzierter Weg über einen neue ioBroker Master Installation, mit meinem aktuellen Setup als Slave, aus Eurer Sicht sinnvoll, um auf dem Weg dann auch gleich 'weich' mein ZigBee Setup auszutauschen? - ich würde dann halt eine Weile mit 2 Sticks leben ....
-
@pedder007
Und warum ziehst du nodeJS nicht einfach hoch? -
@thomas-braun hallo und danke für Deine Rückmeldung.
Meinst Du das so?
- Pimatic außer Betrieb nehmen
- Node updaten
- Backitup durchführen
- dann mit einer Neuinstallation und dem Backup starten
Ich würde mir dann vorher nur nochmal einen kompletten SD-Card Clone ziehen.
Dann würde ich auf der Neuinstallation aber eben auch auf zwei ConBee Sticks setzen, wobei der eine dann erstmal weiter über deCONZ funkt und der neue dann mit ZigBee in Betrieb genommen werden würde, ... für dann eine weiche Migration ...
-
-
@glasfaser danke für Deine Rückmeldung.
So war das ja auch gemeint. Ich kenne seine Signatur und -wie gesagt- ich hatte mich mit ihm ja auch schon einmal bzgl. node update ausgetauscht, also diesbzgl. grundsätzlich alles gut
Ich wollte 1. nur sicher gehen, dass er das so gemeint hatte (die Antwort war halt seht kurz) und
2. nochmals in Erfahrung bringen, ob ich den skizzierten Weg bzgl. der zwei ConBee Sticks so einschlagen kann, oder ob generell die beiden Adapter (ConBee u. ZigBee) gar nicht auf einer ioBroker Instanz laufen würden? Weil wenn letzteres der Fall ist, müsste ich es wohl eher über das weiter oben skizierte Master / Slave Setup versuchen ...Ich würde gerne vermeiden in eine Sackgasse zu laufen.
-
Mir ist das tägliche Backup über den Backitup-Adapter update genug, ich mache keine Clones der gesamten SD-Karte.
Node-Update wie beschrieben.
Zwei Zigbee-Instanzen kann man technisch schon laufen lassen. Da aber die Clients ohnehin neuangelernt werden müssen würde ich da vermutlich einen harten Cut machen und auf einen Schlag alles umziehen. Aber ich habe auch nicht soooo wahnsinnig viele Geräte. So knapp unter 50, glaube ich.