Beiträge von loonypac

    Wie gesagt: Bewegungssensoren sind eigentlich dazu ungeeignet, automatisiert Licht in einem Raum für eine mehr oder weniger durchgängige Anwesenheit von Personen zu schalten. Die Technik war ursprünglich eher für Eingänge, Flure und Treppenhäuser gedacht, also für Durchgangsräume, in denen naturgemäß deutliche Bewegungen von den vergleichsweise "unsensiblen" IR-Sensoren gut erkannt werden.


    Alle mir bekannten Bewegungssensoren für Smarthome auf IR-Basis besitzen eine, wie es sich hier im Forum begrifflich durchgesetzt hat, sogenannte Duration von mindestens 4 Sekunden. Bei Aqara ist bspw. ein Sensor verbaut, der nativ minimal nach 4 Sekunden eine erneute Bewegung erfassen kann, hier regelt allerdings der dazugehörige Hub unsinnigerweise diese technische Minimal-Duration auf minimal 1 Minute hoch. Ebenso wird sich das bei Philips verhalten. Ich habe zwar bislang noch keinen Motion-Sensor zerlegt, allerdings vermute ich denselben billigen Sensor wie bei Aqara, Eve und Co.


    Neben der Duration, die die minimale Zeit beschreibt, nach der eine neue Bewegung erfasst werden kann, ist besonders auch wesentlich die Triggermethode, die bei den besagten Sensoren zwar technisch vorgesehen ist, nach meiner Erfahrung (zumindest bei Aqara und Philips) jedoch wiederum unsinnigerweise nicht ausgewählt werden kann. Folgendes Schaubild verdeutlich die beiden Methoden, die je nach individueller Anforderung sehr nutzbringend sein können:

    Difference-between-single-and-repeating-trigger-HC-SR501.jpg


    Der von dir genannte Ikea-Bewegungsmelder macht seinerseits übrigens nichts anderes als seine Mitbewerber mit dem Unterscheid, dass er die Lampen direkt im Gateway auslöst, weil er nicht HomeKit kann. Sobald Homekit im Spiel ist, muss jeder Sensor erst per Umweg das Schaltsignal senden, was naturgemäß spürbar länger braucht. Deswegen reagiert ein Philips Motion, der in der HUE App konfiguert wurde und HUE-intern Lampen schaltet ebenfalls entsprechend schneller als er dies tut, wenn er in HomeKit konfiguriert wurde.


    Die minimal nutzbare Duration des Eve kenne ich nicht, sie dürfte aber, wie gesagt, baulich bedingt bei um die 4 Sekunden liegen. Das wäre zwar wesentlich besser als bei Philips, allerdings können auch 4 Sekunden unter gewissen Umständen schon wieder viel zu lange sein. Ich bleibe leider dabei: Bewegungssensoren auf IR-Basis sind für den vorgesehenen Zweck nur bedingt geeignet.

    2) Einsatz einer "unabhängigen" Steuerzentrale wie Homey oder openHAB und unterschiedliche Komponenten, z.B. von HomeMatic und Shelly.

    Die von dir genannten "unabhängigen" Steuerzentralen sind in der Tat von HomeKit unabhängig, um nicht zu sagen völlig eigene Systeme mit teils völlig unterschiedlichen Konzepten.


    Ich würde dir erstmal raten, unabhängig vom Smarthome-System möglichst präzise vorauszuplanen, was du wie weit automatisieren möchtest (Licht, Heizung, Sicherheitseinrichtungen, Fenster, Türen ectpp…). Dann stellt sich im nächsten Schritt gleich die Frage, was du – neben der Sicherheit – vom System erwartest und nicht zuletzt, was du an technischen Kenntnissen mitbringst, respektive bereit bist, an Zeit zu investieren, um dich in die jeweilige Materie einzuarbeiten. HomeKit ist zwar Apple-typisch eher für technisch unversiertere Anwender gedacht, in der Praxis ist allerdings besonders bei Problemfällen schon eine tiefere Kenntnis der Logik notwendig, wenn du nicht permanent mit vermeintlichen Fehlfunktionen oder Ausfällen leben möchtest. Denn 100% zuverlässig läuft ein (wachsendes) HomeKit nicht, was hier im Forum ungezählte Male belegt wird.


    Mit Systemen wie openHAB, HomeAssistant, FHEM u.ä. ist im Vergleich zu HomeKit zwar erheblich mehr möglich, allerdings dies immer um den Preis der vornehmlich Codebasierten Konfiguration, die den ein oder anderen schnell überfordern und abschrecken kann.


    Bei SmartHome zum derzeitigen Stand der Dinge auf eine 10-jährige Nachhaltigkeit zu hoffen, ist sicherlich etwas übertrieben. Es gibt ständig Neuerscheinungen und so gesehen steht dieses Thema eher noch am Beginn einer wirklich ungeahnten und unvorhersehbaren globalen Ausbreitung. Welches System sich in den nächsten Jahren letztendlich durchsetzt und das globale Rennen macht, steht bislang noch in den Sternen.


    Thema Sicherheit bei Apple: Bedenke bei deiner Überzeugung allerdings, dass HomeKit ausschließlich Cloudbasiert funktioniert – noch dazu in völlig intransparenter Art und Weise. Das ist für mich inzwischen ein zunehmend störender Nachteil, den ich gerne durch einen zukünftigen Systemwechsel vermeiden möchte. Wohin die Reise da geht, kann ich allerdings immer noch nicht sagen.

    weil es scheinbar nicht möglich ist nativ in Apple Home einen Bewegungsmelder so einzurichten, dass er so lange Licht schaltet, wie sich jemand in dem Raum aufhält.

    So etwas ist mit einem herkömmlichen IR-Bewegunsgmelder auch nur eingeschränkt möglich – egal von welchem Hersteller. Zu dem Thema gibt es allerhand Textmaterial hier im Forum mit den unterschiedlichsten Lösungsansätzen, die allesamt kompromissbehaftet sind. Ich habe das dadurch "gelöst", dass ich das Licht im Raum jeweils nur einschalten lasse und keinerlei Deaktivationszeit definiert habe. Das Ausschalten passiert jeweils durch das Verlassen des Raums und damit durch das Betreten des Flurs mit seinen separaten Sensoren. Das Ganze funktioniert allerdings nur bedingt mit mehreren Personen, weswegen ich für diesen Fall kompliziertere Bedingungen und temporäre Deaktivierungsmöglichkeiten in die entsprechenden Automationen integriert habe.


    Will man das richtig automatisieren, benötigt man einen Anwesenheitssensor – auch Präsenzmelder genannt (bspw. Homematic oder Steinel)


    Mit homekit war es wegen der 10sek Problematik immer murx

    Da bin ich aber sehr verblüfft. Bis heute war ich der Überzeugung, dass diese 10-Sekunden-Duration global durch die HUE-Bridge festgelegt ist und sowohl in HomeKit als auch in der HUE-App bzw. iConnetHUE nicht unterschritten werden kann.

    Beide Sensoren lassen sich gleichzeitig nicht nicht als Auslöser auswählen

    Moin,


    in Drittanbieter-Apps lässt sich dies in deinem Sinne umsetzen. Ich empfehle dazu immer gern die Controller App. Damit lassen sich beliebige Auslöser – dort Startereignis genannt – miteinander kombinieren.

    Nö, ist kein Problem. Es gibt keinerlei Fehlauslösungen seitens des Vibrationssensors an meinem Briefkasten. Funktioniert 100%-ig und war supereinfach zu installieren. Der Clou: auch Zeitungen, die in die unten angebrachte Zeitungsrolle eingelegt werden, werden signalisiert.

    ich hab mir den Sensor mal angeschaut und das sieht echt vielversprechend aus!

    Hab lange nach einer „Art“ Lichtschranke gesucht und bin nie fündig geworden...

    Genau so ging es mir, bis ich auf diese Sensoren gekommen bin, die noch erheblich vielseitiger sind als Lichtschranken. Ein nächstes Projekt wird bspw. ein Sensor, der je nach Abstand verschiedene Automation auslöst – gut um Positionen in Raumbereichen mit unterschiedlichen Schaltautomationen zu versehen. Einmal angefangen mit den Sensoren, sprudeln die Ideen für praktische Anwendungen im SmartHome 8)


    1. betreibst du beide Sensoren am gleichen ESP und wenn ja wie hast du die I2C Adresse bei einem der beiden umgestellt ?

    Ja, alles läuft bislang über 1 ESP. Es gibt eine Library mit Beispielen. U.a. wird da über die Sensor-Interrupt-Kontakte eine Dual-Sensor-Konfiguration im Setup mit separaten Adressen initialisiert. Das funktioniert wunderbar, kostet allerdings 2 zusätzliche (Interrupt-fähige) GPIOs auf dem ESP. Deswegen habe ich den Prototypen mit einem I2C-Multiplexer versehen, über den bis zu 8x I2C-Bauteile an nur 2 GPIOs des ESP verwaltet werden können. Man könnte damit übrigens 8 identische Sensoren pro Multiplexer verwalten, die ihrerseits über eigene Adressen bis zu einer Zahl von 8 an einen einzigen ESP gesteuert werden können (= theoretische 64 Einzelmodule über 2 GPIOs 8|).


    Ich habe das Ganze zur direkten Steuerung am Türrahmen noch mit einem TM1638 versehen. Darüber kann ich alle Messungen sehen, den Threshold für die Zählerschaltung einstellen, die gewünschte Zählfunktion (Nur Raum A, nur Raum B, Raum A + B) und vor allem die bidirektionalen Zähler vollständig kontrollieren, ohne das Ding ständig abzubauen und mit neuen Konfigs am Rechner flashen zu müssen.

    2. hast du dann auf dem ESP immer eine Variable aus Counter laufen, der sich erhöht oder verringert je nachdem in welcher Reihenfolge die Sensoren „unterbrochen“ worden ?

    Das ist etwas tricky über diverse if-Bedingungen gelöst. Sämtliche möglichen Bewegungs-Abläufe habe ich dabei über diverse Variablen durchgespielt bzw. abgebildet. Das hört sich zunächst viel an, ist aber für den eigentlichen Zweck immer noch gut überschaubar und vor allem vom ESP abzuarbeiten. Das jetzt hier an dieser Stelle detailliert zu erklären und aufzulisten, wäre doch etwas aufwändiger. Ich hole das gerne mal nach, wenn das Schätzchen ausgereifter ist. Hier mal einige beispielhafte Auszüge (ich hoffe die sind einigermaßen nachvollziehbar):


    3. Mit welchem Modus betreibst du die Sensoren ?

    Einen speziellen Modus habe ich nicht eingestellt. Da könnte man ggf. noch experimentieren. Nur soviel: Bei dem Zähler ist auf jeden Fall die Sensorgeschwindigkeit wichtiger als die Sensorgenauigkeit. Und das ist, glaube ich, die Default-Einstellung?! :/


    4. und wie überträgst du dann die Daten in dein Smart Home ? Über Mqqt ?

    Über zwei GPIOs werden pro Raumzähler Schaltungen in einen zweiten ESP mit RavenSystem übertragen, in dem ich die Schaltsignale als Belegungssensoren definiert habe, sowie 2 zusätzliche virtuelle Schalter für HomeKit zum De-/Aktivieren der Schaltfunktion(en). Die letztgenannte Schaltmöglichkeit zur Aktivierung pro Raum soll gerne noch durch den Haupt-ESP mitgeschaltet werden. Da wird es im Moment allerdings etwas knapp mit den verfügbaren Wemos D1 Mini GPIOs. Durch die direkte Verkabelung minimiert man weitere Verzögerungen durch bspw. WLAN-Kommunikation, will sagen: eine schnellere Verarbeitung geht vermutlich nur, indem man RavenSystem und Raumzähler in einzigen ESP zusammenfasst. Soweit bin ich allerdings noch nicht. Wie auch immer: Somit ist mein Sensor quasi nativ HomeKit-fähig. ;)


    Der Witz: man kann den zweiten ESP für die native HomeKit-Einbindung auch weglassen und beliebige andere Systeme über entsprechende WLAN-Verfahren/Protokolle mit den Schaltdaten des Haupt-ESP "füttern". Da sollte für jeden etwas dabei sein, ob nun Homebridge, Home Assistant, FHEM whatever…

    Gerrit Da kann ich mich einmal mehr darüber freuen, dass meine Frau mich in Begeisterung in solchen Projekten unterstützt :love:

    Danke dir für den netten Gruß. Auch dir und deiner Frau einen guten Rutsch in’s neue Jahrzehnt!


    PhilippCF Witzig: Ich habe dein Projekt bereits im makesmart.net-Forum mit Interesse verfolgt :thumbup:


    Bei deinem Konzept sind allerdings wieder mehrere "Bremsen" im System. Angefangen mit den vergleichsweise sehr trägen Aqaras bishin zur Sensorauswertung über Node red. Bei mir läuft ALLES im ESP itself – entsprechend ohne Umwege und/oder Weiterleitungen. Die beiden Sensoren tasten derzeit je Millisekunde den Übergangsbereich ab und agieren erst bei Unterschreiten eines frei wählbaren Grenzbereichs. Es gibt somit quasi keine Duration, was sich in schnellen Hin- und Herschaltaktionen < 1 Sekunde positiv bemerkbar macht. Nur HomeKit ist natürlich wieder die Trägheit in Person und kommt bei so schnellen Schaltabläufen nicht hinterher, was für den praktischen Einsatz aber vollkommen ok ist. Des Weiteren ist der Abtastbereich der Sensoren aufgrund der Lasertechnik sehr fokussiert, während herkömmliche Bewegungssensoren einen für den Zweck viel zu hohen Erkennungsbereich haben.


    Probier doch mal solch einen Sensor aus! Bei Kosten von knapp 6,- Euro ist das ein überschaubares Investment. Ich denke du wirst begeistert sein :S


    Thema Stromversorgung: Das stelle ich zunächst hintenan. Entsprechend läuft mein Prototyp über Netzteil. Erst will ich die Grundfunktion optimieren/perfektionieren, dann geht’s weiter mit der Stromversorgung bzw. mit Überlegungen, den Stromverbrauch für einen evtl. möglichen Akkubetrieb zu senken. Es gibt noch viel zu tun, aber der bisherige Stand motiviert mich 8)

    @Typ1er Die Sensoren basieren auf Flugsensoren VL53L0X und können Distanzen bis 2 m messen, sind also auch hervorragend für andere Sensoranwendungen geeignet (Auch dafür existieren bereits Ideen). Aber wer weiß, vielleicht "entdecke" ich noch besser für den Zweck geeignete Sensoren (bspw. den vielversprechenden AK9753). Firmware in dem Sinne gibt es bei den Sensoren und den ESPs nicht. Ich schöpfe aus Standardbibliotheken für die jeweiligen Sensoren und ESPs und flashe per Arduino-App. Das war’s.


    Das Prinzip der autarken Mikrocontroller ist nach meinem Geschmack eine ganz außergewöhnliche Möglichkeit, wirklich maßgeschneiderte Lösungen für das eigene HomeKit/Smarthome zu kreieren – ganz ohne Homebridge, Plugins und andere Hilfskrücken, weswegen ich auch gar nicht verstehe, dass hier – zumindest unter den Bastlern – nicht schon längst ein Arduino-Fieber ausgebrochen ist und im Forum eine eigene Kategorie "ESP8266" eingerichtet wurde. ;) Ich bin da grade erst eingestiegen und sehe bereits jetzt Potential ohne Ende – grade weil zukünftig ja auch von Apple immer mehr "freigegeben" wird, was die Entwicklung eigener Geräte auch für Hobbyisten vermutlich nochmal stark vereinfachen wird. Und an Sensoren und Aktoren gibt es ein schier unüberschaubares Angebot, sowohl was Konfiguration, Präzision als vor allem auch Funktion betrifft.


    Gerrit Genau aus diesem Grund habe ich einen Prototypen platziert, um alle möglichen und unmöglichen Vorgänge und Sonderfälle zu analysieren und schaltungstechnisch nachzubessern. Schon jetzt agiert der bidirektionale Zähler erst, wenn man die Tür bzw. den frei festlegbaren Durchgangsbereich (es muss ja nicht zwingend eine Tür sein) wirklich durchquert hat. Man kann sich also im Türrahmen hin- und herbewegen – wie und aus welchem Grund auch immer – und der Sensor zählt sowohl in die eine oder die andere Richtung erst dann, wenn ein Durchgehen festgestellt wurde, d.h. beide Sensoren müssen in entsprechender Reihenfolge passiert worden sein, ob im Millisekundenbereich oder in mehrminütiger Zeitlupe ist dabei egal.


    Ich habe mich bei meinem Konzept von dem Gedanken getrennt, dass 1 Sensor alles korrekt erkennen und schalten soll. Eine Raumpräsenz ist natürlich nicht nur über ein Durchqueren einer Tür definiert, sondern durch eine beliebige Vielzahl anderer Ereignisse, die sich ihrerseits durch Sensoren abbilden lassen. Kombiniert man bspw. einen Radarsensor, der feinere Bewegungen auch durch Materialien erkennen kann, und lässt alle Sensoren direkt miteinander im Sinne von IoT und vor allem außerhalb von HomeKit kommunizieren, können Sensorergebnisse in der Summe die ggf. fehlinterpretierten Messungen einzelner Sensoren korrigieren. Weiß also mein Masterzähler in der Eingangstür, wieviele Personen sich in der Wohnung aufhalten, kann er sich mit allen beteiligten Zählern per WLAN permanent darüber austauschen, wer grade in welchem Raum welche Zählung vornimmt, sodass sich nicht plötzlich 2 Personen in dem einen Raum und 1 Person im anderen befinden können, wenn der Master nur 2 Personen gesamt registriert hat. Die Radarsensoren überprüfen dann zusätzlich, ob nicht doch in den Räumen mit der Personenzahl 0 Bewegungen festgestellt werden und korrigiert dann diese auf mindestens 1 bei gleichzeitiger Reduktion der Anzahl in den anderen Räumen. Hat man dann auch noch Gyro-Sensoren in diversen Sitzmöbeln und Schlafmöbeln verbaut, wird das Ergebnis immer präziser und die Automationen entsprechend immer zuverlässiger. Im Unterschied zu den mir bekannten Homebridge-Lösungen können die Mikrocontroller intern komplexe Berechnungen und damit quasi beliebige Automationen durchführen. Für HomeKit & Co kommen dann lediglich wahlweise einfache Schaltbefehle, Belegungssensoraktivierungen oder whatever an. Die ganze komplexe "Vorarbeit" übernehmen die Sensoren, wahlweise sogar im eigenen Netzwerk.


    Lange Rede kurzer Sinn: Ich denke es geht auch ohne Chip-Implantat. Außerdem: Geht nicht gibt’s nich 8o

    Genau an einem solchen Sensor auf Basis ESP8266 bastel ich bereits seit einigen Wochen und bin dabei recht weit fortgeschritten. Ein erster Prototyp wurde in einer Durchgangstür installiert und funktioniert soweit recht zuverlässig, allerdings muss ich die einzelnen Bauteile noch weiter optimieren, da es zeitweise sporadische Messabbrüche gibt.


    Nur kurz das Prinzip: Zwei leicht versetzte Entfernungssensoren, die in einem Türrahmen angebracht sind, erkennen durch Laufzeitunterschiede im Millisekundenbereich sowohl die Bewegungsrichtung als auch eine abgeschlossene Durchgangsbewegung. Komplette Durchgänge verschiedener Personen werden wahlweise in beide oder jeweils eine von beiden Richtungen gezählt und können entsprechend beliebige Aktionen auslösen. Sobald ich etwas Ausgereiftes fertiggestellt habe, würde ich das bei Interesse hier vorstellen. Dauert aber noch.


    Es gibt zum Thema neben den genannten käuflichen Lösungen auch eine aus dem Hause Homematic und Weitere, die als sogenannte Präsenzmelder für Büro- und Gastrononieeinrichtungen mitunter mehrere Sensoren für Bewegung, Akustik und Radar miteinander kombinieren (bspw. Steinel)


    Die Technik als Zukunftsmusik zu bezeichnen ist also nicht so ganz korrekt, da die Technik als Solche bereits vorhanden ist, Allerdings setzen sich derartige Technologien nicht im heimischen Smarthome durch, da den allermeisten Anwendern die vergleichsweise günstigen und einfachen Infrarot-Bewegungssensoren für ihre Anforderungen genügen.


    Der von yveslae angesprochene Gesten-Sensor, den ich inzwischen nachgebaut habe, eignet sich leider nicht für die Durchgangszählung. Die Reichweite ist mit wenigen Zentimetern leider viel zu gering. Ggf. wird es aber Nachfolger geben, die im Meterbereich reagieren. Das würde dann auch meine Schaltung extrem vereinfachen.

    Wenn es Problem mit zertifizierten Geräten in einer nativen Umgebung gibt ist Apple natürlich und zu 100% in der Pflicht!

    Ich würde Apple in diesem Falle allerdings eher nur zu 50% in die Pflicht nehmen. Hersteller von zertifizierten HomeKit-Geräten stehen meiner Meinung nach zu mindestens gleichen Teilen in der Pflicht, was sie nach meiner Beobachtung leider eben nicht erfüllen. Die meisten Probleme hatte ich bislang mit Ikea und Philips HUE und tatsächlich die wenigsten mit meinen (bescheidenen) Homebridge-PlugIns. Die Zertifizierung wird ja vermutlich nur einmal mit der Einführung eines neuen Gerätes vollzogen und nicht bei jedem Firmware/software-Update des jeweiligen Herstellers nachgeprüft?! Wie das Prozedere genau abläuft, wäre zumindest mal eine interessante Frage hinsichtlich präziser technischer Vorgaben und vor allem Überprüfungen seitens Apple. Dies, um einmal besser beurteilen zu können, was eine Zertifizierung in Sachen Zuverlässigkeit überhaupt bedeutet.


    Ich persönlich bin mittlerweile davon überzeugt, dass die ungezählten hier und an anderer Stelle beschriebenen, teils exotisch anmutenden HomeKit-Probleme aus einer Summe "unglücklicher" Kombinationen in der jeweiligen technischen Infrastruktur der betreffenden User herrühren. Angefangen vom eingesetzten Router und dessen Konfigurationen, über fehlerhafte Firmware-Updates bishin zu allen möglichen "außerplanmäßigen" Erweiterungen in Form von Homebridge & Co etcpp.


    HomeKit wurde nie für diese Außerplanmäßigkeit konzipiert und ich glaube inzwischen, dass Apple es auch zukünftig nicht ernsthaft dafür weiterentwickeln wird. Allein die Begrenzungen, die die Szenen-/Automationenanzahl und die eindimensional agierenden Steuerzentralen betreffen, lassen stark vermuten, dass HomeKit in erster Linie ein "unkompliziertes" Apple-Feature für grundlegende Automationen denjenigen bieten soll, die ein paar Lampen und Heimgeräte ohne komplizierte Bedingungen und ohne tiefergehendes, technisches Verständnis schalten wollen. Für sogenannte "Poweruser" ist das System allein schon durch seine Intransparenz und ausschließliche Cloudbasierung ohne jegliche Zugriffe auf Setup-Dateien bislang weder gedacht noch geeignet. Ich befürchte, das wird auch in absehbarer Zeit nicht besser.

    SmartHome Hank


    Danach nicht.


    Der Unterschied besteht nach meinem Verständnis darin, dass der Raspbee speziell und ausschließlich am Raspberry verbaut und betrieben werden kann, während der Conbee II auch mit Ubuntu und Win-Rechnern funktioniert. Beides versteht aber ausschließlich Zigbee.