Beiträge von loonypac

Hm, ich hab die Tasmota-Seite mal überflogen und fragte mich die ganze Zeit, was damit gegenüber Raven System im Zusammenhang mit einer Schaltzentrale für HomeKit zu gewinnen ist

Tasmota benötigt dazu immer eine Homebridge, Raven System läuft direkt. Desweiteren sind im Raven System bereits zahlreiche Sonoff-Teile unterstützt.

Und natürlich sind ESP8266 keine Auslaufmodelle, die von ESP32 abgelöst werden sollen. Insbesondere für einfache Schalter sind die absolut leistungsstark. Wie gesagt lassen sich die GPIOs durch günstige Interfaces erweitern, falls die Integrierten nicht reichen.

Nix gegen Tasmota, vor allem, wenn man mit Home Assistant, Open Hab und Co loslegen will, wäre das auch meine erste Wahl. Aber für eine bescheidene HomeKit-Schaltzentrale scheint mir das unnötig kompliziert, spätestens dann, wenn man nicht sowieso schon Homebridge laufen hat und dieselbe erst noch aufgesetzt werden muss. Ich kann mich mit der Einschätzung natürlich irren und lasse mich gern eines Besseren belehren

Zitat von walta

D1 Mini läuft über Tasmota und man braucht immer eine homebridge. Alternative ist das Raven System ohne homebridge - die hab ich aber nicht ausprobiert da sie anscheinend nicht mehr weiterentwickelt wird.

Ein Schaltzentralen-System habe ich über Raven System umgesetzt und kann dieses für das besagte Projekt wärmstens empfehlen, allein schon, weil es nativ HomeKit kann. Bislang nutze ich zwar nur virtuelle Schalter und Lampen in derzeit 4 separaten ESPs, eine programmiertechnische Umsetzung mit physischen Schalter ist aber recht leicht machbar. Die gesamte Konfiguration läuft über eine vergleichsweise einfach zu erstellende json Konfigurationsdatei, die man per Webbrowser editieren kann. Der größte Aufwand besteht tatsächlich darin, hübsche physische Schalter bzw. Taster zu finden, um sie in ein nicht minder schickes Gehäuse zu bauen. Die GPIOs des ESP können dabei als Inputs genutzt werden, um 5 separate Schaltzustände pro Taster umzusetzen. Über MCP23017 Interfaces lassen sich theoretisch bis zu 256 GPIOs in einem einzelnen ESP realisieren. Das sollte für komplexe Schaltzentralen reichen

Noch ein Hinweis zur Weiterentwicklung. Mitnichten wird das System nicht mehr weiterentwickelt! Der Entwickler ist sogar sehr emsig und veröffentlicht in recht kurzen Abständen Firmware-Releases, die sich in meinem Fall bislang anstandslos und völlig unaufwändig in die ESPs uploaden ließen. Zudem lassen sich die ESPs sehr einfach klonen bzw. backuppen, sodass man immer wieder beliebige Setups regenerieren kann, sollte man mal etwas zerschießen. Das System lässt sogar interne Schaltungen zu, bspw. wenn Schalter 1 aktiviert wird, soll er Schalter 2 deaktivieren u.ä. Es können derzeit allerdings "nur" ESP8266 verwendet werden, was bei einfachen Schaltern nach meiner Erfahrung mehr als ausreicht – HomeKit ist da der eigentliche Flaschenhals. Der Entwickler plant allerdings die Integration von ESP32 auf seiner ToDo-Liste.

Alle Möglichkeiten hier aufzulisten, würde den Rahmen komplett sprengen. Ich bedauere eigentlich nur, dass es viel zu wenig konkrete Beispiele für die umfangreichen Möglichkeiten gibt. Hier wäre eine User-Kommunikation sehr förderlich, grade beim konkreten Projekt der besagten Schalterzentrale, um sich gegenseitig zu unterstützen. Ich möchte zukünftig bspw. gerne Uhrzeiten für Schaltvorgänge im ESP programmieren, sowie die hoffentliche Möglichkeit nutzen, Schaltbefehle online und direkt im IoT-Sinne zwischen separaten ESPs ohne den Umweg über HomeKit zu übertragen, finde dazu im Moment aber keine konkreten Umsetzungen.

Wenn der HomePod deine Steuerzentrale ist, musst du ihn am besten für ein paar Sekunden stromlos machen. Ich kenne mich mit den Dingern nicht aus, vermute aber, dass man die im Unterschied zu den Apple TV nicht über Menü regulär neustarten kann!? Wichtig ist, dass du ALLE in der Home-App aufgelisteten Steuerzentralen neu startest bzw. aus- und wieder einschaltest. Ggf. Machst du das anschließend auch gleich noch mit der HUE-Bridge.

foos Ja, da scheint mir alles richtig. Sicherheitshalber könntest du noch in einer der beiden Automationen die „20:00“ durch „19.59“ ersetzen, um womögliche Überschneidungen zu vermeiden.

Ich hatte mit Zeitraum-Automationen in HomeKit zugegebenermaßen Probleme, weshalb ich sie irgendwann durch Zeitpunkt-Automationen mit virtuellen Schaltern ersetzt habe, die ich ihrerseits als Bedingungen in die jeweiligen Automationen geschrieben habe. Aber das ist ein anderes Thema. Probier erstmal die Neustarts!

Ich betreibe seit Jahren meine sämtlichen HUE-Bewegungsmelder-Automationen über HomeKit und habe keinerlei Probleme damit, gemischte Licht- und Schaltersysteme samt zahlreicher Bedingungen zuverlässig zu schalten. Mit den vergleichsweise sehr eingeschränkten Möglichkeiten der HUE-App könnte ich nicht viel beginnen. Aus dieser Erfahrung ist es also keineswegs „dumm“, alle Automationen in einem System anzulegen und nicht auf verschiedene Insellösungen zu fragmentieren.

Ich stelle seit Längerem fest, dass ich nach Änderungen oder Neu-Anlegen von Automationen in HomeKit meine (bewusst gewählte) einzige Steuerzentrale in Form eines ATV jeweils neu starten muss, um dieselben zu „aktivieren“. Das mag der Tatsache geschuldet sein, dass ich eng an der maximalen Anzahl von 250 Automationen in HomeKit kratze und das System deshalb für die Synchronisation ungewöhnlich lange Zeit benötigt – die vorgeschlagenen 10 Minuten und selbst 24 Stunden Warten bringen bei mir nix.

Wie schon gesagt bietet HomeKit in den meisten Fällen leider nur Spekulationsmöglichkeiten für Fehlfunktionen der besagten Art, dennoch scheint der berühmte Neustart aller HomeKit Steuerzentralen für die verschiedensten Probleme sehr erfolgversprechend. Das ist zumindest immer meine erste Tat bei mysteriösen Fehlfunktionen oder geänderten/neuen Automationen, die vom System ignoriert werden, dicht gefolgt von Neustarts diverser Gateways/Bridges. Damit konnte ich über die Jahre immer alle unerklärlichen Probleme lösen.

Ich habe solch eine Szenenwechselschaltung für meine Lichtszenen per RavenSystem umgesetzt (werde nicht müde, das System anzupreisen ), die ich per HUE-Dimmerschalter bediene und theoretisch bis zu 100 Szenen umschalten kann. Allerdings habe ich keine LED zur Statusanzeige integriert, was bei Lichtszenen nicht wirklich nötig ist. Das sollte allerdings auch funktionieren.

Entweder per unmittelbarer Umsetzung mit physischem Schalter an einem GPIO eines ESP8266 Mikrocontroller, der seinerseits bspw. intern eine im Controller integrierte LED schaltet und/oder mittelbar per beliebigem HomeKit-Schalter, der seinerseits per Automation einen virtuellen Mikrocontroller-Schalter samt LED schaltet.

In jedem Fall wäre das eine Bastelaktion, außerdem läuft das Ganze über WLAN, was sinnigerweise eine Stromversorgung per Netzteil nötig macht, wenn man nicht regelmäßig Batterien wechseln möchte.

Zitat von MarcS

Der Sinn und Zweck von Homekit ist ja "Hey Siri" (iPhones und iPads liegen hier in der Wohnung genug rum

Ich habe an allen wesentlichen Verweilstellen meiner Wohnung diverse Schalter und behaupte jetzt mal, dass es wesentlich einfacher und schneller ist, auf einen Schalter zu drücken als Siri über iPhone, iPad, Apple Watch anzufunken Ist natürlich reine Geschmacksache, wobei mein Konzept natürlich beides zulässt: Sowohl Schalter als auch unsere Freundin Siri

Zitat von MarcS

Das klingt interessant... Soll ich selber googeln oder hast Du DEN besten Link dafür parat?

Klaro, aber gerne doch -> https://github.com/RavenSystem/esp-homekit-devices/wiki

Die von mir erwähnten virtuellen Gerätschaften sind nur ein bescheidener Nebenvorteil der Möglichkeiten von HAA. Im Prinzip kannst du über das System alle elektrischen Gerätschaften HomeKit kompatibel machen und zwar nativ ohne irgendeine Bridge o.ä. Ich hatte bereits eigens entwickelte Durchgangszähler für Räume sowie hochpräzise Lichtstärkensensoren damit testweise zum Laufen bekommen. Shellys können lt. damit auch geflashed werden und könnten dann im Unterschied zu der hauseigenen Firmware theoretisch mit Zusatzfunktionen versehen werden, bspw. mehrere Timer oder KillSwitches, die ein Schalten per zusätzlichem Sicherheitsschalter verhindern. All das ist komplett dann wahlweise in HomeKit abgebildet und kann entsprechend umfangreich automatisiert werden. Ich weiß allerdings nicht, wieviel Speicherplatz in den Shellys steckt, d.h. wieviele Schalter, Timer dort platziert werden können.

Zitat von MarcS

An so einer Lösung wäre ich auch interessiert. Hast Du da mehr Infos?

Ich habe Einiges, wie gesagt, ja schon umgesetzt. Du kannst die virtuellen Schalter u.ä. beliebig definieren und funktionell sogar innerhalb des Prozessors miteinander verbinden.

Meine separate Lichszenenzentrale bspw. verfügt pro Raum über eine virtuelle Lampe, die Ihrerseits meine bevorzugten Lichtszenen durchsteppen kann. Damit kann ich jede einzelne Lichtszene auf einen expliziten Dimmwert im Sinne eines Speicherplatzes legen und per HUE-Schalter weitersteppen. Jeweils mit der virtuellen Lampe direkt im Prozessor verbunden sind 2 virtuelle Schalter mit ebenfalls jeweiliger Ausschaltverzögerung von 0,2 Sekunden, die den besagten Dimmwert bzw. Szenenspeicherplatz um 1 erhöhen oder verringern. Szenen kann man somit quasi für HomeKit über Bedingungen als aktiv oder passiv definieren oder direkt per Zahlenwert schalten. Der Fantasie sind keinerlei Grenzen gesetzt. Bei Bedarf kann das Ganze dann sowohl mit physischen Schaltern direkt geschaltet werden. Das hab ich allerdings noch nicht ausprobiert. Es geht noch unglaublich viel mehr…

Tja, HomeKit und Timer…

Alternative Möglichkeit, um das zeitverzögerte Ausschalten in HomeKit zu lösen, könnte eine Einschalt-Automatik sein. Zwar lässt Apple HomeKit keine "unmittelbaren" Timer zu im Sinne -> Gerät schaltet ein -> schaltet sich selbst nach Zeit X aus, jedoch immerhin eine "mittelbare" Lösung über ein anderes Gerät oder eine Zeit. Sprich: wenn du mit einem Schalter die Heizdecke über eine entsprechende Automation einschaltest, kannst du in den Automationseinstellungen den unscheinbaren Button "Deaktivieren - Nie" auf eine gewünschte Zeit einstellen, damit dieselbe danach das Gerät (bzw. alle in der Automation aktivierten Geräte) automatisiert ausschaltet. Alternativ zum Schalter als Auslöser lässt sich sicherlich (nicht getestet) eine Zeit oder ein beliebiger Sensor auswählen, es muss etwas anderes sein, was die Heizdecke einschaltet. Mein Automations-Versuch mit demselben Gerät als Auslöser, das sich selbst einschaltet, um dann nach Zeit X auszuschalten, hat bei mir nicht funktioniert und konnte HomeKit nicht überrumpeln. Ergo ließe sich eine automatisierte Siri-Ein-/Ausschaltung damit leider nicht realisieren, es sei denn über den Umweg des Automations-Auslösers, der die Heizdecke einschaltet.

Ansonsten gibt es als Alternative zur Shelly-Anschaffung auch die von mir immer gerne empfohlene Alternative über einen ESP8862 Mikroprozessor, mit dem man über das Ravensystem-Projekt mehrere virtuelle Geräte wie Schalter und natürlich auch Zeitschalter sehr leicht und kostengünstig für knapp 5,– € generieren kann (selbst die Shellys lassen sich damit offensichtlich umflashen), was sich dann direkt in HomeKit einbinden lässt ohne zusätzliche Homebridge, wenn man die nicht sowieso schon hat. Ich selbst habe mir inzwischen eine regelrechte HomeKit-Schaltzentrale angelegt. Der Vorteil ist, dass man dann alles in HomeKit derart schalten kann und gleichzeitig den Überblick über die Schaltzustände behält.

Ich habe für meine neuen Aqara-Thermostate einen anderen Ansatz für die Offene-Fenster-Automationen umgesetzt. Wichtig war mir einerseits die Automatisierung in HomeKit, respektive Controller für HomeKit aus den mehrfach genannten Gründen der erweiterten Möglichkeiten, sowie die Erfüllung mehrerer Logiken, die ich beim Entwickeln der derzeitigen Lösungen habe einfließen lassen:

• Beim Fenster-Öffnen soll nicht sofort der betreffende Thermostat ausgesschaltet werden – optimalerweise möchte ich pro Raum eine individuelle Ausschaltverzögerung einstellen können, um bspw. durch kurzzeitiges Öffnen nicht jedesmal eine Batterie zehrende Thermostat-Abschaltung auszulösen.
• Für den Fall, dass ich ein Fenster in einem Raum öffne, in dem der Thermostat bereits ausgeschaltet ist, soll nach dem Fensterschließen derselbe ausgeschaltet bleiben, was durch einen einfache Fenster SCHLIEßEN -> Heizung AN Automation leider nicht machbar ist.
• Ist das Fenster geöffnet und ist die Heizung ordnungsgemäß ausgeschaltet, soll ein (versehentliches) manuelles oder automatisiertes Einschalten wieder rückgängig gemacht werden. Grundsätzlich soll zu keinem Zeitpunkt eine nachträglich nach dem Fensteröffnen wie auch immer ausgelöste durchgehende Aktivierung der Heizung möglich sein.

Zugegebenermaßen ist meine Lösung nicht ganz einfach allein mit den Bordmitteln von HomeKit umsetzbar (also eher etwas für Bastelinteressierte). HomeKit hat bis heute leider für mich völlig unverständliche Einschränkungen, was virtuelle Devices betrifft.

Um die o.g. Anforderungen zu erfüllen, werden einerseits ein einfacher Timer sowie ein noch einfacherer Statusspeicher benötigt. Ersterer schafft die Möglichkeit, das Heizung-Ausschalten für eine Zeit X zu verzögern, Letzterer speichert den Heizungs-Schaltzustand im Moment des Fenster-Öffnens, um nach dem Fensterschließen den vorherigen Zustand wiederherzustellen.

Beides ist leicht mit einem der zahlreichen Delayschalter-PlugIns für Homebridge zu erstellen.

{"a":[{"t":1,"i":10},{"t":1}]}

Die eigentlichen Automationen erstelle ich nun in HomeKit. Pro Raum werden 2 Szenen und 4 Automationen benötigt, wobei Letztere ggf. noch vereinfacht/zusammengefasst werden können. Die Szenen sind den ebenfalls ärgerlichen HomeKit-Einschränkungen geschuldet, dass man einen Thermostat nicht direkt ohne gekoppelte Temperatur einschalten kann, was für meine weiteren Heizungsautomationen aber eine Grundvoraussetzung ist. Erfreulicherweise gestattet die Controller-App die Möglichkeit, Szenen mit einzelnen Device-Funktionen anzulegen – das ausschließliche Einschalten des Thermostats ohne Veränderung der Temperatur ist damit also machbar. Die explizite Ausschaltszene könnte dagegen gespart werden, da hier eine direkte Geräteschaltung des Thermostats möglich ist, weswegen in diesem Fall auch 1 Szene pro Raum ausreicht.

Automation 1

Auslöser: Fenstersensor öffnet, Heizung wird aktiviert

Bedingungen: Fenstersensor offen, Heizung aktiviert

Schaltergebnisse: Timer AN, Status AN

Erklärung: Die beiden Auslöser bewirken, dass ein Status immer geschaltet wird, also sowohl beim Öffnen des Fensters als auch beim Einschalten des Thermostats. Die Bedingungen sind dabei für die beiden Auslöser „wechselseitig“ zu verstehen, also Auslöser Heizungsaktivierung soll nur auslösen, wenn das Fenster geöffnet ist, Auslöser Fensteröffnung soll nur auslösen, wenn die Heizung angeschaltet ist.

Automation 2

Auslöser: Timer AUS

Bedingungen: Fenstersensor ist offen

Schaltergebnisse: Szene Heizung AUS

Erklärung: Nach Ablauf der Rückschaltzeit schaltet der Timer wieder aus und löst die Heizungsabschaltung aus unter der Bedingung, dass das Fenster offen ist.

Automation 3

Auslöser: Fenstersensor schließt

Bedingungen: Statusschalter ist an

Schaltergebnisse: Szene Heizung AN, Status AUS

Erklärung: Sobald das Fenster geschlossen wird, löst es das ausschließliche Einschalten der Heizung OHNE Temperatur-Änderung unter der Bedingung aus, dass der Status während des Fensteröffnens eingeschaltet wurde. Logischerweise würde die Automation also nur ausgeführt, wenn die Heizung vorher eingeschaltet war. Auch, wenn zwischenzeitlich bei offenstehendem Fenster durch eine separate Automation die Temperatur der Heizung geändert hätte, würde diese korrekt nach dem Fensterschließen beibehalten. Im anderen Fall eines nicht aktivierten Statusschalters würde keine der bisherigen Automationen ausgeführt und die Heizung bliebe in allen Fällen ausgeschaltet. Des Weiteren würde ein Einschalten des Thermostats innerhalb der Rückschaltzeit des Timers zwar den Status aktivieren, dennoch die Heizung nach dem Ausschalten des Timers wieder deaktivieren und erst nach dem Schließen des Fensters aktivieren. Auch wird bei mehrfachem kurzeitigen Öffnen und Schließen des Fensters innerhalb der Rückschaltzeit der Status jeweils richtig geschaltet, ohne die Thermostatbatterien zu strapazieren.

Automation 4

Auslöser: Heizung wird deaktiviert, Timer schaltet an

Bedingungen: Heizung deaktiviert, Timer ist an

Schaltergebnisse: Status AUS

Erklärung: ähnlich Automation 1 korrigieren die beiden Auslöser durch die wechselseitigen Bedingungen etwaige Ausschaltungen der Heizung während der Rückschaltzeit des Timers.

Die Lösung ist herstellerunabhängig. Prinzipiell lassen sich alle Thermostate nutzen, die schnell genug auf Ein- und Ausschaltbefehle reagieren (was meine FritzDect per Homebridge leider nicht taten), selbst gemischte Systeme werden funktionieren.

Moinmoin,

Sehr interessantes Thema! Dazu gab es bereits mehrere Beiträge (bspw. dieser). So richtig ausgereift als fertig kaufbare Lösung ist da nach meiner Kenntnis noch nichts, bzw. das Wenige recht teuer. Basteln ist also angesagt.

Ein neuer Sensor VL53L1X ist da recht vielversprechend (Dank an PhilippCF für den Tipp). Ich habe meinen Prototypen mit 2 Vorläufern zusammengebastelt und werde diese durch den besagten Neuen ersetzen, was die gesamte Schaltung einigermaßen vereinfachen kann. Derzeit gibt’s aber andere Baustellen…

Oder ganz ohne Umweg über Homebridge direkt nativ HomeKit-fähig machen per RavenSystem. Im Prinzip braucht man dafür nur die GPIO-Belegung für RGBW.

Ah ok, mit der Home App wirst du die Bedingungen nicht eingeben können. Ich benutze ja fast ausschließlich die Controller App. Das Ganze sollte aber auch mit den alternativen Apps genauso gut gehen.

Viel Erfolg!

Hm, auf die Gefahr hin, bereits erfolgte Vorschläge nochmal zu wiederholen, müssten doch einfache Automationen deine Anforderung erfüllen:

Zeitraum 6:00 bis 9:00.

Auslöser: Zeit 6:00 -> Bedingung: Vor Sonnenaufgang -> Licht EIN

Auslöser: Zeit 9:00 -> Licht AUS Kann entfallen, da hierzulande der späteste jährliche Sonnenaufgang vor 9:00 liegtt.

Auslöser: Sonnenaufgang -> Licht AUS

Zeitraum 16:00 bis 20:00.

Auslöser: Zeit 16:00 -> Bedingung: Nach Sonnenuntergang -> Licht EIN s.o. Der früheste jährliche Sonnenuntergang liegt hierzulande ca. bei 16:00

Auslöser: Sonnenuntergang -> Bedingung: Zeitspanne zwischen 16:00 und 20:00 -> Licht EIN

Auslöser: Zeit 20:00 -> Licht AUS

Aber vielleicht habe ich dein Vorhaben auch nicht richtig verstanden

Zitat von HomeBridgeBeginner

Meinst Du ich muss das RavenSystem auf meinen Raspberry installieren? Muss ich dazu Homebridge "deinstallieren"?

Nein, du brauchst gar keinen Raspberry mehr, bzw. keine Homebridge für den Zweck. Das Shelly hat einen standardisierten Mikrocontroller integriert, der durch das Flashen umprogrammiert und dadurch direkt in HomeKit eingebunden werden kann. Damit wird das Relais quasi nativ HomeKit-kompatibel, so wie die zertifizierten, teuren Apple-Geräte - nur eben ohne Zertifikat und für erheblich weniger Cash.

Vorteile liegen auf der Hand: Direkte Verbindung ohne Homebridge-Umweg = schnellere Schaltvorgänge. Weniger/kein Aufwand durch Raspi-und PlugIn-Konfigurationen, weniger Hardware-Gedöns und weniger potentielle Fehlerquellen.

Es kann durchaus sein, dass dein recherchiertes Wifi-Relais ebenfalls auf diese Art umprogrammiert werden kann, weil es vermutlich ebenfalls den besagten ESP8266 beinhaltet. Das müsste recherchiert werden.

Lies dir einfach mal den Artikel zum Umflashen durch, ob ein solches Prozedere für dich überhaupt in Frage kommt!

Moin HomeBridgeBeginner

Alternativ zur Homebridge-Einbindung könntest du das genannte Shelly1 auch direkt und ohne Umweg in HomeKit einbinden. Dazu müsstest du dasselbe mit der RavenSystem Firmware neu flashen. Zu dem Prinzip gibt‘s hier im Forum bereits eine gute Anleitung .

Na, das freut mich aber

Ich weiß auch nicht, warum Eve das nicht hingekriegt hat, da technischerseits in dem Zusammenhang keine Einschränkung besteht. Vermute dabei höchstens, dass der Fake-Switch nicht richtig in der Automation als Bedingung integriert war.

Auf ein Eve-Update zur Behebung des Problems würde ich nicht hoffen. Wenn dein besagter Test mit dem Fake-Switch positiv verlaufen ist, liegt das Problem sehr wahrscheinlich weder an Eve noch am Homebridge-Plugin. Hast du keine andere HomeKit-App, mit der du die Automation alternativ erstellen könntest?

Werden die Außenleuchten noch anderweitig über weitere Automationen geschaltet?

Um das Problem besser nachvollziehen zu können, müsstest du ein wenig mehr Details preisgeben. Screenshots könnten helfen.

Gerne

Na, dann scheidet der Switch doch schonmal als Fehlerquelle aus.

Was die "Übermittlung" an HomeKit betrifft, so kann es passieren, dass Automationen erst verzögert im System ausgeführt werden. Das KANN wohlgemerkt passieren, muss aber nicht. Dank der undurchsichtigen iCloud-Synchronisation seitens Apple ist hierzu auch leider keine verlässliche Aussage über das Warum, Wieso, Weshalb zu machen. In meinen Automationserarbeitungen hat sich bei Nicht-Funktion zu 90% der Steuerzentralen-Neustart bewährt. Vermutlich wird dadurch nochmal explizit abgefragt, was es alles so Neues in HomeKit gibt

Wenn also deine Testautomation schonmal funktioniert hat, würde ich persönlich nun als Nächstes einen Test mit Bewegunsgmelder statt Schalter machen. Dies ebenfalls in einfacher Form, also ohne zeitabhängige Bedingungen.

Moin redbull2906

Deine Automation ist prinzipiell goldrichtig angelegt. Nach diesem Prinzip reguliere ich meine gesamte Behausung.

Fehlermöglichkeiten gibt es Mehrere. Angefangen beim Fake-Switch per Homebridge-Plugin. Am besten testest du diesen mal in einer einfachen Testautomation mit einem Schalter und einer Lichtquelle (damit du nicht immer bis zum Sonnenuntergang warten musst). Fehler in der Eve-App ist nicht ganz auszuschließen, aber eher unwahrscheinlich. Du könntest einmal in der Home App nachsehen, ob die Bedingung dort aufgelistet wird und, falls du eine alternative HomeKit App hast (bspw. Controller App), alternativ mit dieser die Automation neu anlegen. HomeKit selbst birgt mitunter diverse Tücken, insbesondere bei neu angelegten Automationen, die eine gewisse Zeit brauchen können, bis sie im System verankert sind. Hier hilft zumeist ein einfacher Neustart der Steuerzentrale/n, nachdem man eine oder mehrere Automationen angelegt hat.

rel & BenGore

Ich war jetzt doch mal neugierig und habe die HUE App nach langer Zeit wiedermal zu Rate gezogen.

Der Knaller: Hier scheint die Duration TATSÄCHLICH auf ca. 4 bis 5 Sekunden verkürzt, zumindest in der Bewegungsempfindlichkeits-Übersicht. Ob das schon immer so war, kann ich nicht sagen, da ich darauf schwören könnte, dass bei meinen Anfangskonfis für mehr als 1 Jahr die Ausschläge in der HUE und der Home App ungefähr identisch lange brauchten. Das ist nun allerdings ein dicker Hund seitens Philips und bestätigt (einmal mehr), wie inkonsequent und halbherzig dort HomeKit implementiert wurde/ist. Und dies würde dann auch erklären, warum die Anwender, die ihre Bewegungsmelder direkt in HUE konfigurieren, weniger Schaltprobleme haben.

Übrigens denke ich nicht, dass eine HomeKit-Zertifizierung irgendetwas mit einer Qualitätskontrolle zu tun hat. Es werden vermutlich lediglich die Funktion und vielleicht noch einige Sicherheitsprotokolle während der Verbindung überprüft und dies sicherlich auch nur bei Markteinführung der Produkte. Deswegen scheint zumindest bei nicht sicherheitsrelevanten Geräten eine Zertifizierung wenig hilfreich oder aussagekräftig. Homebridge ist ja das allerbeste Beispiel dafür, dass eine Nicht-Zertizierung qualitativ und funktionell mindestens gleichwertig, wenn nicht sogar den zertifizierten Gerätschaften überlegen ist.