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

Loredo

Zitat von: justme1968 am 13 Januar 2020, 16:22:47
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.


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 :-/


Zitat von: justme1968 am 13 Januar 2020, 16:22:47
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.


Ja, hatte ich mal mit dem teuren Busch-Jäger ZigBee teil. Grausam zu programmieren und extrem eingeschränkt. Dabei will man doch nur unterschiedlich schalten zu unterschiedlichen Zeiten (wenn man schon vom starren Zeitkorsett nicht weg kommt...). Sowas over-the-air zu programmieren (und zu backupen!) wäre ja eine Standardanforderung. Gibts aber nicht als DAU Lösung. Also ebenfalls meh :-/
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

Beta-User

Zitat von: Loredo am 13 Januar 2020, 16:13:56
Kannst du da mal aus dem Nähkästchen plaudern und die Unterschiede erklären?
Na ja, der IKEA ist schon kein Design-Wunder, will heißen: langweilig und vergleichsweise groß. Vor allem: Beschwerden über unzuverlässige Schaltungen hatte ich auch; das Ding hängt in einem Nebenbereich und ist nicht ganz so wichtig, aber wenn ich grade noch einen Xiaomi da gehabt hätte, wäre der direkt wieder in den Laden gegangen... (Jetzt sagt entweder keiner mehr was, oder es ist - warum auch immer - besser). Und wie sich der zuständige Konstrukteur die Aufhängung gedacht hat, würde mich auch interessieren, für meine Begriffe ist der Schlitz unten, sollte aber zum Aufhängen und Ausrichten besser oben sein.

Die Xiaomi liefern daneben noch "irgendeinen" Lichtlevel (und Temperatur?), der als Schätzwert ganz ok ist. Ich hatte den Wert eine kurze Zeitlang dazu genutzt, via FHEM noch eine MiLight-Leuchte indirekt zu schalten, das klappte ganz gut, zog aber andere Probleme nach sich. Das Design ist so, dass die von meiner Frau bisher nicht kritisiert wurden, und man kann die mit dem Fuß recht flexibel anbringen, was v.a. hier im Treppenhaus nicht ganz unwichtig ist. Es ist etwas "tricky", den Melder so zu platzieren, dass er rechtzeitig schaltet, aber nicht schon, wenn jemand am Gang vor dem Treppenhaus rumläuft; mit dem geht es jedenfalls nicht nur in der Beziehung deutlich besser und flexibler als mit den (stillgelegten) fest verbauten.



Was das "Ökosystem" angeht: Für mich wäre z.B. das ganze Gedockere nichts und viele Pi's würden mich zur Weißglut bringen. Noch kann ich das irgendwie überblicken und alles entweder über USB oder MQTT anbinden, deCONZ ist der einzige Service, der auf dem Server noch läuft, und es gibt eine Backup-da ja innerhalb der Software eine Backup-Funktion, mit der man zumindest theoretisch schnell einen Umzug machen können sollte.



Nähkästchen Teil 2:
Ansonsten wollte ich ZigBee (und den genannten Jung) haben, weil damit auch Direktverknüpfungen gehen - leider aber eben häufig eher theoretisch denn praktisch, an dem Punkt hatte ich mir mehr versprochen, das ganze ist deutlich weniger flexibel als ich das von CUL_HM her kenne (siehe auch dein Kommentar zu dem Busch-Jäger, wird vermutlich auch von insta geliefert).

Von der Roadmap her werde ich (dimmbares) Licht in Richtung ZigBee umziehen, wo jeweils angesagt (ist noch einiges MiLight), und dazu ggf. auch die (Bewegungsmelder-) Sensorik passend wählen, Eigenbauten bleiben MySensors, was heute CUL_HM ist, wird vermutlich ggf. durch ZWave ersetzt. Aber auch dort stellt sich das update-Problem...

Für "reine" Kauf-Sensorik (vorrangig Raumtemperaturen) teste ich grade mit Bluetooth (@OpenMQTTGateway) - klappt vergleichsweise gut. Wird ggf. auch ein Thema, falls die HM-Fensterkontakte mal nicht mehr wollen...
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

justme1968

weil wir gerade so schön off-topic sind:

- die ikea rollos sind bis jetzt ziemlich gut. aber die app schmier bei mir regelmäßig alle 10-15 sekunden ab. das reicht oft noch nicht mal zum pairen. hat noch jemand das problem oder eine lösung?

- die ikea app findet keine sonos lautsprecher

- mein fls-pp3 schmiert alle 1-2 wochen ab und tut nichts mehr. obwohl er ganz normal in der bridge ausschaut. angeblich hilft ein firmware update. das geht aber nur mit mit phospcon. nicht mit der hue bridge an dem er hängt. außerdem würde das update das ding auf zwei lampen aufteilen. ein mal farbe und ein mal ww/kw statt wie bisher eine lampe. finde ich nicht gut...

- weiß jemand wie man den hue bewegungsmelder dazu bringt uhrzeit gesteuert zu arbeiten statt nach festen zeiten?

- die hm fenstergriff sensoren verlieren bei mir regelmäßig alle einstellungen, die verbindung zur ccu und senden an broadcast. kennt jemand einen vernünftigen ersatz mit anderem protokoll? zwave oder zigbee wären ok.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

gvzdus

Meine Wut auf Hue kam konkret mit Bewegungsmeldern und dem Treppenhaus:
Damit eben *nicht* das Licht erst angeht, wenn man an der letzten Treppenstufe gestolpert ist und im Flur aufschlägt, habe ich Bewegungsmelder in den Fluren und zwischen den Geschossen im Treppenhaus angebracht. Erstere sollten "ihren" Flur steuern, letztere jeweils 2 Flure. Geht von der Logik her weder mit Hue noch mit iConnectHue, und die Überlegung, die Regeln dafür manuell in die Hue-Bridge zu donnern, habe ich verworfen.

Wenn ich nicht liebevoll angelernte, teils auseinandergebaute LivingWhite Plugs an diversen Stellen (wo nochmal?) unter der abgehängten Decke hätte, die ich nicht nochmal neu anlernen möchte, wäre ich schon längst auf ConBee gegangen.

Btw: Frisch gekaufter Innr Plug SP120 läuft super mit ConBee und HUEDevice - Stromverbrauch wird nach "define .. HUEDevice sensor xy" angezeigt.
Bbtw: Ich hatte gestern mal ein paar schaltbare Steckdosen untersucht, darunter auch 3 Zigbee-Viecher:
https://forum.fhem.de/index.php/topic,107269.0.html

justme1968

es gibt in den hue labs irgendetwas um eine lampe über zwei melder zu steuern. schau mal ob das vielleicht weiterhilft.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

SamNitro

Zitat von: Beta-User am 13 Januar 2020, 14:29:48
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...).

Also ich habe nur Deconz. Batterie habe ich noch nicht getauscht. Und ich habe mich mit der gui noch nicht auseinander gesetzt. Dafür muss ich den Stick aus meinem Raspberry nehmen.
(Intel-Nuc Proxmox) (Homematic) (EnOcean) (CUL868) (CUL433) (Zigbee2MQTT) (ESP8266) (Echo) (DUOFERN)

Beta-User

Zitat von: justme1968 am 13 Januar 2020, 16:56:50
- die hm fenstergriff sensoren verlieren bei mir regelmäßig alle einstellungen, die verbindung zur ccu und senden an broadcast. kennt jemand einen vernünftigen ersatz mit anderem protokoll? zwave oder zigbee wären ok.
...und ich dachte schon, ich wäre mit dem Problem alleine auf der Welt... (Bevorzugt scheint das zu passieren, wenn die kalt werden und die Batterien nicht mehr top.)
Für die Drehgriffe wird es schwierig, da gäbe es "das Eigenbau-Projekt" (gibt hier im Forum Platinen+Code für AskSin++ und 3D-Druckvorlagen), ansonsten hat fast jeder Hersteller bei "normalen Kontaktsensoren" irgendwas im Programm, u.a. (um mal auf das Thema wieder zurückzukommen) auch Xiaomi in ZigBee; was Langzeiterfahrungen angeht,  gibt es afaik allenfalls im 433MHz-Bereich China-Ware, die schon länger bei einzelnen Usern hier im Einsatz zu sein scheint.



Die innr SP120 habe ich übrigens auch, keine größeren Probleme damit @deCONZ.



Und die Lichtsteuerung im Treppenhaus läuft über 2 (Xiaomi) Bewegungsmelder, einer oben, einer unten, und je ein Leuchtmittel, eins oben, eins unten.
Kommt jemand oben in den Erfassungsbereich, geht das Licht oben (fast) voll an, unten gedimmt; geht er nach unten, wird unten hochgedimmt, bzw. beim Hochlaufen das ganze umgekehrt.
Nach einer gewissen Zeit wird dann abgedimmt und irgendwann dann ganz aus.
War mit deCONZ kein größeres Problem, die Logik so einzurichten, und hat mit der sanften" Funktionsweise auch meine Frau überzeugt ;) .

EDIT: Das mit der Batterie betrifft nicht den ConBee II-Stick, sondern den Bewegungsmelder. Dafür muß der Stick nicht raus, oder?!?
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

Loredo

Zitat von: gvzdus am 13 Januar 2020, 17:02:54
Btw: Frisch gekaufter Innr Plug SP120 läuft super mit ConBee und HUEDevice - Stromverbrauch wird nach "define .. HUEDevice sensor xy" angezeigt.


Ah cool, dann wird der auch mal an Phoscon umgehangen.
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

Loredo

Zitat von: Beta-User am 13 Januar 2020, 17:13:52
ansonsten hat fast jeder Hersteller bei "normalen Kontaktsensoren" irgendwas im Programm, u.a. (um mal auf das Thema wieder zurückzukommen) auch Xiaomi in ZigBee; was Langzeiterfahrungen angeht,  gibt es afaik allenfalls im 433MHz-Bereich China-Ware, die schon länger bei einzelnen Usern hier im Einsatz zu sein scheint.


Genau solche Rückmeldungen wollte ich ;-)
Einfach mal wissen, was mit Phoscon so angestellt wird. Kontaktsensoren sind bei mir noch immer HM, hab auch jüngst erst welche auf Hm-IP umgestellt. Die fehlende Intelligenz für ThreeState ist mir aber immernoch schleierhaft... dass man immer aus den Gewerken ausbrechen muss, um einfachste Dinge umzusetzen, ärgert mich. Dein Hausflurlicht klingt einfach, aber ist es eben leider auch: Mir würde es fehlen, dass ich zu unterschiedlichen Tageszeiten nicht nur unterschiedlich hell dimme, sondern auch unterschiedliche Farbtemperturen habe. Geschweige denn unterschiedliche Rampup Zeiten und Timeouts. Ob sowas mit den Phoscon Rules geht, keine Ahnung... zumindest nicht über die GUI. Und irgendwie stört es mich, dass man wegen jeder Kleinigkeit erstmal Tage und Wochen recherchieren und ausprobieren (und scheiten...) muss. Ich glaub ich zünde wieder Kerzen an. Ich hab inzwischen durchaus viel Verständnis für Menschen, die nix smartes wollen. Solange sie das nicht aus genereller Technikfeindlichkeit, sondern mit fundierten Erfahrungswerten tun, kann ich solche Menschen für ihre Konsequenz nur beneiden ^^
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

Beta-User

Zitat von: Loredo am 13 Januar 2020, 17:24:04
Genau solche Rückmeldungen wollte ich ;-)
Na ja, der verlinkte Thread startet 2015, ich habe aber nicht nachgesehen, wann er endet...
Und nach meinen bisherigen Xiaomi-Erfahrungen würde ich sagen: das Zeug ist von der Tendenz her schwer ok, das Risiko, einen Ausreißer zu erwischen, kann ich bei dem Preis in Kauf nehmen ;) .

Zitat
Dein Hausflurlicht klingt einfach, aber ist es eben leider auch
...schon klar... Da ist auch noch eine day/night-Unterscheidung bei, aber das macht es nicht wesentlich besser oder wesentlich inteligenter. Der Punkt ist aber: es läuft, es gibt eine Info, was bewegungsmäßig Sache ist, das ist für den Bereich schon völlig ausreichend ;D .

Zitat
Und irgendwie stört es mich, dass man wegen jeder Kleinigkeit erstmal Tage und Wochen recherchieren und ausprobieren (und scheiten...) muss. Ich glaub ich zünde wieder Kerzen an. Ich hab inzwischen durchaus viel Verständnis für Menschen, die nix smartes wollen. Solange sie das nicht aus genereller Technikfeindlichkeit, sondern mit fundierten Erfahrungswerten tun, kann ich solche Menschen für ihre Konsequenz nur beneiden ^^
Ebend, ich hatte dann (beim Treppenhaus jetzt) auch irgendwann keine Lust mehr zur weiteren Optimierung, und es ist ok, wie es ist. Auch die Küchenbeleuchtung (der Jung sollte das übernehmen...) läuft im Moment ganz klassisch mit Schaltern (ja, Strom weg=aus).
Ich versuche auch niemanden sonst in meinem persönlichen Umfeld zu überzeugen, dass man "sowas" wie ein SmartHome braucht. Solange das so ist, dass man erst mal jahrelange Erfahrungen haben muß, um überhaupt mal mit planen anfangen zu können, wird sich da auch nichts wesentliches dran ändern.
Und der Glaube, dass irgendeine Software aus irgendeiner Quelle daran was wesentliches ändern kann, ist mir zwischenzeitlich abhanden gekommen, was weniger an FHEM liegt denn eher an der Erkenntnis, dass wir halt alle nicht ein IKEA-Leben in einer 100% normierten IKEA-Box führen, sondern alles mögliche um die Nutzer drumrum gebastelt sein will (bzw. auch um deren sich ändernden Gewohnheiten, Ansprüchen und sonstigen Erfordernissen).

Andererseits wollte ich z.B. die Möglichkeiten der (sinnvollen und) flexiblen Heizungssteuerung nicht missen, ebensowenig wie die eine oder andere einfache (?) Logik, Steuerungsmöglichkeit....
Von daher: Ist alles irgendwie ein Kompromiß, und (um auf das eigentliche Thema hier zurückzukommen) deCONZ ist ein m.E. ein akzeptabler Vertreter eines Kompromisses ;D .
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

Loredo

Zitat von: Beta-User am 13 Januar 2020, 17:47:11
Von daher: Ist alles irgendwie ein Kompromiß, und (um auf das eigentliche Thema hier zurückzukommen) deCONZ ist ein m.E. ein akzeptabler Vertreter eines Kompromisses ;D .


Genau das ist auch meine Schlussfolgerung: Nicht entweder oder, sondern sowohl als auch. Leider. Von daher habe ich Phoscon jetzt mal ergänzend im Einsatz, mal sehen wohin das so führt.
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

Thyraz

Wenn man all seine Beleuchtung mit Hue macht, mag Deconz nicht die (alleinige) Wahl für einen sein.
Die Hue-Bridge mit ihrem Polling bei Sensorik ist ja aber auch nicht der heilige Gral für jeden Nutzer.

Ich nutze zur Hauptbeleuchtung z.B. Zwave.
Hue ist bei mir nur für die Stimmungsbeleuchtung zuständig (alles was eben ursprünglich keinen Wandtaster hatte:
Stehlampen, Lightstrips, Akzentbleuchtung, Lampen bei denen ich auch mal Farbe einsetzen wollte, ...)

Die Hue-Lampen sind bei mir also absolut nicht notwendig als Basisbeleuchtung wenn FHEM mal ausfallen sollte.
Habe daher auch nie Regeln im original Hue-Hub angelegt gehabt.

Das mit den Farblampen war im Nachhinein eh ein Schuss in den Ofen bei mir.
Sieht in der Realität doch eher selten gut aus und ich hab fast alle Birnen durch Hue Whites ersetzt.

Hinter meinen Zwave Birnen sitzen dafür normale LED Birnen von Philips (Warmglow), welche von hell (normal warmweiss) nach gedimmt (noch wärmer) ihre Farbtemperatur verändern.
Meine Hues betreibe ich genauso, obwohl man hier ja mehr Möglichkeiten hätte:
- Die Lampen sind an sich Tagsüber alle Hell und normal warmweiss
- Abends ist alles etwas gedimmt und wärmer vom Farbton.

Für meine Anwendung ist Deconz dann schon schön um nur ein Gateway für alle Zigbee Geräte zu haben, das auch für Sensorik / Taster mit Push Richtung FHEM ermöglicht.
Ikea legt ja in letzter Zeit auch immer mehr nach mit Zigbee Geräten, Aqara wurde ja auch schon genannt.
Fhem und MariaDB auf NUC6i5SYH in Proxmox Container (Ubuntu)
Zwave, Conbee II, Hue, Harmony, Solo4k, LaMetric, Echo, Sonos, Roborock S5, Nuki, Prusa Mini, Doorbird, ...

P.A.Trick

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.
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

gvzdus

Wo wir hier gerade mal nicht einem Bug oder einem Fehler nachjagen:
Nochmal zur "Treppenhaus-Kritik" von Hue: Wenn man für einen hübschen dreistelligen Betrag Lampen, Schalter und Bewegungssensoren anschafft, dann möchte man das auch halbwegs sinnvoll zusammenbringen, und das sprengt schon im EFH die Hue-Bridge.
Klar ist doch: Ein Schalter, eine Willensbekundung via Alexa, etc. haben Prio 1, Bewegungssensoren Prio 2, und eine eventuelle Grund-Nachtbeleuchtung Prio 3. Die Hue-API erlaubt Variablen: Über den gigantischen Umweg eines Pseudosensors, der u.a. genau eine Variable führen kann. iConnectHue nutzt nun diese Pseudovariablen, um z.B. Dinge wie "Taste mehrfach gedrückt" hintenrum abzubilden. Man kann darüber auch fehlende Konstrukte wie die Variable zu einer Gruppe wie "Welcher Sensor ist jetzt dafür zuständig, sie auszuschalten?" oder den Fallback-State irgendwie abbilden, aber das führt zu einer enormen Inflation der Regeln. Prinzipiell Trigger der Zustandsänderung (z.B. "Keine Bewegung bei Sensor 1") mal Anzahl der Ausgangsstati mal Tag/Nacht/was auch immer für Zeiten. Daher ist das m.E. "broken by design". Das einfachste Beispiel ist der lange (Hotel-)Flur, in dem sich Licht und Sensor abwechseln, und der Sensor jeweils die beiden benachbarten Leuchten verwaltet. Für den Fall des "Zurückgehens", oder mehrerer Personen etc. lassen sich hier Beispiele finden, wo es ohne die Übergabe der Verantwortung "Okay, jetzt bist Du für das Ausschalten dieser Birne verantwortlich" nicht geht - Lichter bleiben an oder gehen vorzeitig aus. Alles in FHEM kein Problem, in Hue nicht per GUI abbildbar.

Von der Phoscon-GUI / deCONZ als Steuerlogik bin ich weg, weil allein schon das "Georg, warum geht das Licht im Flur an, wenn es doch gerade echt hell ist?" sich mangels Support der Helligkeitserkennung des Hue-Motionsensors in Phoscon nicht abbilden ließ.

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

slor

Bin auch großenteils mit der Logik nach Fhem gewandert.
Bei mir funktionieren Osram Lampen auch prima. Seit min. 6 Monaten ohne ein Problem.
Lediglich die Tadfri Leuchten zicken alle 3 Monate mal rum. Strom weg und wieder dran und alles gut.

Xiaomi Schalter schalten nur zu 70%... das ist echt mist. Die Bewegungssensoren sind super. Bis auf die 2 min Zwangspause.

Wo es auf Schnelligkeit ankommt habe ich HM-IP Präsenzmelder.
Fhem auf Raspberry Pi 4
CCU3 mit RaspberryMatic mit HMCCU an FHEM
HMCCU, Telegram, Conbee2 und Hue/Tradfri/Osram Lampen AQARA Sensoren, HomeConnect