Funk Bewegungsmelder

[king-crash]

Hallo,

ich bin auf der Suche nach einem Funk Bewegungsmelder oder Reflexlichtschranke, die ich mit einem Debian auslesen kann. Reichweite sollte ca 8m sein.
Kennt da jemand ein Produkt?

Grüße

[heisenberg]

Ich verstehe auf Anhieb nicht, ob da irgendwas fertiges dabei ist, oder ob man da überall basteln muss:

https://templates.blakadder.com/sensors.html

----------------

Das hier ...

sonoff pir2 bewegungsmelder wireless

... ist ein 433 MHz-Bewegungsmelder. Damit man von dort aus noch ins WLAN kommt braucht es z. B. eine RF Bridge wie diese hier:

Sonoff RF BridgeR2 WiFi Smart Hub 433MHz Funk

Ich habe das nur kurz zusammengegoogelt. Ich hatte davon nix im Einsatz. Ich habe bisher nur ein bisschen mit meiner Tasmota-Steckdose gespielt. Hier mein Bericht zu der Tasmota-Geschichte: viewtopic.php?t=187599

----------------

Ansonsten könnte ich mir vorstellen, dass über Zigbee da auch was geht. Bewegungsmelder gibt es da wohl einige.

Edit: Links entfernt. Nur Suchbegriffe gelassen.

[reox]

Shelly hat solche Dinger mit Wifi. Die Shellies haben ein Web Interface mit JSON API - die du auslesen kannst. Außerdem können sie CoAP und MQTT, siehe auch https://shelly-api-docs.shelly.cloud/ge ... lly-motion
So billig wie Zigbee sinds halt nicht, brauchen dafür kein Gateway.

[heisenberg]

Hier nochmal ein paar Webseiten, die diesbezüglich eine Übersicht an Produkten geben:

https://www.rasppishop.de/Smart-Home
https://control-your-home.de/
https://mediarath.de/

[niemand]

Mir fiele bei „Funk Bewegungsmelder[sic!] oder Reflexlichtschranke“ sowas wie diese RCWL-0516 ein – die könnte man über ’nen USB-RS232-Konverter an einen Rechner anschließen; an einen Pi auch direkt an einen GPIO.

[GregorS]

ich bin auf der Suche nach einem Funk Bewegungsmelder oder Reflexlichtschranke, die ich mit einem Debian auslesen kann. Reichweite sollte ca 8m sein.
Kennt da jemand ein Produkt?

Wenn Du eine individuelle Lösung benötigst und ein bisschen Gebastel nicht abschreckt, bist Du mit Deiner Frage im Arduinoforum (https://forum.arduino.cc/) oder bei https://www.mikrocontroller.net/ evtl. besser aufgehoben. Ansonsten wäre es hilfreich, ein bisschen über den Anwendungsfall zu erfahren.

Gruß

Gregor

[king-crash]

Danke für die vielen Hinweise, das Shelly sieht auf den ersten Blick am Einfachsten aus. Basteln wäre rein technisch meine Branche, möchte ich aber aus zeitlichen Gründen und der benötigten Stückzahl (1) nicht.
Wenn ich das auf der Seite https://shelly-api-docs.shelly.cloud/ge ... y-motion-2 richtig lese kann ich per HTTP GET auf "/status" ein JSON auslesen, und bei Bewegung wird "sensor.active" = true.
Werde ich ausprobieren.

[heisenberg]

Nur nebenbei bemerkt:

Per Webrequest direkt kannst Du den Sensor auch mit der Tasmota-Firmware ansteuern. Der Vorteil von dem MQTT-Protokoll und den Alternativen, ist der, dass Du zusätzlich an dem Standort, wo der WLAN-Sensor (z. B.: ZG38C02927) ist, nur einen WLAN-Accesspoint brauchst und keinen Server (aka "Linux-Büchse" oder "Home-Automation-Gateway"). D. h. das Gerät wird einmal konfiguriert und hält dann die Verbindung zu irgend einem Server irgendwo im Internet und ist dann über dieses Relay (z. B. MQTT-Server) steuer- bzw. abfragbar.

[king-crash]

Falls es jemandem hilft, hier ein kleines Skript zum Auslesen:

Code: Alles auswählen

#!/bin/bash

piep()
{
	echo "Alarm"
	speaker-test -t sine -f 500 -b 100000 -l 1 > /dev/null 2>&1
	speaker-test -t sine -f 1000 -b 100000 -l 1 > /dev/null 2>&1
}

while true
do
	JSON=$(curl -s 192.168.1.223/status)
	echo "${JSON}" | jq -r .sensor.motion | grep false > /dev/null
	if [ $? -ne 0 ]
	then
		piep
	else
		echo "Nix"
	fi
	echo "${JSON}" | jq -r .bat
done

[niemand]

Hast du mal geschaut, welche System- und Netzwerklast das verursacht? Wenn’s für dich okay ist, kein Problem – mich würde die Ressourcenverschwendung und die inhärente Unzuverlässigkeit jedoch massiv ärgern.

[king-crash]

Pro Übertragung sind es laut Wireshark mit sämtlichem Protokolloverhead 1636 Bytes. In der Ausgabe von top kann ich es nie erkennen. Es wird ja auch nur ein einfacher HTTP GET ausgeführt. Da ist jetzt auch nichts zu erwarten.
Von Ressourcenverschwendung kann man hier glaube ich nicht sprechen, die CPU wird das kaum merken. Jedenfalls nicht mehr als bei einem MQTT Server anzufragen.
Wo du hier Unzuverlässigkeit vermutest musst du aber bitte erklären.

[heisenberg]

Pro Übertragung sind es laut Wireshark mit sämtlichem Protokolloverhead 1636 Bytes.

MQTT würde hier aber mit push arbeiten, statt mit pull. D. h. 10 x am Tag, wenn der Bewegungsmelder anschlägt leitet der das an den MQTT-Broker weiter und von dort aus an alle Clients, die darauf einen Subscribe haben. Das wären dann ein Paar KiB pro Tag anstatt ein paar KiB pro Sekunde. Ansonsten ist MQTT sehr resourcensparsam ausgelegt, weil die Geräte allesamt eher schwachbrüstig sind.

Aber ca. 2-5 KiB/Sekunde ist schon sehr massiv

MIt der Unzuverlässigkeit vermute ich, dass folgendes gemeint ist:

Mit dem regelmässigen pullen bekommst Du immer nur einen kurzen Schnappschuss des Status des Bewegungssensors. Z. B. alle Sekunde. Wenn der Bewegungsimpuls nur kurz ist, dann kriegst Du das so u. U. nicht mit. Wenn hingegen der Sensor sich bei jeglicher Aktivität meldet, d. h. er sendet jede Bewegungserkennung aktiv zum Broker, dann kann nichts verloren gehen. Ich würde aber schätzen, dass das schon zuverlässig genug ist.

[king-crash]

Verstehe was ihr meint. Der Melder signalisiert mindestens einige Sekunden lang, daher ist das kein Problem.

[niemand]

Pro Übertragung sind es laut Wireshark mit sämtlichem Protokolloverhead 1636 Bytes. […] Von Ressourcenverschwendung kann man hier glaube ich nicht sprechen […]

Je nach Sichtweise. Wie gesagt, wenn’s für dich so in Ordnung ist, ist alles fein.

Mir wär’ das halt ein Dorn im Auge, und ich würde zusehen, dass ich so hinbekomme, dass der Sensor eine Nachricht schickt und ansonsten nur ab und zu ein Keepalive-Paket durchgeht, statt nur durch die Geschwindigkeit des Webservers und die Ausführungsgeschwindigkeit des Scripts auf der gegebenen Maschine gebremst ’ne Endlosschleife zu haben.

Was die Zuverlässigkeit angeht, hat heisenberg schon einen Aspekt genannt. Abgesehen davon hast du auch keine Fehlererkennung und -behandlung. Aber auch hier: wenn’s für dich tut, ist alles fein. Ist auch an dieser Stelle nur meine subjektive Ansicht.

[king-crash]

Wenn du auf Nachricht vom Sensor wartest bleibt ein Ausfallen des Sensors auch unbemerkt. Willst du das bemerken kommst du an beständigem Pollen nicht vorbei, letztlich ist ein Keepalive genau das. Der Vorteil ist nur eine verringerte Meldezeit. Die ist in meinem Fall aber nur ca 1s und daher vernachlässigbar.
Ein Fehlerhandling gibt es für die "Sensor schickt Nachrichten" Variante auch nicht frei Haus. Sondern muss genauso umgesetzt werden.

Für umfangreichere Umgebungen ist MQTT sicherlich das Mittel der Wahl, ggf auch mit Heimautomatisierungssoftware. In meinem Fall Anwendungsfall mit genau einem Sensor und einem PC der diesen auswertet löst es kein Problem, verbessert wenig, ist dafür aber deutlich komplizierter.

[reox]

Danke für die vielen Hinweise, das Shelly sieht auf den ersten Blick am Einfachsten aus. Basteln wäre rein technisch meine Branche, möchte ich aber aus zeitlichen Gründen und der benötigten Stückzahl (1) nicht.
Wenn ich das auf der Seite https://shelly-api-docs.shelly.cloud/ge ... y-motion-2 richtig lese kann ich per HTTP GET auf "/status" ein JSON auslesen, und bei Bewegung wird "sensor.active" = true.
Werde ich ausprobieren.

jein. Also vorab ich hab keinen Bewegungsmelder, was der genau macht kann ich nicht sagen. Aber die Shellies sind hauptsächlich im Sleep Modus. dH du musst sowas wie MQTT oder CoAP verwenden. Polling ist kaum möglich oder sinnvoll.
Die Dinger funktionieren ca so: Wenn ein Signal erkannt wird, wacht der µC auf, schaltet WLAN ein, sendet die Daten und legt sich dann wieder schlafen. Du kannst natürlich auch die API per polling verwenden, aber dazu musst du alle Sleep-Funktionen abdrehen, damit der Shelly dauerhaft online bleibt. Es gibt ein paar Geräte die auch an Netzstrom funktionieren (zB der Shelly H&T) aber selbst der ist nie dauerhaft online (Ich glaube dort kann man es nicht mal weg konfigurieren). Nur die Geräte wie Lampen oder Steckdosen sind wirklich dauerhaft erreichbar.
Weil die Shellies mit WLAN arbeiten und nicht mit Zigbee, sind die Batterien auch schnell leer. Die von den H&T die ich hier habe halten ca 6-12 Monate. Ich hab einen DW2 und das ist ein wahrer Batteriefresser: er braucht 2 Stück und die sind innerhalb von wenigen Monaten leer - und das obwohl der am wenigsten Signale sendet! Es ist also sehr ratsam wenn das Gerät so lange wie möglich schläft - sonst bist nur am Batteriewechseln.
Ich würde sowas auf jeden Fall mit MQTT implementieren - so einen Broker hast ja schnell aufgesetzt.

[niemand]

Wenn du auf Nachricht vom Sensor wartest bleibt ein Ausfallen des Sensors auch unbemerkt. Willst du das bemerken kommst du an beständigem Pollen nicht vorbei, letztlich ist ein Keepalive genau das.

Hm. Nein, das Keepalive ginge bei mir vom Sender aus, und es würde verbindungslos über UDP kommen, wenn ich IP nutzen würde. Es würde einen Bruchteil der Ressourcen deiner Lösung benötigen. Auch wäre es allenfalls dann funktional vergleichbar, wenn du den Sensor zeitlich definiert pollen, und das auch kontrollieren würdest – und die Begrenzung nicht unkontrolliert von den Limits des Systems machen ließest. Das ist ja im Grunde der Punkt, der mich persönlich mit am meisten stören würde: in deinem Script gibt’s diesbezüglich gar keine Steuerung.

Und ja – Fehlerbehandlung wäre in beiden Fällen selbst zu implementieren, das ist von obenstehendem Punkt unabhängig. Du hast halt gar keine – und ich halte sowas für essenziell.

Aber wie bereits mehrfach herausgestellt: wenn es für dich den Job tut, ist damit alles in Ordung. Vielleicht liegt’s bei mir daran, dass ich mich selbst ein wenig mit so funkangebundener, batterie-/akkubetriebener Sensorik beschäftige. Die Funkverbindung ist da in der Regel der teuerste Teil, auf Leistungsbedarf und damit auf die Laufzeit bezogen, und der Zustand der Signalübertragung muss im Grunde immer im Auge behalten werden. Vielleicht ist’s vor dem Hintergrund besser verständlich, warum ich dran rummäkele

[king-crash]

Ich verstehe deine Motivation voll und ganz. Ich möchte das Ding allerdings nur alle paar Tage für kurze Zeit verwenden. Ich wollte demnächst mal wieder Event Horizon schauen und vermeiden, dass eins der Kinder zur Tür rein kommt. Ist noch nicht ganz altersgerecht. Normalerweise bleiben sie problemlos im Bett, aber da wollte ich sichergehen.

Btw ich habe das Skript jetzt mal ca 2 Stunden laufen lassen und der Akku ist immer noch auf 100%. Das scheint trotz allem sehr sparsam zu sein. Hut ab an die Entwickler.

[GregorS]

.. Ich möchte das Ding allerdings nur alle paar Tage für kurze Zeit verwenden. Ich wollte demnächst mal wieder Event Horizon schauen und vermeiden, dass eins der Kinder zur Tür rein kommt. ...

Bei diesem Anforderungsprofil wären mir zuerst ein Schlüssel oder ein (Stolper-)Bildfaden mit Glöckchen eingefallen.

Bin ich noch normal?!

Gregor

[king-crash]

Ich hatte es mit einer Bewegungsgesteuerten Steckdose versucht. Die löst aber sehr unzuverlässig aus.
Wenn ich das Shelly direkt am PC habe kann ich auch automatisiert den mplayer schließen, das erschien mir doch sehr komfortabel. Und den Stolperdraht mit Umlenkrollen quer durch die Bude bis zum Netzstecker spannen um den dann zu ziehen war mir dann doch zu abenteuerlich.

[niemand]

Bin ich noch normal?!

Je nach Alter – SCNR

Mir würde bei der Anforderung heute auch einfach ein Funksensor einfallen – allerdings eben selbstgebaut und handgelötet (wenngleich ich da anstelle des von mir oben angeführten Funksensors einen via Funk angebundenen PIR-Sensor genommen hätte: diese wortwörtlichen Funk-Bewegungsmelder (nach einem Radar-Prinzip) detektieren nämlich durch Wände, was in einer Wohneinheit unpraktisch sein mag).

Wäre mir das Anwendungsszenario bekannt gewesen, hätte ich an der gefundenen Lösung wohl auch nicht rumgemäkelt.

[reox]

Btw ich habe das Skript jetzt mal ca 2 Stunden laufen lassen und der Akku ist immer noch auf 100%. Das scheint trotz allem sehr sparsam zu sein. Hut ab an die Entwickler.

Hat der auch eine CR123A? Mir ist aufgefallen, dass die oft extrem lange 100% anzeigen und dann plötzlich auf <20% fallen.

[king-crash]

Es sind zwei Rundzellen 66x18mm (Länge x Durchmesser) NCR18650BD, die aber in Folie eingewickelt sind. Eine eigene Messung ergibt 4,14V während das Gerät selber "voltage":4.114 anzeigt. Zum jetzigen Zeitpunkt also korrekt. Ich werde das aber beobachten, Danke für den Hinweis.

[niemand]

Also irgendwas zwischen 3 und 6Ah (von parallelgeschalteten Zellen ausgehend). Da kann man natürlich mit dem Strom etwas rumaasen und trotzdem einige Tage Laufzeit bekommen.

Einige meiner Sensoren würden damit allerdings mehrere Jahre durchhalten …

[heisenberg]

Ich habe mir mittlerweile auch einen WiFi-Sensor von Shelly zugelegt: Einen Feuchtigkeitssensor. Bei uns wurden neue Fenster eingebaut und zusätzliche Dämmung ans Haus gepappt. Daneben noch Lüfter, die aufgrund der höheren Dichtigkeit Schimmel vorbeugen sollen.

Wie dem auch sei. Was ich hier zu dem Thread noch beiträgen möchte, sind ein paar Fakten zum Thema Batterie und Shelly Gerät. Die Energiespareinstellungen davon sind sehr extrem. Ich habe mich am Anfang über die schlechte Erreichbarkeit des Gerätes gewundert (ping), bis ich dann irgendwann mal dann doch die Doku dazu gefunden habe.

Wenn der Sensor nur mit Batterie betrieben wird, dann wacht der nur alle 12 Stunden mal auf, gibt seine Werte weiter und schläft dann wieder ein. Unter der Bedingung soll die Batterie dann 1,5 Jahre ausreichend Strom liefern.

Der Sensor kann ansonsten auch MQTT und liefert dann brav dort seine Daten immer ab.

Wenn eine externe Stromversorgung angeschlossen ist, (Adapter muss man dazu kaufen und das habe ich auch) dann ist das Meldeintervall 10 Minuten.

Doku zum Gerät siehe:
https://shelly-api-docs.shelly.cloud/ge ... t-settings