PIR / GPIO - funktioniert mit Python Skript in FHEM ist PINLEVEL immer High

skynet · 03 März 2018, 20:58:27

Hallo zusammen,

habe einen kleinen PIR Sensor nach dieser Anleitung an meinem PI Zero.
Anleitung: http://coldcorner.de/2017/09/08/pir-motion-sensor-in-fhem-integrieren/

Erkennung über Python Skript an PIN7 läuft super.

Zitat2018-03-03 20:52:10.999456: Sensor initialisieren ...
2018-03-03 20:52:11.007419: Fertig! Warte auf Bewegung...
2018-03-03 20:52:12.729717: Bewegung erkannt!
2018-03-03 20:52:15.355236: Fertig! Warte auf Bewegung...
2018-03-03 20:52:23.045817: Bewegung erkannt!
2018-03-03 20:52:25.680320: Fertig! Warte auf Bewegung...
2018-03-03 20:52:31.317890: Bewegung erkannt!
2018-03-03 20:52:33.944324: Fertig! Warte auf Bewegung...
2018-03-03 20:52:41.036987: Bewegung erkannt!
2018-03-03 20:52:43.663004: Fertig! Warte auf Bewegung...
2018-03-03 20:52:49.165919: Bewegung erkannt!
2018-03-03 20:52:51.788713: Fertig! Warte auf Bewegung...
2018-03-03 20:52:57.269427: Bewegung erkannt!
2018-03-03 20:52:59.903733: Fertig! Warte auf Bewegung...
2018-03-03 20:53:05.507325: Bewegung erkannt!

Dann wollte ich es in FHEM integrieren.
Auch nach obiger Anleitung.
Das PIN-Level verbleibt auf HIGH.
Das Reading PIN-Level wird zwar ab und zu aktualisiert aber nicht passend zur "Bewegung" ?

GPIOs schalten etc. klappt -> FHEM ist auch in der entsprechenden Gruppe.

Was mache ich falsch ?
Liegt es am Zero ?

klausw · 03 März 2018, 23:51:38

Die Konfiguration wäre hilfreich.
Vermutlich hast du das Attribut interrupt auf high oder low gesetzt. In diesem Fall wird nur bei der entsprechenden Flanke getriggert Daher ändert sich der Wert auch nicht . Das müsstest du aber der Änderung der Uhrzeit hinter den Readings erkennen.
Mit notifys kannst du darauf allerdings reagieren. Mit interrupt auf both sollte sich das Reading passend zum Gpio Pegel verhalten.

skynet · 04 März 2018, 11:00:51

Nein, ich habe nach Musterkonfig auf both gesetzt.
Wenn ich den PIN 7 manuell abfrage ist der State auch immer entsprechend "Erkennung".
In FHEM immer auf HIGH ...

Code Auswählen

defmod rpi_PIR RPI_GPIO 7
attr rpi_PIR direction input
attr rpi_PIR interrupt both
attr rpi_PIR toggletostate yes

setstate rpi_PIR on
setstate rpi_PIR 2018-03-04 11:00:18 Pinlevel high
setstate rpi_PIR 2018-03-03 21:41:21 state on

Frank_Huber · 04 März 2018, 11:08:31

setz mal nen pull down Widerstand.

kannst bei installiertem WiringPI per Attribut setzen.
Ansonsten versuchsweise nen echten Widerstand einklemmen.

skynet · 04 März 2018, 11:21:19

Habe gerade mal auf PIN 11 gewechselt. Da bleibt es in FHEM immer auf LOW

Wenn ich gpio readall mache geht er bei Erkennung auf 1 ...

PUD_RESISTOR - Alle 3 Varianten getestet -> Keine Statusänderung ...

Frank_Huber · 04 März 2018, 11:23:50

ZitatPUD_RESISTOR - Alle 3 Varianten getestet -> Keine Statusänderung ...

WiringPI installiert und Funktionsbereit?

Teste doch mal mit einem externen Pull down...

skynet · 04 März 2018, 11:34:21

WiringPI ist drauf.
Gerade mal auf meinen TEST Raspberry 3 ausgewichen.
Da das gleiche.

Was ich nicht verstehe warum es nur in FHEM nicht korrekt angezeigt wird.
In der Konsole bei direkter Abfrage wird der Status sauber gewechselt.

Da kann doch kein externer Pull down helfen ?

Wenn es auf OS-Ebene klappt nur FHEM erkennt den Status-Wechsel nicht, oder ?

Frank_Huber · 04 März 2018, 11:37:28

Das stimmt auch wieder.
Blockiert das externe Script den gpio für fhem?
Versuch es doch mal ohne das ganze externe gescripte.

Nur Pir - gpio - fhem.

Mit dem Handy online, daher kurz gefasst...

skynet · 04 März 2018, 11:41:21

Ja habe ich. Skript läuft nicht.
Auf dem Zero habe ich sogar eine Clean Install.

Raspian / FHEM / WiringPI -> Dann in FHEM nahezu nur das aktiv.

In der Konsole checke ich aktuell per gpio readall nur ob er den State wechselt.
Da macht er es.
In FHEM nicht

FHEM ist auf dem aktuellen Stand ..
FHEM ist auch in der Gruppe GPIO - Einen Output aus FHEM kann ich schalten ...

Frank_Huber · 04 März 2018, 12:23:33

Dann würde ich vermuten dass fhem die gpio nicht lesen kann.
Steht was im fhem log?
Kannst ja manuell den gpio lesen und dann ins log schauen.

Zuerst jetzt das ganze mit nem jumperkabel weitermachen.
Per Attribut pull down setzen.

Wenn fhem dann den gpio (per jumper) sofort erkennt kannst mit dem Pir weitermachen.

Wiki zu rpi_gpio hast gelesen?

Mit dem Handy online, daher kurz gefasst...

klausw · 04 März 2018, 13:00:26

Sehr seltsam, FHEM greift quasi direkt über das System auf den Gpio zu. Passt den die Gpio Nummer? Wiringpi, Pinnummer und Gpionummer sind unterschiedlich

skynet · 04 März 2018, 16:41:38

@klausw -> Ich nutze die "PINs" -> Also Hardware-Adressierung ? Falsch ?
Im FHEM auch (Acticity) LOG ist nichts zu sehen ... -> Nur wenn ich manuell speichere ...
Habe auch um sicherzugehen mit PIN7 = GPIO7 getestet.

Komisch ist, an einem GPIO ist er immer High am anderen immer LOW - Beide sind sauber auf Input eingestellt ?!

@Frank
Wiki habe ich gelesen - ja
Was meinst du hiermit ? -> "Zuerst jetzt das ganze mit nem jumperkabel weitermachen."

klausw · 04 März 2018, 16:50:03

Bei Fehlern sollte was im log zu sehen sein.
Pin 7 ist GPIO4
https://goo.gl/images/bLjqFp
Der funktioniert z. B. nicht wenn 1wire aktiviert ist

Frank_Huber · 04 März 2018, 16:59:31

Zitat von: skynet am 04 März 2018, 16:41:38
@Frank
Wiki habe ich gelesen - ja
Was meinst du hiermit ? -> "Zuerst jetzt das ganze mit nem jumperkabel weitermachen."

https://www.google.de/search?q=jumperkabel

Denke mittlerweile aber dass du schlicht den falschen gpio definiert hast.
Such dir mal nen pinout des raspberry, dann hast die Zuordnung von pin zu gpio.

Mit dem Handy online, daher kurz gefasst...

skynet · 04 März 2018, 17:21:03

Ich bin direkt mit dem PIR dran - Jumperkabel

Habe gerade mal mit PIN 11 getestet. - Das wäre ja dann nach dieser Logik GPIO0 - Korrekt ?

Habe alle 3 möglichen Varianten getestet ...

Definiert als GPIO 17 nix - Als GPIO 0 nix - Als GPIO 11 - Nix.
Funktionieren tut es mit "readall" weiterhin ...

| 17 | 0 | GPIO. 0 | IN | 1 | 11

Logfile weiterhin leer