Zigbee Gateways Conbee und Raspbee mit deConz und Phoscon in Fhem einbinden

Begonnen von maddinthebrain, 04 Januar 2019, 10:41:24

Vorheriges Thema - Nächstes Thema

P.A.Trick

Zitat von: gvzdus am 13 Januar 2020, 22:15:48

@P.A.Trick: Ich habe vor 6 Wochen 4 Osram Lightify (Smart+) E27-Birnen gekauft - die zicken mit meinem Conbee-Stick überhaupt nicht.

Ja bei mir sind es auch nur zwei, die anderen gehen.
Problematisch sind Flex RGBW Controller mit der Version V1.03.07. Leider gibt es dafür keine Firmware Updates :-/
Cubietruck,RPI,QNAP Ts-419p+, FS20, FRITZ!DECT200, 7 MAX! Thermostate, 3 MAX! Fensterkontakte, Kodi, CUL V3.3, EM1000S, LW12, LD382, HUE, HM-CFG-USB-2, 1x HM-LC-SW1-FM, 2x HM-LC-SW2-FM, 2x HM-LC-Sw1PBU-FM, 3xHM-LC-Bl1PBU-FM,HM-SEC-RHS, 2xHM-SEC-SD,HM-WDS30-T-O, 3x HM-LC-Dim1TPBU-FM, RPI+AddOn

popy

Zitat von: Loredo am 13 Januar 2020, 16:29:31

Ich weiß. Aber genau das ist ja das Problem, dort gibt es dann nur entweder oder, aber nicht beides zusammen.
Bei Phoscon gibt es diese Möglichkeit wohl generell (über die Gruppen, die standardmäßig ja sogar angelegt werden). Hab ich mich aber noch nicht mit beschäftigt. Reicht aber eben auch nur für extrem simple Zusammenhänge wie an/aus, mehr geht dann schon wieder nicht glaub ich. HomeMatic ist zwar schittig zu programmieren, hat aber zumindest wirklich echte Intelligenz in den Aktoren. ZigBee ist meh :-/

Das stimmt nicht ganz.
Habe jetzt begonnen mal ein Zimmer (Abstellkammer, wo es egal ist wenn mal was nicht geht) und ein Ikea Rollo auf deCONZ umzusiedeln.
Also sind jetzt folgende Geräte mal bei deCONZ:


  • HUE Lampe E27 warmweiß
  • HUE Dimmer
  • HUE BM
  • Ikea Rollo

Den Taster kann man schön über HUE Essentials programmiern, inkl. mehrfach Betätigungen, Dimmen usw. auf allen Tasten  (was man von der HUE App gewohnt ist).
Sprich, auch wenn fhem nicht läuft und nur deCONZ am laufen ist, gehen wenigstens die Schalter.
Den BM habe ich jetzt über FHEM gelöst und gefällt mir persönlich besser als über die HUE Apps.
Man ist freier in der Programmierung und nicht auf die App Funktionalitäten beschränkt.
Ansprechzeit ist voll in Ordnung da deCONZ einen Push zu fhem macht.

Da Rollo pairing verlief Problemlos. Das steuere ich nun über 2x Dimmer welche noch auf der HUE Bridge hängen -> durch das polling eine Verzögerung.
Wird sicher besser wenn ich die Schalter mal ins deCONZ Netz bringe.

Soweit meine Erfahrungen mit deCONZ.
Werde sicher in nächster Zeit alles auf deCONZ umsiedeln.

Zitat von: P.A.Trick am 13 Januar 2020, 22:05:48
Ich bin vor einiger Zeit auch auf Phoscon umgestiegen. Gründe dafür waren das polling und auch die günstigen Xiaomo Sensoren. Ich muss aber sagen, dass Phoscon überhaupt nicht mit meinen OSRAM Lightify Lampen klar kam. Daraufhin habe ich die wieder an die originale Philips HUE Bridge gehangen. Ikea läuft super mit Phoscon, besonders da die Lampen automatisch von der deCONZ App aktualisiert werden. Sensoren usw. klappen auch gut. Ich glaube aber, dass ein gemischtes Meshup Netzwerk für alle Systeme eine Herausforderung ist.

Könntest du mir erklären wo du in Phoscon die automatische IKEA Update Möglichkeit findest?
Habe die latest Phoscon/deConz stable 02.05.71.

Danke
pOpY



P.A.Trick

Du kannst dieses Script hier nutzen:

https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/ikea-ota-download.py

Beim Restart von deCONZ sollte dann, sofern das ota Verzeichnis beim User pi erstellt ist und die Firmware Dateien dort liegen auch ein automatisches Update durchgeführt werden.
Alternativ kannst du des mit der deCONZ App manuell updaten.
Cubietruck,RPI,QNAP Ts-419p+, FS20, FRITZ!DECT200, 7 MAX! Thermostate, 3 MAX! Fensterkontakte, Kodi, CUL V3.3, EM1000S, LW12, LD382, HUE, HM-CFG-USB-2, 1x HM-LC-SW1-FM, 2x HM-LC-SW2-FM, 2x HM-LC-Sw1PBU-FM, 3xHM-LC-Bl1PBU-FM,HM-SEC-RHS, 2xHM-SEC-SD,HM-WDS30-T-O, 3x HM-LC-Dim1TPBU-FM, RPI+AddOn

justme1968

noch etwas allgemein zur zuverlässigkeit und autonomie ohne fhem bzw. beim fhem ausfall:

das ist leider nur bedingt richtig und betrachtet nicht das auch die andere hardware (bridge, taster, ...) kaputt gehen können. mein fhem z.b. läuft stabiler als alle anderen komponenten im system. und selbst falls es ausfällt ist es schneller wiederhergestellt oder umgezogen als die vorgelagerten raspberrys oder bridges.

wenn z.b. die hue bridge ausfällt gibt es kein backup der dort hinterlegten regeln die sich auf einer neuen bridge einspielen lassen, die neue bridge kann nicht einfach die stelle der alten übernehmen weil sie ohne umzug bei laufender alten bridge ein komplett neues netz auf macht in das alle geräte angelernt werden müssen. danach wären die alten regeln vermutlich sowieso nicht mehr zu gebrauchen.

gleiches mit hm: die direkten verknüpfungen sind nirgendwo gesichert und lassen sich nicht einfach wider einspielen. auch hier ändern sich ids der aktoren beim tausch.

die programmierung in fhem kann ich hingegen einfach umziehen und sie läuft einfach weiter. mit den letzen hue änderungen sogar wenn ein device auf einer neuen bridge angelernt wird.


hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Loredo

Zitat von: popy am 19 Januar 2020, 15:28:18
Sprich, auch wenn fhem nicht läuft und nur deCONZ am laufen ist, gehen wenigstens die Schalter.

Was passiert, wenn deCONZ nicht läuft, lassen sich dann die Leuchten als Fallback noch immer über den Schalter bedienen?
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

popy

Zitat von: Loredo am 19 Januar 2020, 15:42:27
Was passiert, wenn deCONZ nicht läuft, lassen sich dann die Leuchten als Fallback noch immer über den Schalter bedienen?

Nein, da die Kommunikation ja über deconz geht.

Beta-User

Zu dem
Zitat von: Loredo am 19 Januar 2020, 15:42:27
Was passiert, wenn deCONZ nicht läuft, lassen sich dann die Leuchten als Fallback noch immer über den Schalter bedienen?
Zitat von: popy am 19 Januar 2020, 22:17:48
Nein, da die Kommunikation ja über deconz geht.
Diese Aussage würde ich etwas in Zweifel ziehen. ZigBee ist in der Hinsicht undurchsichtig:

Es gibt durchaus Methoden/Geräte, die eine direkte, von irgendeiner Bridge nicht (mehr) gesteuerte direkte Kommunikation direkt zwischen einzelnen Teilnehmern des ZigBee-Netzwerks zu kennen scheinen, ausgetestet hatte ich das z.B. mal mit einem "eckigen" on/off-Tradfri an einer Tradfri-Birne (und evtl. auch mit der "großen Runden" iVm. zwei tint). Nicht geklappt hat das mit einem Jung/insta-Taster (ZLL5005), aber der hat sowieso irgend ein Problem mit der firmware, update ist angkündigt.
Allerdings habe ich noch keine Idee, wie man "direkte" und "indirekte" Kommunikation (indirekt=über die Bridge (hier deCONZ)) unterscheiden kann, vermutlich muß man messages sniffen, oder eben testen, indem man die Bridge ausschaltet...

Zitat von: justme1968 am 19 Januar 2020, 15:39:24
gleiches mit hm: die direkten verknüpfungen sind nirgendwo gesichert und lassen sich nicht einfach wider einspielen. sich hier ändern sich ids der aktoren beim tausch.
Das ist mAn. etwas "unscharf". Soweit wir über den Ausfall der Bridge sprechen, bleiben die Peerings erhalten, und man kann die (jedenfalls mit CUL_HM) auch später wieder auslesen (mit hminfo).
Was die Aktoren usw. angeht, kann man (wieder @CUL_HM) auch die Registerwerte sichern, und die dann hinterher wieder auf einem anderen, baugleichen Gerät wieder herstellen, wenn ich das richtig im Kopf habe; in jedem Fall zeigt einem hminfo an, wenn es "ins Leere gehende" direkte Verknüpfungen gibt, man hat also einen Ansatz zur Reparatur, selbst wenn man die Register nicht gesichert hatte...

(Bei ZWave scheint es eine "replace"-Funktion zu geben, aber mit der habe ich mich bisher nicht intensiv beschäftigt).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

volschin

Die HueBridge ist tatsächlich ein negatives Beispiel bzgl. der Wiederherstellbarkeit. Bei Phoscon kann man die Daten des Netzwerks sichern und wieder einspielen.

Bei Hue gab es ja die ersten Lampen und Steckdosen mit einer Remote. Das war jeweils ein eigenes Zigbee-Netz. Das erste konnte man an der Bridge anlernen, dann funktionierte das ganze auch mit Fernbedienung weiter.
Meine neuen Hühner-Dimmer funktionieren nicht, wenn die Bridge offline ist (gerade letztens festgestellt, als sich die HueBridge beim Update aufhängte).
Intel NUC+Ubuntu 22.04+Docker+FHEM6
HomeMatic: HM-MOD-RPI-PCB+HM-USB-CFG2+hmland+diverse, HUE: Hue-Bridge, RaspBee+deCONZ+diverse
Amzn Dash-Buttons, Siro Rollos
4xRPi, 4xCO20, OWL+USB, HarmonyHub, FRITZ!Box 7590, Echo Dots+Show8, Logi Circle 2, HomeBridge
TIG Stack (Telegraf, InfluxDB, Grafana)

Thyraz

@volschin hast du das bei Phoscon schonmal mit einem neuen Gateway getestet?
Funktioniert das dann ohne erneutes Anlernen der Geräte, oder nur wenn man wieder die selbe Hardware (also z.B. der selbe Conbee 2 Stick) verwendet?

Falls das geht, werde ich mir einen zweiten Connbee 2 in den Keller legen, wie ich das auch schon beim ZWave Stick gemacht habe.

Weil Zwave weiter oben auch erähnt wurde:
Hier geht Backup/Restore der ganzen Gerätetopologie sogar super bequem innerhalb von FHEM.
das ZWave Modul hat bei mir den Umstieg vom Zwave.me Raspberry Mopul zum Zwave.me USB Stick im NUC gemacht, ohne etwas neu anlernen oder konfigurieren zu müssen.

Zur Ausfallsicherheit FHEM:
Angeregt durch den Thread werde ich mal versuchen auf meinem Macbook Pro eine VM mit Proxmox als Guest zu installieren.
Dort dann das letzte Proxmox Backup vom FHEM Container und das aktuelle Backup von FHEM selbst einspielen.

Also das, was ich auch beim Hardwareausfall des NUCs machen müsste.
(Backup Container mach ich nach jedem Update von Ubuntu oder nach dem Installieren neuer Pakete, Update FHEM passiert täglich, beides aufs NAS, welches sich einmal täglich wiederum auf eine OffSite Location sichert.)

Dann mal die zwei einzigen Gateways am Macbook der VM durchreichen die aktuell direkt am NUC angeschlossen sind und nicht per Netzwerk angesprochen werden: Conbee und Zwave.
Mal sehen ob ich die dann auch problemlos gehen.

Wenn ja, hätte ich damit einen Plan B um FHEM in < 1h wieder lauffähig zu bekommen, ohne im Falle eines Defekt überhastet einen neuen Minirechner kaufen zu müssen.
Fhem und MariaDB auf NUC6i5SYH in Proxmox Container (Ubuntu)
Zwave, Conbee II, Hue, Harmony, Solo4k, LaMetric, Echo, Sonos, Roborock S5, Nuki, Prusa Mini, Doorbird, ...

Beta-User

@Thyraz:
Nach meinen ersten Erfahrungen mit dem Thema ist es so, dass der ConBee II das ZigBee-Netzwerk irgendwo intern (EEPROM?) abspeichert, jedenfalls kann man denselben Stick samt sämtlicher Geräte an unterschiedlichen Rechnern mit je eigenem deCONZ betreiben, ohne was neu anlernen zu müssen. Das klingt danach, als wäre die backup-Funktion vor allem auch dazu da, neuen IO's diese Infos mitteilen zu können (vermutlich sogar Typ-unabhängig, also von Pi-Modul auf ConBee II sollte auch gehen...).

Nachtrag: Steht auch ausdrücklich so in der Doku...
Zitat
The backup includes deCONZ and Phoscon App specific data for groups, lights, scenes, ZigBee network settings and other data like deCONZ GUI node positions and names.
Two scenarios:

       
  • Move ConBee / RaspBee to a new gateway / Raspberry Pi
  • Move network to a new controller (e.g. in case ConBee breaks and needs to be replaced)

Zitat von: P.A.Trick am 19 Januar 2020, 15:32:06
Du kannst dieses Script hier nutzen:

https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/ikea-ota-download.py

Beim Restart von deCONZ sollte dann, sofern das ota Verzeichnis beim User pi erstellt ist und die Firmware Dateien dort liegen auch ein automatisches Update durchgeführt werden.
Alternativ kannst du des mit der deCONZ App manuell updaten.

Danke für den Hinweis, das teste ich bei nächster Gelegenheit mal; auf der phoscon-Oberfläche ist es ein ziemlicher Mist, einzelnen Geräten eine OTA-file zuzuweisen, das ist komplett unübersichtlich/kryptisch, und man muß eine GUI haben...
Wenn es so einfach geht, wäre das klasse!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

popy

Zitat von: P.A.Trick am 19 Januar 2020, 15:32:06
Du kannst dieses Script hier nutzen:

https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/ikea-ota-download.py

Beim Restart von deCONZ sollte dann, sofern das ota Verzeichnis beim User pi erstellt ist und die Firmware Dateien dort liegen auch ein automatisches Update durchgeführt werden.
Alternativ kannst du des mit der deCONZ App manuell updaten.

Danke, werde ich testen.

NoPlan12

Hallo, ich habe eine Frage zu den Xiaomi-Würfel. Ich habe bisher über den Raspbee (ConbeeII) mehrere Xiaomi Bewegungsmelder in Fhem eingebunden. Das ging alles prima und ohne Probleme. Vor Allem weil ich mit  dem "set attrTemplate"  den Sensor direkt auswählen konnte. So waren die dann in Fhem gut eingebunden und ich konnte sie verwenden. Den Würfel habe ich dort leider nicht gefunden. Prinzipiell wurde der Würfel auch ohne diesen Punkt eingebunden. Ich hatte aber gehofft, daß ich die unterschiedlichen Bewegungen (Flip, Rotation und so weiter) besser aufgeschlüsselt bekomme um dann bestimmte Befehle zu zu ordnen. Im Reading bekomme ich unter "state" verschiedene Zahlen als Ergebnis der Bewegung. Das aber dann auszuwerten  wäre sicher ziemlich aufwending. Ich hatte gehofft, daß das einfacher geht. 
Ich hoffe, ihr könnt mir da weiter helfen.

Gruß

justme1968

such mal hier im forum. da gibt es einen post mit einem user reading das genau das macht.

hab auch die schnelle den hier gefunden: https://forum.fhem.de/index.php/topic,92089.msg846021.html#msg846021. gibt glaube ich noch mehr.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968


popy

Danke für eure Einschätzungen bzgl. Zuverlässigkeit und Backup.
Habe jetzt folgendes per cron eingerichtet:


  • fhem, ha-bridge & deconz Backup jeden Sonntag auf SMB Share vom Windows Server
  • rpi live backup jedes Monat auf SMB Share vom Windows Server

Mal ne frage bzgl. conbee II.
Falls der Conbee II defekt werden würde kann ich mein Backup auf einen anderen wiederherstellen und funktioniert dann alles (bzgl. pairing und zigbee mac)?

Danke