Wie gesagt, bei mir wurde die Datei automatisch angelegt und die entity wird angezeigt. Unter "Integrationen" steht bei mir aber, glaube ich jedenfalls, nichts. Der "Rest" ist aber ohnehin "Handarbeit", wobei ich bei mir momentan echt keine sinnvollen Automationen sehe. Außer, man will die Harmony-Aktionen auf Taster legen und sie im Zusammenhang mit bestimmten Lichteinstellungen auslösen. Ja, das könnte tatsächlich sinnvoll sein
Beiträge von DSchumacher2104
-
-
Einer Person-entity kann man mehrere device-tracker zuordnen, anhand derer die Anwesenheit dieser Person festgestellt wird. Dabei kann man auch die Prioritäten der einzelnen device-tracker untereinander bestimmen (z. B. Bluetooth vor WLAN vor GPS oder so). Sie selbst haben keine eigene Funktionalität, wenn ihnen keine device-tracker zugeordnet sind. Device-tracker können z. B. der Status eines WLAN-Geräts im Router oder der GPS-Standort sein. Oder das Anpingen eine MAC-Adresse.
-
@m4d-maNu Ich habe zwar einen Harmony-Hub und eine Elite Fernbedienung, aber nutze sie gar nicht in HASS.IO. HASS.IO hat aber automatisch eine Datei harmony_hub.conf erzeugt, in der alle von mit angelegten Aktionen und die an den Hub angebundenen Geräte mit allen Befehlen aufgeführt sind. Ich vermute, dass man dies alles über HASS.IO auslösen und abfragen kann. Wie das aber genau geht, habe ich noch nicht ausprobiert. Allerdings erweckt dies den Eindruck, dass HASS.IO für alles in diesem Zusammenhang gerüstet sein sollte!
-
Alles anzeigen
Okay
was wäre der Vorteil/Nachteil vom Gateway, ist es sinvoll es darüber zu betreiben
oder
was wäre der Vorteil/Nachteil es über einen ConBee II zu machen?
das was ich bis jetzt gelesen habe ist das man ohne den Gateway keine Updates machen kann für die Geräte was ja eigentlich eher ein Nachteil ist,
auf der anderen Seite wäre es ohne Gateway natürlich auch gut da mir langsam die Plätze zum einstecken ausgehen.
Ich würde eher zu Conbee II greifen, da man dort alle ZigBee-Geräte einbinden kann, so dass man ein riesiges Mesh-Netzwerk bekommt, von dessen Reichweite auch die Aqara-Sensoren profitieren.
-
Ich kann alle hier nur ermutigen, sich in HASS.IO einzuarbeiten. Es ist schon etwas komplizierter als HomeKit/homebridge, aber absolut zuverlässig und wirklich extrem stabil. Und mal kann, wie upwind_anderl ja schon geschrieben hat, alles sichern und im Falle eines Falles mit wenigen Klicks zurückholen. Allein aus diesem Grund ist es allen anderen Systemen, die ich bislang getestet habe, überlegen. Zugegeben, bei ioBroker gibt es auch eine Backup-Funktion, die ich aber im Rahmen meines Tests nicht ausprobiert, weil ich schon aus anderen Gründen abgebrochen hatte.
-
Die Euphorie ist erstmal tatsächlich wieder gebremst, dies aber nichtmal aus technischen (Nicht)Wissensgründen zum Thema hassio, sondern wegen deiner Bemerkung, dass du weder openhab noch iobroker kennst. Genau in diesem Gesamtzusammenhang brauche ich nämlich, wie oben bereits geschrieben, unbedingt mal einen detaillierten und möglichst objektiven Vergleich der ganzen alternativen Systeme, um eine möglichst optimale Entscheidung für mein Vorhaben treffen zu können.
Ich habe auch openhab und iobroker ausprobiert, für mich ist HASS.IO ganz klar besser. Es ist umfassender, was die Integrationen betrifft, und auch deutlich einfacher zu bedienen.
-
Ich habe mir eben einmal angesehen was mit der Einbindung der von mir oben genannten Dinge so geht.
Zuerst sah es ganz gut aus, bis ich mir die tuya Anbindung angesehen habe. Die funktioniert leider nicht lokal, sondern geht über die tuya Server. Das geht bei mir leider gar nicht, da ich allen tuya-Geräten nach der Installation den Draht ins Internet abgeklemmt habe und sie nur lokal von der homebridge bedient werden. Also werde ich wohl doch bei homebridge bleiben.
Schaut dir mal diese custom_component an:
https://github.com/NameLessJedi/localtuya-homeassistant
Die funktioniert lokal. Allerdings kann man ein tuya-Gerät nur einmal lokal ansteuern, du musst also die homebridge-tuya-Integration dafür abschalten!
-
Ein Bug ist es nicht, der Auslöser der Automation funktioniert halt ereignisbezogen. Wenn das Ereignis kein weiteres Mal eintritt, sondern nur fortbesteht, greift konsequenterweise die Deaktivierungsregel. Um nach deiner Vorstellung wunschgemäß zu funktionieren dürfte der Auslöser nicht das einzelne Bewegungsereignis sein, sondern "solange eine Bewegung erkannt wird". Solche Auslöser bietet HomeKit nach meinem Kenntnisstand aber (noch?) nicht!
-
Danke DSchumacher2104, aber diesen Trick kenn und verwende ich, er funktioniert nur recht unzuverlässig. Bewegt man sich nämlich in den 3 Minuten der 2. Automation ununterbrochen, dann schaltet er das Licht dennoch aus. Komisch, ist aber so.
Dann wird der 2. Timer durch die erste Regel vermutlich nicht abgebrochen.
Wenn du deine Hue-Bridge über homebridge-hue eingebindest, kannst du die Duration für den Hue Motion in der Eve-App auf z. B. 3 Minuten stellen. Dann kannst du mit einer 2. Regel bei "keine Bewegung erkannt" das Licht sofort ausschalten. Das hat bei mir fehlerfrei funktioniert! Allerdings reagiert der Hue Motion über das Plugin etwas träger, weil die Hue-Bridge Änderungen an das Plugin nicht pusht, sondern alle 2 Sekunden vom Plugin abgefragt wird. Den "heartbeat" kannst den in der Eve App auf 1 Sekunde senken, das lief bei mir stabil ohne die Hue-Bridge zu überfordern.
-
Hallo DSchumacher2104, kurze Frage:
Mit welchem Eintrag in der json.config hast du die Duration eingestellt? Hast du die Hue-Bridge oder Raspbee mit deconz? Und durch die Einstellung hast du es geschafft, die 10 Sekunden-Duration des Hue Motion tatsächlich zu verkürzen, so dass ich bei "Dauerbewegung" im Raum nur ca. 2 Sekunden mal still stehen muss, damit die Automation wieder startet? Danke.
Tut mir leid, ich kann überhaupt nicht nachvollziehen, was du meinst. Das 10-Sekunden-Update-Intervall ist fest im Hue Motion integriert, dass kann man nicht verkürzen. Er sendet halt höchstens alle 10 Sekunden eine neue Bewegung, kürzer löst er intern nicht auf.
Das hat aber mit dieser in diesem Zusammenhang unbrauchbaren Möglichkeit, in HomeKit die Ausführung einer Regel nach x Minuten zu deaktivieren, gar nichts zu tun. Das ist ein ausschließliches HomeKit-Problem. Eine vernünftige Programmierung für eine Lichtsteuerung mit Bewegungsmeldern funktioniert halt genau andersherum, nämlich dass das Licht x Minuten verzögern, nach dem keine Bewegung mehr erkannt wurde, ausgeschaltet wird. Das kann HomeKit aber nicht, bzw. nur mit etwas tricksen! Du musst das Licht mit einer Regel bei Bewegung einschalten und in dieser Regel das Deaktivieren auf z. B. 12 Stunden stellen (mit einer Drittanbieter-App!). Mit einer zweiten Regel schaltest du das Licht auch bei keiner Bewegung ein und in dieser Regel stellt du das Deaktivieren auf den Zeitraum, den das Licht dann noch anbleiben soll, z. B. 3 Minuten, damit es nicht schon bei "kurzen" Bewegungspausen während der Anwesenheit ausgeht. Durch den Timer in der ersten Regel wird der Timer in der zweiten Regel abgebrochen, wenn eine neue Bewegung erkannt wird!
-
Wenn zwischendurch Bewegung erkannt wird, wird nichts ausgeschaltet, sondern eingeschaltet (was ohnehin schon eingeschaltet war). Nur die Deaktivierungsfrist wird neu gesetzt. Etwaige zwischenzeitliche Änderungen in der Lichtszene oder andere Lichtszenen werden allerdings wieder zurückgesetzt.
Das Problem dürfte sein, dass, wenn der Sensor ununterbrochen Bewegungen registriert, das Licht nach der eingestellten Zeit ausgeht!
-
Ich kann die Probleme von MikeDelta auch bestätigen, die Home App läuft zeitweise sehr unstabil. Zudem liefen bei mir auch einige Automationen nicht zuverlässig, scheint aber so langsam zu stabilisieren. Zum Glück nutze ich inzwischen für viele Dinge HASS.IO
tvOS 13.1 habe ich installiert, leider habe ich noch ein altes iPhone 6 in meinem Setup, das von iOS 13 nicht mehr unterstützt wird. Ich bin mal gespannt, wie sich das auf die Stabilität von HomeKit auswirken wird. Mit alten iOS 9.x Geräten kann man ja gar nichts mehr anfangen, da sie die Konfiguration zerschießen. Ich hoffe, dass man iOS 12 Geräte unfallfrei weiterbenutzen kann
-
Doch das geht. Weniger als 10s funktioniert nicht. Aber raufsetzen geht.
Das ganze kannst du direkt auf der Bridge ändern, über die REST API.
Bist du dir sicher? Wenn man den Hue Motion über deCONZ verbindet, kann man den delay-Wert in der sonsor-config über die deCONZ-API ändern. In der Hue-API konnte ich diesen Wert nicht finden. Kann man den trotzdem manuell zusätzlich in die sensor-config einfügen?
-
Nochmal, mein Licht wird nur eingeschaltet, d.h. ein Sensor muss nur kurz eine Bewegung erkennen und danach ist egal, was er erkennt. Dazu gibt es noch diverse komplizierte Bedingungen (die jetzt zu weit führen würden) und alles funzt ganz ohne Zappeln in Perfektion. Problem ist einzig die Situation, ich bin im Raum und gehe kurz in den Flur (Licht im Raum geht aus, im Flur an), um nach dem Einkauf kurz die Tasche in den Flur zu stellen, gehe innerhalb von 10 Sekunden zurück und löse in dieser Zeit eben wegen der zu trägen Duration nix aus und Licht im Raum bleibt aus und ich muss den Schalter bemühen.
Du solltest vielleicht mit Lichtschranken arbeiten
-
Achse, kurios. Aber man kann von der Herstellern wirklich nicht erwarten, dass sie für so ein unübliches Szenario entwickeln. Wie sind die Sensoren denn installiert, dass sie nur beim Betreten eine Bewegung erkennen? Dafür ist der Erfassungsbereich doch viel zu groß
-
wenn die Bewegungsmelder nur Licht bei Bewegung Ein- bzw. Ausschalten. So spielt es keine Rolle ob in den Raum Mann/Frau auf der Couch liegt und pennt oder ständig sich bewegt. Damit dies so dann aber auch funktioniert darf auch nicht der Raum Überwacht werden sondern nur die Türe.
Verstehe ich nicht?!? Ich dachte es geht genau darum, dass der Bewegungsmelder das Licht bei Bewegung ein- und bei keiner Bewegung ausschaltet.
Alles anzeigenWenn die Duration aus geht, muss ja nicht automatisch das Licht ausgehen. „Licht an bei Bewegung, aus nach zB 5 Minuten“.
Ich finde es auch blöd, dass man den Hue Motion nicht unter 10 Sek. Duration setzen kann, da es schon mal vorkommt, dass in den zB 5 Minuten es keine 10 Sek. gibt, in denen keine Bewegung stattfindet und die Regel somit nicht neu ausgelöst wird. Was dazu führt, dass das Licht nach 5 Minuten ausgeht.
Und der Eve ist wg. dem fehlenden Helligkeitssensor für Lichtsteuerungen ungeeignet.
Gesendet von iPhone mit Community
Das ist ein reines HomeKit-Problem und hat nichts mit der Duration zu tun. In HASS.IO kann man einstellen, dass die Automation auslöst, wenn der Bewegungsmelder z. B. 2 Minuten lang keine Bewegung mehr erkannt hat. Und ob er dazwischen jede Sekunde, alle 10 Sekunden oder jede Minute eine neue Bewegung erkennt, spielt keine Rolle. Es kommt dann allein darauf an, dass er 2 Minuten lang keine Bewegung mehr erkannt hat.
-
loonypac Das Problem mit deiner 1-Sekunden-Duration ist aber insbesondere, dass du in dem Raum auch nicht 1 Sekunde ruhig sein darfst, da sonst das Licht sofort ausgeht, also nur war für Zappelphillip.
Genau dafür bzw. dagegen ist da die Duration da, dass selbst wenn man sich mal eine kurze Zeit lang nicht bewegt, das Licht noch eingeschaltet bleibt! -
loonypac Nein, das ist mal kein HomeKit-Problem, sondern das liegt ja nativ am Bewegungsmelder. Der sendet einfach nicht öfters, deshalb nützt es nichts, eine kürze Duration einzustellen als die Sensorelektronik selbst mitmacht. Ich denke, dass es zumindest auch etwas mit dem Stromverbrauch zu tun hat, würde er jede Sekunde senden, wäre der Stromverbrauch sicherlich deutlich höher als beim 10 Sekunden-Takt bzw. Minuten-Takt. Keine Ahnung, was es sonst noch für Gründe haben könnte?!?
-
Man muss in der EVE-App den Sensor auswählen, dann unter dem "Zahnrad" oben rechts, wenn man den Pfeil "aufklappt"!
-
Einstellen kann man in der EVE-App jedenfalls 1 Sek., aber ob der Sensor wirklich intern auch so auflöst und dann auch noch so schnell reagiert?!? Die Bluetooth-HK-Geräte waren ja noch nie die Schnellsten.
Über die deCONZ-Integration kann man bei den Xiaomi-Bewegungsmeldern ja auch eine Sekunde einstellen, nur senden sie die nächste Bewegung trotzdem erst nach 1 Minute an die Bridge. Der Effekt ist, dass HK nach einer Sekunde auf keine Bewegung umspringt und erst nach weiteren 59 Sek. wieder für 1 Sek. auf Bewegung stellt usw.. Also total sinnlos, diese Einstellungsmöglichkeit!
