Hi, ich möchte meine schon vorhandenen und funktionsfähigen Bewegungsmelder (HC-SR501 PIR) an FHEM anbinden.
Bisher mache ich das mit einem Python Script.
Folgendes habe ich in FHEM gemacht:
define RPIPin8 RPI_GPIO 14
attr RPIPin8 direction input
attr RPIPin8 interrupt both
define act_on_BewegungGPIO notify RPIPin8 { if ("$EVENT" ne "off") { fhem("setstate status_flur 1;");}}
Per Python Script wird nun auch eine Bewegungs gemeldet.
Dich in FHEM wird der status "status_flur" nicht auf 1 gesetzt.
Habt ihr ne Idee?
Vielen Dank!
Wenn hier keine Antwort gefunden wird, würde ich dir empfehlen das Thema in den Bereich "Einplatinencomputer" zu verschieben. Dort ist laut Maintainter.txt der Maintainer zu RPI_GPIO.
Ändert sich denn der Status des RPIPin8 bei Bewegung, oder klappt das auch schon nicht?
Der Status ist immer "? ? ?".
Bitte keiner Bilder posten, sondern ein "list" des Device machen. Mehr über richtiges Posten von Fehlern etc findest du hier: https://forum.fhem.de/index.php/topic,71806.0.html
Hier die Ausgabe:
Internals:
DEF 14
GPIO_Basedir /sys/class/gpio
NAME RPIPin8
NR 24
RPI_pin 14
STATE ???
TYPE RPI_GPIO
WiringPi_gpio /usr/local/bin/gpio
filehandle
Readings:
Pinlevel:
TIME 2017-05-28 19:29:29
VAL
Fhem:
interfaces switch
Attributes:
direction input
interrupt both
naja, wenn der State ??? ist, dann kann ja auch nix schalten. Also müssen wir erst Mal raus bekommen, wieso der State bei ??? bleibt.
bischen dürftig , deine Beschreibung, was du bisher gemacht hast um Fhem beizubringen die GPIO zu nutzen
die Kurzversion bei jessie Lite bei mir war.
sudo adduser fhem gpio
sudo apt-get install wiringPi
reboot tut not!!!
mit gpio -v
in der shell prüfen , ob wiringPi tut
steht alles in der commandref und Wiki
in deinem fhemlog steht bestimmt auch noch einiges drin an Fehler
Jetzt funktioniert es: "sudo adduser fhem gpio" hat es getan...
Hatte mir die Command-Reg angeschaut... Diesen Punkt aber wohl überlesen :-/
Der Bewegungsmelder wird nun wohl jede Sekunde abgefragt, richtig?
Scheint meinen Raspi ziemlich auszulasten... Kann man da noch irgendwas machen um die Auslastung zu verringern?
Danke!
wieso jede sekunde?
fhem wird nur "aktiv" wenn sich der Eingang ändert. ich kenne den HC-SR501 PIR nicht bezüglich Signal am gpio
ich habe noch attr < > pud_resistor up da bei mir nur low geschalten wird
Bei den Readings sehe ich, dass dort jede Sekunde aktualisiert wird... Hmm aber geht ja eigentlich auch nicht anders, da der Zustand ja überprüft werden muss ob der Melder grad eine "High" Singal schickt...Mein Raspberry ist halt bei einer Dauerauslastung von ca. 70% seit dem...
kann ich nicht bestätigen, weil dann müßte nach deiner Aussage im Eventmonitor die ganze Zeit auch Events von dem Device auftauchen.
Was allerdings stimmt ist, wenn du auf Detail bei dem Device gehst, steht dort immer der aktuelle Pinlevel mit aktueller Uhrzeit drin,
sprich wird abgefragt bei Aufruf der DetailSeite.
Hmm tatsächlich tauchen im Event-Monitor ständig Events von dem Device auf (mehrmals pro Sekunde sogar), bspw.:
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Dblclick: off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Pinlevel: low
2017-05-28 21:04:29 RPI_GPIO RPIPin8 off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Longpress: off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Dblclick: off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Pinlevel: low
2017-05-28 21:04:29 RPI_GPIO RPIPin8 off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Longpress: off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Dblclick: off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Pinlevel: low
2017-05-28 21:04:29 RPI_GPIO RPIPin8 off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Longpress: off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Dblclick: off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Pinlevel: low
2017-05-28 21:04:29 RPI_GPIO RPIPin8 off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Longpress: off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Dblclick: off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Pinlevel: low
2017-05-28 21:04:29 RPI_GPIO RPIPin8 off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Longpress: off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Dblclick: off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Pinlevel: low
2017-05-28 21:04:29 RPI_GPIO RPIPin8 off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Longpress: off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Dblclick: off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Pinlevel: low
2017-05-28 21:04:29 RPI_GPIO RPIPin8 off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Longpress: off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Dblclick: off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Pinlevel: low
2017-05-28 21:04:29 RPI_GPIO RPIPin8 off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Longpress: off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Dblclick: off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Pinlevel: low
2017-05-28 21:04:29 RPI_GPIO RPIPin8 off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Longpress: off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Dblclick: off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Pinlevel: low
2017-05-28 21:04:29 RPI_GPIO RPIPin8 off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Longpress: off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Dblclick: off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Pinlevel: low
2017-05-28 21:04:29 RPI_GPIO RPIPin8 off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Longpress: off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Dblclick: off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Pinlevel: low
2017-05-28 21:04:29 RPI_GPIO RPIPin8 off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Longpress: off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Dblclick: off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Pinlevel: low
2017-05-28 21:04:29 RPI_GPIO RPIPin8 off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Longpress: off
2017-05-28 21:04:29 RPI_GPIO RPIPin8 Dblclick: off
2017-05-28 21:04:30 RPI_GPIO RPIPin8 Pinlevel: low
2017-05-28 21:04:30 RPI_GPIO RPIPin8 off
2017-05-28 21:04:30 RPI_GPIO RPIPin8 Longpress: off
2017-05-28 21:04:30 RPI_GPIO RPIPin8 Dblclick: off
2017-05-28 21:04:30 RPI_GPIO RPIPin8 Pinlevel: low
2017-05-28 21:04:30 RPI_GPIO RPIPin8 off
2017-05-28 21:04:30 RPI_GPIO RPIPin8 Longpress: off
2017-05-28 21:04:30 RPI_GPIO RPIPin8 Dblclick: off
2017-05-28 21:04:30 RPI_GPIO RPIPin8 Pinlevel: low
2017-05-28 21:04:30 RPI_GPIO RPIPin8 off
2017-05-28 21:04:30 RPI_GPIO RPIPin8 Longpress: off
2017-05-28 21:04:30 RPI_GPIO RPIPin8 Dblclick: off
2017-05-28 21:04:30 RPI_GPIO RPIPin8 Pinlevel: low
2017-05-28 21:04:30 RPI_GPIO RPIPin8 off
2017-05-28 21:04:30 RPI_GPIO RPIPin8 Longpress: off
2017-05-28 21:04:30 RPI_GPIO RPIPin8 Dblclick: off
2017-05-28 21:04:30 RPI_GPIO RPIPin8 Pinlevel: low
2017-05-28 21:04:30 RPI_GPIO RPIPin8 off
2017-05-28 21:04:30 RPI_GPIO RPIPin8 Longpress: off
2017-05-28 21:04:30 RPI_GPIO RPIPin8 Dblclick: off
2017-05-28 21:04:30 RPI_GPIO RPIPin8 Pinlevel: low
2017-05-28 21:04:30 RPI_GPIO RPIPin8 off
2017-05-28 21:04:30 RPI_GPIO RPIPin8 Longpress: off
2017-05-28 21:04:30 RPI_GPIO RPIPin8 Dblclick: off
2017-05-28 21:04:30 RPI_GPIO RPIPin8 Pinlevel: low
2017-05-28 21:04:30 RPI_GPIO RPIPin8 off
2017-05-28 21:04:30 RPI_GPIO RPIPin8 Longpress: off
2017-05-28 21:04:30 RPI_GPIO RPIPin8 Dblclick: off
2017-05-28 21:04:30 RPI_GPIO RPIPin8 Pinlevel: low
2017-05-28 21:04:30 RPI_GPIO RPIPin8 off
2017-05-28 21:04:30 RPI_GPIO RPIPin8 Longpress: off
2017-05-28 21:04:30 CUL_HM Wz.SteckDMess.PC CMDs_done
2017-05-28 21:04:30 dummy Verbraucher.PC 169.11
2017-05-28 21:04:30 CUL_HM Wz.SteckDMess.PC_Pwr b
Scheinbar wird das "Low" Signal dauerhaft geschickt...
Ich habe gerade mal das Datenblatt runtergeladen, wie hast du denn den Jumper gesetzt , ich hoffe mal auf single Trigger
Jup, hab ich grad noch einmal geprüft... Ist auf "Single" gestellt.
Wenn ich den interrupt auf "rising" stelle, dann kommt auch nur ein Signal/Event wenn eine Bewegung erkannt wurde.
Wenn ich den interrupt auf "falling" stelle, dann kommt ein Event (wie oben) mehrmals die Sekunde...
So, ich habe es nun soweit unter Kontrolle.
Für den Bewegungsmelder habe ich "event-on-change-reading: state" gesetzt.
Jetzt bekomme ich nur noch "on" oder "off" states als event und nicht mehr ein Dauer "low".
Ein kleines Problem habe ich nun noch:
Ich steure eine Hue Lampe nun bei Bewegung mittels DOIF:
([RPIPin8:"on"]) (set HUEDevice8 on-for-timer 15)
Das funktioniert auch einwandfrei. Nur leider liefert der Bewegungsmelder des öfteren "Fehlalarme".
Dies Erkenne ich daran, dass das "on" bzw. "high" Signal nur 1 Sekunde besteht und dann direkt auf "off/low" geschaltet wird.
Bei einer richtigen Bewegung bleibt das "on" Signal" für ca. 5 Sekunden bestehen bevor es auf "low" geht.
(Wie) Kann ich dem DOIF nun beibringen, dass erst noch 2 Sekunden gewartet werden soll (um auszuschließen, dass es ein Fehlalarm ist) und dann erst den Befehl zum Schalten der Lampe gibt? Nach den 2 Sekunden müsste also noch mal geprüft werden ob das signal auf "on" steht...
Danke
mit dem wait attr. Einfach mal in die CommandRef zu DOIF schauen, ist lang, aber so ziemlich alles drin ;)
DOIF kennt ein Attribut "wait" siehe commandref
(erst nach eingestellter Wartezeit wird geschaltet, wenn Bedingungen noch erfüllt sind)...
Zitat von: gamauf am 31 Mai 2017, 09:52:31
DOIF kennt ein Attribut "wait" siehe commandref
(erst nach eingestellter Wartezeit wird geschaltet, wenn Bedingungen noch erfüllt sind)...
Hi, danke für den Tipp, aber das scheint leider nicht zu funktionieren.
Im Event-Log wird ganz klar ein "on" und "off" Signal innerhalb einer Sekunde geliefert:
2017-06-08 18:25:24 RPI_GPIO RPIPin8 on
2017-06-08 18:25:24 RPI_GPIO RPIPin8 off
Und trotz einer "wait" von "2" geht die Lampe an.
Hier noch mal ein List meiner "DOIF":
Internals:
DEF ([RPIPin8:"on"]) (set HUEDevice8 on-for-timer 60)
NAME motion_flur
NR 37
NTFY_ORDER 50-motion_flur
STATE cmd_1
TYPE DOIF
Readings:
2017-06-08 18:25:24 Device RPIPin8
2017-06-08 18:25:26 cmd 1
2017-06-08 18:25:26 cmd_event RPIPin8
2017-06-08 18:25:26 cmd_nr 1
2017-06-08 18:25:24 e_RPIPin8_events off
2017-06-08 18:25:26 state cmd_1
2017-06-08 18:25:25 wait_timer no timer
Condition:
0 EventDoIf('RPIPin8',$hash,'on',1)
Devices:
0 RPIPin8
all RPIPin8
Do:
0:
0 set HUEDevice8 on-for-timer 60
1:
Helper:
event on
globalinit 1
last_timer 0
sleepdevice RPIPin8
sleepsubtimer -1
sleeptimer -1
timerdev RPIPin8
timerevent on
triggerDev RPIPin8
timerevents:
on
timereventsState:
state: on
triggerEvents:
on
triggerEventsState:
state: on
Internals:
Itimer:
Readings:
Regexp:
0:
All:
State:
State:
Trigger:
all RPIPin8
Attributes:
do resetwait
wait 2
Eine Idee?
Danke!
Commandref nochmals lesen. Abschnitt DOIF Attribute.
Lösung selbst erarbeiten, dann hier posten...
Ciao, -MN
Zitat von: Morgennebel am 08 Juni 2017, 20:34:33
Commandref nochmals lesen. Abschnitt DOIF Attribute.
Lösung selbst erarbeiten, dann hier posten...
Ciao, -MN
Auf die Idee bin ich auch schon gekommen... Aber finde wohl nicht den richtigen Command.
"wait" möchte einfach nicht funktionieren... Viel falsch kann man da ja nicht machen.
Anhand dieses Beispiels habe ich mein DOIF ja auch gemacht:
Anwendungsbeispiel: Benachrichtigung "Waschmaschine fertig", wenn Verbrauch mindestens 5 Minuten unter 2 Watt (Perl-Code wird in geschweifte Klammern gesetzt):
define di_washer DOIF ([power:watt]<2) ({system("wmail washer finished")})
attr di_washer wait 300
Meins:
define motion_flur DOIF ([RPIPin8:"on"]) (set HUEDevice8 on-for-timer 60)
attr motion_flur wait 2
Du weißt es anscheint und möchtest es nicht sagen, damit ich es mir erarbeite?! :o
Glaube du hast einen Denkfehler. Du fragst mit deinem DOIF den Status von "RPIPin8" und schaltest "HUEDevice8". Diese Schaltung wird mit wait verzögert und nicht die Abfrage von "RPIPin8".
Lies das hier noch mal: https://fhem.de/commandref_DE.html#DOIF_do_resetwait
und dann schau Dir noch mal genau Dein list bzw. Dein Gerät an.
Ja, ich bin für Wissenzuwachs für lernen und aufmerksam lesen. Ein paar Hinweise, um die Richtung zu finden, sind natürlich in Ordnung...
Ciao, -MN