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

[justme1968]

auch wenn das nicht die ausgabe war nach der ich gefragt hatte und screenshots sehr unhandlich sind. ja. es sind die leerzeichen. morgen sollte es auch damit gehen.

[popy]

auch wenn das nicht die ausgabe war nach der ich gefragt hatte und screenshots sehr unhandlich sind. ja. es sind die leerzeichen. morgen sollte es auch damit gehen.

Sorry, schon ein langer Tag 
Jetzt die Ausgabe mit "set deCONZ_HUEGroup3 ?":

Code Auswählen Erweitern


Unknown argument ?, choose one of off on toggle statusRequest pct bri rgb color ct hue sat xy dimUp dimDown ctUp ctDown hueUp hueDown satUp satDown alert effect lights rename savescene deletescene scene off-till on-for-timer on-till-overnight intervals off-till-overnight off-for-timer on-till blink attrTemplate

Nach dem SVN Update, was muss ich machen damit sich die Szenen/Einträge bereinigen/aktualisieren -> oder geht das automatisch?

Danke Vielmals
pOpY

[popy]

Könntest du mir bitte die geändert 31_HUEDevice.pm hier hochladen zum testen?

Danke

[popy]

@justme1968: Mit der heutigen Version funktionieren nun auch Szenen mit Leerzeichen.

Danke Vielmals
pOpY

[Loredo]

Hab auch seit einiger Zeit ein Phoscon Gateway testweise laufen gehabt. Allerdings hat es bei mir die Hue Bridge nicht ersetzen können, da ich Szenen, Timer, und vor allem die flexiblen Regeln bei den Bewegungsmeldern aus iConnectHue nicht zuverlässig anwenden konnte (ließ sich über diyHue vorschalten zwar konfigurieren, aber diyHue hat die Regeln nicht richtig abgearbeitet). Ist für mich wichtig, da ich die Grundfunktionen gerne direkt in der Bridge abhandeln möchte (Redunanz und so). Phoscon läuft deshalb auch absichtlich nicht auf meinem Intel NUC, sondern brav auf einem RPi (mit dedizierter Homebridge Instanz, halt das neue Phoscon Image).


Letztlich habe ich es aber bei der Hue Bridge belassen:


- Firmware Updates der Hue Hardware
- mit geht es nicht darum weniger Geld auszugeben, die Hue Hardware ist IMHO noch immer das beste
- das Hue Ökosystem möchte ich lieber vollständig nutzen können
- mir fehlt eigentlich nur die Push API für eine schnelle Reaktion der Bewegungsmelder. 1sek Polling hat dafür nicht befriedigend geklappt
- 2 Ikea Tradfri Leuchten werden nur so meh angesprochen (Steuerung mehrerer Attribute gleichzeitig funzt nicht) - mein ursprünglicher Hauptgrund eigentlich auf Phoscon zu wechseln. Diese auf einer anderen Bridge als die restlichen Leuchten zu haben ist aber nicht praktikabel. _Noch_ bin ich nicht soweit das Tradfri 90x60 Panel gegen das >2x so teure von Hue auszutauschen... viel schlimmer sind die Treiber für die Küchenschrankbeleuchtung. Hue hat da keinen Ersatz für, die Stripes sind alle viel viel viel zu dunkel ...


Für die Steuerung über Bewegungsmelder habe ich jetzt also welche von Ikea gekauft und nur diese über das Phoscon Gateway laufen. Dank der Websocket Anbindung ist die Reaktion hier endlich wie erhofft und die Sonos Follow-Me Automation ist endlich hinreichend okay. Doof, dass ich nun in jedem Raum 2 Bewegungsmelder habe, aber so habe ich das wenigstens mal einigermaßen gelöst.




------




Meine Frage ist nun aber: Warum genau nutzt man ansonsten noch ein Phoscon Gateway? Jaja die billigen Sensoren von Aqara, liegen hier auch schon. Ich meine aber: Wenn man ansonsten eh auf Philips Hue setzt und einen das Geld egal ist, was bleibt dann noch? Andere/hellere Stripes und Treiber? Kann ich ja teilweise auch an der Hue Bridge betreiben (wenn die Firmware nicht so mistig wäre wie die bei Ikea...).


Ich bin jedenfalls von der anfänglichen Euphorie, die ich da vor einem Jahr mal hatte, etwas auf den Boden der Tatsachen zurückgekommen.

[popy]

@Loredo: Danke für deine Einschätzung bzgl. Conbee II + DeCONZ + Phoscon.
Bei mir ist alles derzeit noch auf der HUE bridge und ich experimentiere mit dem deCONZ.
Bin mir auch noch nicht sicher ob ich alles migriere.

Das mit der Ausfalls Sicherheit ist auch noch ein Punkt der offen ist bei mir.
Jetzt ist die Bridge halt ein eigenständiges "System" und ich kann auf meinem RPI mit FHEM machen was ich will, die Lampen funktionieren.

Im Prinzip bin ich VOLL zufrieden mit der Stabilität und Funktionalität der HUE bridge + HUE Essentials + all4hue ...
Das anlernen und programmieren von Standard Sachen wie Lampe, Dimmer & BM sind so einfach!
Ja da fängt's schon an bei deCONZ, zwar irgendwie eine HUE bridge aber dann doch nicht kompatibel 
Habe einige Zeit damit verbracht eine Lösung für das BM + deCONZ Problem zu finden, aber keine Zeitsparende gefunden.
Ich müsste alle Regeln in deCONZ per Hand einpflegen (all4hue kann man die wenigstens editieren ohne sich mit der REST API auseinander zu setzen).
Da ist mir die Zeit irgendwie zu Schade...

Oder kennst du eine GUI-Lösung (ähnlich den Android/iOS Apps) um die Regeln für den BM zu erstellen ohne viel Zeit investieren zu müssen?

Meine Intentionen alles zu deCONZ zu migrieren sind/waren folgende Punkte:

• Resourcen Limit: die HUE bridge ist voll bei mir! Ja ich könnte mehrere nehmen, aber dann ziehe ich ja auch 2 ZigBee Netze auf, was Kontra produktiv ist.
• Fehlende Push API: und das seit Jahr(zehnt)en
• Fehlende Einbindung anderer HW: Aqara, Ikea usw.

Habe jetzt ein Ikea Rollo bekommen und auch schon einen Tradfri Hub liegen, bin die ganze Zeit am überlegen wie ich es machen soll...deCONZ...Tradfri HUB + 2te Bridge...

Hast du das Problem das die HUE Bridge voll ist?
Wie hast du das gelöst?

Du sagtest du hast die IKEA Bewegungsmelder über deCONZ (Phoscon) laufen, da brauchst du ja auch Repeater (Lampen) oder ähnliches damit das Mesh gut funktioniert, oder?
Hast du da noch ein paar Lampen platziert?

Meine Euphorie an deCONZ (Phoscon) schwindet leider auch schön langsam.
@PHILIPS: Wo ist eine HUE Pro Bridge ohne Speicher Limitierungen?

Danke
pOpY

[gvzdus]

Ich habe mich in die Rules-API von Hue eingelesen. Das ist m.E. so akademischer Sch..., in dem sich Dinge wie Variablen oder geschachtelte IFs nur sehr begrenzt und mit sehr vielen Regeln abbilden lassen. Zugleich ist aber die Kapazität der Hue-Bridge für die Anzahl der Regeln eingegrenzt, weil "innen drin" wohl keine Rückübersetzung in effizienten Code läuft.

Du wirfst m.E. mit anspruchsvolleren Regeln - egal ob über iConnectHue oder Hue-Original erzeugt - zügig in Kapazitätsgrenzen laufen. Das ist mir zumindest mit 4 Bewegungsmelder und 3 Schaltern so passiert.

Deswegen baue ich alles, was ich mache, lieber in FHEM. Die "Logik" habe ich inzwischen aus Phoscon in FHEM übertragen.

[popy]

PS.: Phoscon Szenen funktinieren ja jetzt mit FHEM & auch mit der Android & jetzt auch iOS App -> HUE Essentials.
Optisch schaut darin alles so aus wie wenn man eine HUE Bridge steuert.

[Beta-User]

Meine Frage ist nun aber: Warum genau nutzt man ansonsten noch ein Phoscon Gateway?

Schwierig zu beantworten, wenn man die HUE-Bridge nicht aus eigener Anschauung kennt.

Ich kann über deCONZ bisher nicht klagen (auch wenn meine ZigBee-Erfahrungen auch teils gemischter Natur sind, aber das ist ein anderes Thema).

Vorteile, die ich sehe:
- deCONZ läuft bei mir auf derselben Hardware wie FHEM, ich brauche nicht "noch eine Hardware", die irgendwo rumsteht;
- push-API, isbesondere von Bewegungsmelder-Daten;
- (Herstellerübergreifende) firmware-update-Option (ich hoffe auch mal bzgl. eines Jung-Tasters, s.o....!)
- das USB-Dongle ist portabel, man kann es auch an einem anderen Rechner betreiben (wg. GUI/erweiterten Möglichkeiten. Frage an DE: Warum gibt es eigentlichen keine vollst. Kontrolle als "headless-expert-mode" und man muß diese dusselige GUI-Software nehmen?); (man muß dazu keine anderen Teilnehmer des ZigBee-Netzwerks anfassen, das geht "einfach so");
- deCONZ wird zwar von DE betreut, aber soweit ich das verstanden habe, ist das OpenSource, und man kann (im Prinzip) ggf. sogar selbst Geräte einpflegen (via xml-File), was ggf. wichtig ist, wenn man "Exoten" betreiben will (es gibt da z.B. auch Steuerungsaktoren für Fußbodenheizungen, so dass eQ-3 da kein Monopol hat). Bei einer Hersteller-Bridge ist man da auf firmware-updates des Herstellers angewiesen.

(Szenen habe ich in deCONZ bisher nur zwei erstellt, und das war ok; macht man ja in der Regel nur einmalig. Beides Bewegungsmelder->Beleuchtung)


Gg. der zigbee2mqtt-Lösung sehe ich (fast) nur die firmware-update-Sache als Vorteil an, und die Umgehung des Nachteils, dass das eine ziemlich heftige Begrenzung auf wenige Geräte enthält, die der CC253x "kann").

[SamNitro]

- (Herstellerübergreifende) firmware-update-Option

Kann ich über Deconz/Phoscon meine Xiaomi Fensterkontakte Updaten? Von meinen 11 Stück funktioniert einer leider nicht. Der Verliert nach kurzer zeit die Verbindung...

[Beta-User]

Kann ich über Deconz/Phoscon meine Xiaomi Fensterkontakte Updaten? Von meinen 11 Stück funktioniert einer leider nicht. Der Verliert nach kurzer zeit die Verbindung...

Theoretisch ja, praktisch ist die Frage, ob du eine passende firmware-file hast (hat man in der Regel leider nicht, aber für IKEA geht das z.B., wenn auch sch... umständlich, und ob alle firmwares verfügbar sind, kann ich auch nicht sagen). Über phoscon sollte sich jedenfalls ermitteln lassen, ob die firmware dieselbe ist; wenn ja, hat es vermutlich andere Ursachen, wenn die Verbindung wegbricht (Batterie hast du mal ersetzt? Habe gelesen, dass die mitgelieferte teils ziemlich leer sein soll...).

[popy]

@SamNitro & @Beta-User : Versteh ich das Richtig, ihr setzt als Haupt Gateway deCONZ ein?

Wäre es nicht eine Idee die Geräte was man Updaten will kurz auf die HUE/Tradfri Bridge zu pairen.
Ich habe das jetzt während der Test/Migrationsphase mal ein paar Mal mit Lampe, Dimmer & BM gemacht.
Phoscon bzw. die HUE Bridge arbeitet dann mit der letzten Konfiguration weiter und man verliert nichts.

Eine andere Frage noch, sorry schon mal für OT, wie stellt iht bei den Philips BM über deCONZ das Lightlevel ein?
Oder macht ihr das dann einfach über FHEM (wenn lightlevel <).

pOpY

[Beta-User]

@SamNitro & @Beta-User : Versteh ich das Richtig, ihr setzt als Haupt Gateway deCONZ ein?

Als IO für ZigBee-Material habe ich nur (noch) deCONZ (früher mal CC2531@zigbee2mqtt), weitere Hardware ist nicht vorhanden.

Wäre es nicht eine Idee die Geräte was man Updaten will kurz auf die HUE/Tradfri Bridge zu pairen.

Idee vielleicht, allein: es fehlt die Hardware; ich wollte eigentlich nicht extra deswegen eine Tradfri-Bridge besorgen, zumal mir das nur was bringt mit IKEA-Material, oder kann die auch Tint und Aqara?
Außerdem käßt es mich an, wenn ich mich nur wegen eines updates durch wieder eine typischerweise unvollständige Bedienungsanleitung lesen muß...

Ich habe das jetzt während der Test/Migrationsphase mal ein paar Mal mit Lampe, Dimmer & BM gemacht.Phoscon bzw. die HUE Bridge arbeitet dann mit der letzten Konfiguration weiter und man verliert nichts.

Interessante Info, ich hätte vermutet, dass man die Teile jeweils wieder resetten muß und dann bei der Rückkehr eben wieder die Funktionalität haben, an die deCONZ sich erinnert (das war v.a. mit dem Jung überraschend, was da beim An- und wieder Ablernen abging, aber das ist afaik ein spezielles Thema, das diesen Taster betrifft...)

Eine andere Frage noch, sorry schon mal für OT, wie stellt iht bei den Philips BM über deCONZ das Lightlevel ein?
Oder macht ihr das dann einfach über FHEM (wenn lightlevel <).

Ich habe im Moment nur 3 ZigBee-BM, einen IKEA (scheiße) und zwei Xiaomi (super); dabei verwende ich den internen "Lichtsenor" von deCONZ (reine Tag/Nacht-Schaltung), das paßt an den beiden Stellen (die Xiaomis machen zusammen das Treppenhaus) soweit eigentlich ganz gut (ich werde mir das aber bei Gelegenheit mal anschauen, denn wenn das ohne GW geht, ist das ein Bonus, den ich gerne mitnehme).

[Loredo]

Oder kennst du eine GUI-Lösung (ähnlich den Android/iOS Apps) um die Regeln für den BM zu erstellen ohne viel Zeit investieren zu müssen?

[...]

Hast du das Problem das die HUE Bridge voll ist?
Wie hast du das gelöst?

Du sagtest du hast die IKEA Bewegungsmelder über deCONZ (Phoscon) laufen, da brauchst du ja auch Repeater (Lampen) oder ähnliches damit das Mesh gut funktioniert, oder?
Hast du da noch ein paar Lampen platziert?

Ich kenne keine App, mit der man sonst Bewegungsmelder einfach konfigurieren kann. diyHue sah mir mal so aus als wenn man da einfach alle ZigBee Gateways unter einem Gateway vereint bekommt. Theoretisch war das wie gesagt auch so, praktisch sind da leider viele Kinderkrankheiten drin und bei sowas wichtigem wie den Rules habe ich selbst keine Muße da zu debuggen und den Betatester zu spielen (Zeit, wie immer ...).


Ich habe keine volle Bridge. Von der Geräteanzahl bin ich bei allen Objekten soweit noch im Rahmen. Die Automationsregeln sind allerdings bei etwa 70% - geht also noch.


Mesh brauche ich hier aktuell nicht und im anderen Objekt brauchts diese Automation nicht. Wenn ich mehr von Ikea hätte, dann würde ich aber nochmals schauen einen Tradfri Gateway an den Start zu bringen, schon allein wegen Firmware Updates (konnte ich über Phoscon bisher nicht verifizieren, da Ikea ja fleißig keine Updates liefert ...).

Deswegen baue ich alles, was ich mache, lieber in FHEM. Die "Logik" habe ich inzwischen aus Phoscon in FHEM übertragen.

Ist halt eine weiter Abhängigkeit, die ich für ein Gewerk wie "Licht" nicht wirklich brauchen kann. Schlimm genug, dass man die Bridge laufen haben muss und Schalter sich nicht auch direkt unterhalten können (das war so schön in der HM Welt...). Ich wollte die Logik auch in ioBroker bauen (FHEM vertraue ich da nicht mehr als Hauptsystem, Thema Architektur...), will aber wie gesagt was verlässliches getrennt pro Gewerk. Gleichzeitig brauche ich etwas für sofort (um nicht im Dunkeln zu sitzen) und die Regeln in iConnectHue zusammenzustellen und mit den starren Zeiträumen bei Regeln waren für mich ein guter Kompromiss.


Eine zentrale "Orchestrierung" für gewerkeübergreifende Automationen ist nochmals etwas anderes, als wenn ich Grundfunktionen innerhalb eines Gewerkes zuverlässig haben möchte.
Aus diesem Grund bin ich auch mit meinem Umstieg auf die RaspberryMatic (+RedMatic für Homekit Export) so zufrieden - eine Box für die HM Welt und man muss nicht herumfrickeln und sich ständig über den Characteristik Mist ärgern und das Rad, was andere schon zig mal erfunden haben, selbst abermals entwickeln ... werde auch die Basis Rollladen Automation dort umsetzen, eben weils dann alles als eigenes Gewerk auf der RaspberryMatic läuft.

PS.: Phoscon Szenen funktinieren ja jetzt mit FHEM & auch mit der Android & jetzt auch iOS App -> HUE Essentials.Optisch schaut darin alles so aus wie wenn man eine HUE Bridge steuert.

Szenen sind ja überhaupt nicht die große Magie, sondern die automatische und intelligente Ansteuerung selbiger.
Szenen anlegen und manuell auswählen kann ich überall machen, bringt aber gar nichts in Sachen Hausautomation.

- deCONZ läuft bei mir auf derselben Hardware wie FHEM, ich brauche nicht "noch eine Hardware", die irgendwo rumsteht;

Da stand ich auch mal.

Ist für mich ja inzwischen wie gesagt eher ein Nachteil. Finanziell, Platzbedarf und Strom für ein halbes Rechenzentrum, um einen dann auch wieder wartungsintensiven Clusterbetrieb von <hierDieAktuelleTechnologieEinfügen>, kommt für mich inzwischen nicht mehr in Frage. Ich habe ein Hobby und ich habe einen Beruf, kann aber nicht mein Hobby auch noch ständig zum Beruf machen
Ich kann so mal eben eine "Wartung" oder was auch immer an einem einzelnen Gewerk durchführen, ohne dass gleich alles andere auch betroffen ist. Server aktualisieren und neu installieren? Kein Problem. VMs restoren? Kein Thema, Licht und Heizung laufen ja im Grundbetrieb separat auf den Pi's weiter.
"Peace of mind" ist mir da wichtiger und auch von anderen Community Projekten, wo sich Leute auf einen speziellen Bereich konzentrieren (wie z.B. RaspberryMatic) zu profitieren. Ich kann und möchte nicht neben meinen ganzen Eigenentwicklungen noch alles andere auch noch ständig pflegen müssen.

- push-API, isbesondere von Bewegungsmelder-Daten;- (Herstellerübergreifende) firmware-update-Option (ich hoffe auch mal bzgl. eines Jung-Tasters, s.o....!)- deCONZ wird zwar von DE betreut, aber soweit ich das verstanden habe, ist das OpenSource, und man kann (im Prinzip) ggf. sogar selbst Geräte einpflegen (via xml-File), was ggf. wichtig ist, wenn man "Exoten" betreiben will (es gibt da z.B. auch Steuerungsaktoren für Fußbodenheizungen, so dass eQ-3 da kein Monopol hat). Bei einer Hersteller-Bridge ist man da auf firmware-updates des Herstellers angewiesen.

Push API fehlt mir wie gesagt auch, ist Dreh und Angelpunkt bei allen gewerkeübergreifenden Automationen. Haben die Hersteller mit ihrer neuen "Allianz" ja aber auch endlich eingesehen, nur warten wir da auf die Früchte noch 2-3 Jahre drauf, wie immer (lasse mich ja gern überraschen wenns ein Jahr weniger wird ).
OpenSource und so ist gut. Aber das ist kein Ersatz für ein kommerziell gepushtes und gepflegtes Ökosystem, was eben auch seine Vorteile hat. Wer sich eben aus dem "Walled Garden" bewegt, steht halt dann eben auch auf dem Acker mit einigen Ansammlungen von Baumgruppen am Wegesrand. Das muss man wollen, auch vor allem zeitlich.


Firmware Update ist ein großes Thema. Ich gehöre zu der Fraktion, die gerne Updates einspielt, auch wenn augenscheinlich alles funktioniert. "Never change a running system" kann man bei der heutigen Sicherheitslage nicht mehr durchziehen, besonders bei Funksystemen. Man kann ja die Gateways in Subnetzen einkapseln wie man will, aber solange man Protokolle ohne Kabel benutzt... neue Funktionen will ich natürlich auch haben, Spielkind eben Deshalb empfiehlt es sich eben dann doch zu schauen, wie man die Herstellerinseln als solche sinnvoll beibehalten kann und die Inseln dann eben verbindet. Den "Zoo" an unterschiedlichen Dingen hat man so oder so auf die ein oder andere Art.

Wäre es nicht eine Idee die Geräte was man Updaten will kurz auf die HUE/Tradfri Bridge zu pairen.

IMHO nicht praktikabel. Nicht nur das ganze hin und her gepaire für Duzende Geräte. Auch weil ein Gerät nicht unbedingt die selbe interne ID am alten Gateway wieder bekommt. Große Schmerzen hinterher das dann überall wieder anzupassen... nicht nur in FHEM.

Ich habe im Moment nur 3 ZigBee-BM, einen IKEA (scheiße) und zwei Xiaomi (super)

Kannst du da mal aus dem Nähkästchen plaudern und die Unterschiede erklären? Habe seit dem Wochenende auch 2 Ikea Bewegungemelder für den Flur (steuern über ioBroker dann die Homematic Dimmer). Gefühlt reagieren sie nicht so zuverlässig aus allen Richtungen bzw. haben ein zu langes Timeout für die erneute Bewegungserkennung. Kann ich aber nach 1,5 Tagen noch nicht so ganz genau sagen ...

[justme1968]

schalter bzw. taster können direkt lampen steuern. die meisten machen das auch. das ist einer der gründe warum viele in der hue bridge garnicht zu sehen sind.

immer wenn du einen taster direkt mit einer lampe pairst wird direkt gesteuert. wichtig ist nur ihm vorher ins netzt deiner bridge zu bekommen damit die lampe weiterhin mit der bridge steuerbar ist und nicht mit dem taster ein neues netz auf macht.