PIR auf Basis Wall switch and HC-SR501

[Waldmensch]

Danke für den Tipp, aber ich habe 3 Accesspoints, die meine Ranch bis in den letzten Winkel ausleuchten. Ich arbeite aussen mit Panel Antennen. Das Problem sind die Supermini PCB Antennen der Sonoff. Das fixe ich aber lieber am Sonoff mit einem Pigtail und einer kleinen RP-SMA Antenne.

Da ich immer ein Problem habe, bei der Installation auf den besten AP zu connecten (alle haben die gleiche SSID) habe ich in meinem GIT eine modifizierte ESPEASY Firmware, die RSSI und BSSID im Setup Wizard mit anzeigt. Zudem ist der Longpulse gefixt. (Longpulse wird bei einem gpio Kommando nicht gelöscht und schlägt nach Ablauf zu)
Findest Du unter Tommy-LSA auf github.


Gesendet von iPhone mit Tapatalk

[Billy]

Den PIR kann man auch mit 3,3V betreiben wenn man die Diode am Eingang nach Vcc überbrückt.
Siehe Bild!

Falls jemand auf den Umbau des Sonoff Basic zum 5V Pin verzichtet.

Ich bin bewusst bei der 5V Variante geblieben um den Störabstand zwischen Sonoff und PIR
im gleichen Gehäuse groß zu halten.

Billy

[MarkusHiba]

Hallo

welchen sonoff Basic habt ihr verwendet?

[Billy]

Hallo

welchen sonoff Basic habt ihr verwendet?

Sonoff Basic ist dieser
https://www.itead.cc/sonoff-wifi-wireless-switch.html

[Reinhart]

@Billy
Danke für die Info wegen der 3,3V am PIR.

@MarkusHiba
den normalen Sonoff Switch, musst aber im Sketch die "Wall" aktivieren, aber im richtigen Abschnitt "Sonoff" und nicht im Electro Dragon.

Code Auswählen Erweitern

  * Wall switch and HC-SR501
\*-------------------------------------------------------------------------------------------*/
  #define SWITCH_PIN           14           // GPIO 14 = Standard wall switch to Gnd (Sonoff_TH10A(16A), Sonoff SV)
  #define SWITCH_MODE          TOGGLE       // [SwitchMode] TOGGLE, FOLLOW, FOLLOW_INV, PUSHBUTTON or PUSHBUTTON_INV (the wall switch state)
  #define USE_WALL_SWITCH                   // Enable the use of a standard wall switch to control the relay

LG

[Billy]

@Reinhart

Weißt Du was man mit den commands
PowerRetain on und PowerRetain off

anfangen kann bzw. für was die gut sind?
Mir ist das nicht ganz klar.

Billy

[Reinhart]

@Billy

so richtig schlau bin ich mit PowerRetain auch noch nicht geworden, bzw. kann ich das Problem nicht nachvollziehen.
Es geht dabei um einen definierte Einschaltzustandsmeldung nach erstmaligen Netzspannung ein. Diese soll angeblich nicht gekommen sein und darum wurde PowerRetain (ab Version 3.0.0) eingeführt.

https://github.com/arendst/Sonoff-MQTT-OTA-Arduino/issues/126

Code Auswählen Erweitern

00:00:06 MQTT: Connected
00:00:06 MQTT: tele/sonoff_sw3/INFO = Sonoff 8266 module version 3.1.5, FallbackTopic DVES_E89B40, GroupTopic sonoffs
00:00:06 MQTT: tele/sonoff_sw3/INFO = Webserver active for Admin on sonoff_sw3-6976 with IP address 10.0.0.121
00:00:07 MQTT: tele/sonoff_sw3/POWER = ON (retained)
12:38:29 MQTT: tele/sonoff_sw3/POWER = ON
12:38:29 MQTT: tele/sonoff_sw3/UPTIME = 0
12:38:29 MQTT: tele/sonoff_sw3/AP = 1
12:38:29 MQTT: tele/sonoff_sw3/SSID = Pergola
12:38:29 MQTT: tele/sonoff_sw3/RSSI = 88
12:38:29 MQTT: tele/sonoff_sw3/TIME = 2017-01-04T12:38:29
12:43:29 MQTT: tele/sonoff_sw3/POWER = ON
12:43:29 MQTT: tele/sonoff_sw3/UPTIME = 0

bei mir sieht aber der Netzspannung Ein Vorgang so aus, POWER ON kommt sofort nach dem retained (noch vor NTP), also kein Unterschied.

Da ab Version 3.0.0, ohnehin einige Änderungen betreffend der Prefix stat, tele und cmnd durchgeführt wurden, haben bei einem Switch die Statusmeldungen nach dem Schaltvorgang ja nicht mehr funktioniert und somit funktionierten alle Wiki Beispiele nicht mehr. Bei einem Schaltvorgang aus Fhem wurde dann der Schalter erst eingefärbt wenn die Telemetriedaten im Zyklus eingetroffen sind, also eine Zeit später.

Es geht dabei

Code Auswählen Erweitern

subscribeReading_Power
um das subscribeReading_Power, welches einmal über tele und einmal über stat kommt aber ein und dasselbe ist. Ebenso wurde ja "POWER" eingeführt, aber "LIGHT" doch noch teilweise unterstützt.

Code Auswählen Erweitern

#define SUB_PREFIX             "cmnd"       // Sonoff devices subscribe to:- SUB_PREFIX/MQTT_TOPIC and SUB_PREFIX/MQTT_GRPTOPIC
#define PUB_PREFIX             "tele"       // Sonoff devices publish to:- PUB_PREFIX/MQTT_TOPIC
#define PUB_PREFIX2            "tele"       // Sonoff devices publish telemetry data to:- PUB_PREFIX2/MQTT_TOPIC/UPTIME, POWER/LIGHT and TIME

Ich habe daher anstatt des "stat" Prefix bei mir nun alles auf "tele" Prefix umgestellt. Prefix und Prefix2 ist also gleich. Mir ist das eigentlich egal ob das eine Statusmeldung oder Telemetriedaten sind. Einen genauen Unterschied gibt es ja eigentlich gar nicht, da beides einfach nur "Meldungen" sind. Die einen halt spontan (stat), die anderen im Zyklus (tele). Durch diese Maßnahme gibt es auch kein Einschaltproblem und bei einem Schaltvorgang werden auch die Schalter sofort korrekt angezeigt. In Fhem hast du sonst das Problem, das ein und dieselben Daten einmal mit "stat" und einmal mit "tele" kommen und das funktioniert so nicht. Ich habe dies auch im Wiki nun so beschrieben und alle Beispiele korrigiert.

Kennst du eine Situation wo du gezielt einen "stat" Prefix benötigst? ESPEASY hat das ja auch nicht sondern sendet einfach die Topic+Daten.

so ein typischer Sonoff Switch schaut bei mir nun ab Version 3.0.0 so aus, funktioniert aber nur wen der Source (tele anstatt stat) korrigiert wurde.

Code Auswählen Erweitern

define Sonoff_Sw3 MQTT_DEVICE
attr Sonoff_Sw3 IODev myBroker
attr Sonoff_Sw3 alias Sonoff Test
attr Sonoff_Sw3 devStateIcon on:rc_GREEN:off off:rc_RED:on
attr Sonoff_Sw3 eventMap ON:on OFF:off ON:Ein OFF:Aus
attr Sonoff_Sw3 group Test
attr Sonoff_Sw3 icon light_ceiling
attr Sonoff_Sw3 publishSet ON OFF cmnd/sonoff_sw3/1/POWER/set
attr Sonoff_Sw3 room Licht
attr Sonoff_Sw3 stateFormat Power
attr Sonoff_Sw3 subscribeReading_Power tele/sonoff_sw3/POWER
attr Sonoff_Sw3 subscribeReading_state cmnd/sonoff_sw3/1/POWER/set
attr Sonoff_Sw3 webCmd Ein:Aus

LG

[Billy]

@Billy

so richtig schlau bin ich mit PowerRetain auch noch nicht geworden, bzw. kann ich das Problem nicht nachvollziehen.
Es geht dabei um einen definierte Einschaltzustandsmeldung nach erstmaligen Netzspannung ein. Diese soll angeblich nicht gekommen sein und darum wurde PowerRetain (ab Version 3.0.0) eingeführt.

@Reinhart
Na dann bin ich ja beruhigt wenn du da auch nicht schlauer bist.

Ich habe bei mir die Version 3.1.6 am Laufen. Und wie folgt am Beispiel Sonoff_2 eingebunden.

Code Auswählen Erweitern

# ------------- Sonoff_2 mit Bewegungsmelder ---------------
define Sonoff_2 MQTT_DEVICE
attr Sonoff_2 IODev Broker_BB17
attr Sonoff_2 eventMap ON:on OFF:off
attr Sonoff_2 group Sonoff
attr Sonoff_2 icon hue_filled_br30
attr Sonoff_2 publishSet ON OFF cmnd/sonoff_2/1/POWER/set
attr Sonoff_2 room MQTT
attr Sonoff_2 stateFormat Licht
attr Sonoff_2 subscribeReading_Licht stat/sonoff_2/POWER
attr Sonoff_2 subscribeReading_state cmnd/sonoff_2/1/POWER/set
attr Sonoff_2 webCmd :

Mit command BUTTONTOPIC = Alarm_SO2 habe ich denWall switch GPIO14 vom Sonoff entkoppelt und damit
sendet der Bewegungsmelder direkt an FHEM --> Motion_2 MQTT_DEVICE

Code Auswählen Erweitern

# ------------------ Motion_2 MQTT_DEVICE -----------------

define Motion_2 MQTT_DEVICE
attr Motion_2 IODev Broker_BB17
attr Motion_2 devStateIcon on:on-for-timer off:off
attr Motion_2 eventMap ON:on OFF:off
attr Motion_2 group Sonoff
attr Motion_2 icon people_sensor
attr Motion_2 room MQTT
attr Motion_2 stateFormat Alarm
attr Motion_2 subscribeReading_Alarm cmnd/Alarm_SO2/POWER

Ein Doif verknüpft das ganze mit Tag_Nacht:twilight_weather um dann über Fhem MQTT
den Sonoff Power und damit das Licht/Strahler bei Bewegungsalarm in Abhängigkeit der Helligkeit zu schalten.

Code Auswählen Erweitern

# ------------------ DoIf zur Motion Abfrage -----------------
define di_Sonoff_2_Alarm DOIF ([Motion_2:"on"] and [Tag_Nacht:twilight_weather] < 35) (set Sonoff_2 on) DOELSEIF ([Motion_2:"off"] and [Tag_Nacht:twilight_weather] < 35) (set Sonoff_2 off)
attr di_Sonoff_2_Alarm comment Abhängig von Helligkeitssensor wird nachts,\
bei Bewegung das Licht eingeschaltet!
attr di_Sonoff_2_Alarm group Sonoff
attr di_Sonoff_2_Alarm room MQTT

Meine derzeit 3 Bewegungsmelder sind per Sonoffs Group noch zusammengefasst und können im kritischen Alarmfall z.B.
gemeinsam im Blinkmodus geschaltet werden.

Code Auswählen Erweitern

# ------------------------ Sonoffs Group ----------------------
define Sonoffs MQTT_DEVICE
attr Sonoffs IODev Broker_BB17
attr Sonoffs eventMap ON:on OFF:off
attr Sonoffs group Sonoff
attr Sonoffs icon hue_filled_br30
attr Sonoffs publishSet ON OFF cmnd/sonoffs/1/POWER/set
attr Sonoffs room MQTT
attr Sonoffs stateFormat state
attr Sonoffs subscribeReading_Licht stat/sonoffs/1/POWER
attr Sonoffs subscribeReading_state cmnd/sonoffs/1/POWER/set

In Anlage die FHEM Übersicht!

Billy

[Reinhart]

Danke Billy für die ausführliche Information!

Ich habe jetzt auch gesehen, dass mit der 3.1.6 auch die Topic "stat" wieder tadellos funktioniert (so wie früher).

Besonders gut gefällt mir die Lösung mit Buttontopic, weil dann zusätzliche Verknüpfungen wie Helligkeit etc. wieder möglich sind. Ist dann eigentlich im Sketch die Aktivierung von Wall Switch noch erforderlich, oder benötigt Buttontopic den auch?

Was mich noch interessiert, wie steuerst du das Licht wenn Fhem ausfällt? Gibt es hier eine Möglichkeit das unabhängig davon am Sonoff noch einzuschalten (autark)? Den internen Taster auf einen externen Taster führen oder so.

LG

[Billy]

@Reinhart

Ist dann eigentlich im Sketch die Aktivierung von Wall Switch noch erforderlich, oder benötigt Buttontopic den auch?

Ja, die Aktivierung von Wall Switch ist nötig.

Was mich noch interessiert, wie steuerst du das Licht wenn Fhem ausfällt? Gibt es hier eine Möglichkeit das unabhängig davon am Sonoff noch einzuschalten (autark)? Den internen Taster auf einen externen Taster führen oder so.

1. Bei mir ist FHEM noch nie ausgefllen, die BBB's laufen seit über 3 Jahren durch.
2. Ich würde nicht den internen Taster auf einen externen Taster führen  sondern den Wall Switch parallel
zum Bewegungsmelder auf einen externen Taster führen.

Übrigens bin ich nach wie vor der Meinung, du solltest das Thema Sonoff Familie mit MQTT in FHEM einbinden
im Bereich "    FHEM Forum »    FHEM - Hausautomations-Systeme »    Sonstige Systeme "
mit Verweis auf dein WIKI eröffnen.
Wer schaut schon in die Bastelecke um z.B. nach einem WIFI Schalter oder WIFI Steckdose etc. zu suchen.
Ich habe übrigens auch das ROBONECT Modul im Einsatz.

LG Billy

[Reinhart]

Danke für die Info, der Wall Switch ist mir jetzt so weit klar.

Ich habe mir jetzt das Thema Prefix und stat nochmals genauer angesehen. Das Problem mit dem "stat" ist nach wie vor, dass nur Statusmeldungen in Fhem registriert werden und das gefällt mir nicht ganz, weil Fhem dann trotz der zyklischen (tele) Meldungen nicht mehr mitbekommt dass sich der Status geändert hat wenn es einmal während einer Statusänderung am Sonoff ausgefallen ist (bei einem Neustart durch Updates etc.).

Code Auswählen Erweitern

12:06:54 MQTT: tele/sonoff_sw3/TIME = 2017-01-05T12:06:54
12:08:19 MQTT: stat/sonoff_sw3/POWER = ON
12:11:30 MQTT: stat/sonoff_sw3/POWER = OFF
12:11:54 MQTT: tele/sonoff_sw3/POWER = OFF
hier um 12:11:30 habe ich Fhem neu gestartet wegen Updates und zeitgleich Power off am Sonoff ausgeführt. 24 Sekunden später würden die Telemetriedaten melden, dass der Status off ist, aber Fhem reagiert ja nur auf "stat" und bekommt das nicht mehr mit und hat immer noch "ON" Anzeige obwohl der der Switch "Off" ist.

Deshalb bleib ich bei meiner Variante und mache die Statusmeldungen zu Telemetriemeldungen, dann gibt es diesen Fehler nicht. Zugegeben, es ist schon etwas weit hergeholt und beim nächsten Umschaltvorgang würde sich das wieder synchronisieren, aber wenn ich es schon im Vorfeld vermeiden kann ist es mir persönlich lieber.

Ja, Robonect ist eine tolle Sache und ebenso mit esp8266, noch dazu das man es auch in Fhem einbinden kann. Bin schon auf die nächste Version gespannt, wenn bei den Vierradmodellen auch GPS zur Auswertung unterstützt wird.

Wegen der Platzierung der Themen, solange gebastelt wird passt es schon hier und das Wiki ist ohnehin gut besucht, aber man kann es einmal so machen wie du vorschlägst.
LG

[Billy]

Danke für die Info, der Wall Switch ist mir jetzt so weit klar.

Gern geschehen.

hier um 12:11:30 habe ich Fhem neu gestartet wegen Updates und zeitgleich Power off am Sonoff ausgeführt. 24 Sekunden später würden die Telemetriedaten melden, dass der Status off ist, aber Fhem reagiert ja nur auf "stat" und bekommt das nicht mehr mit und hat immer noch "ON" Anzeige obwohl der der Switch "Off" ist.
Deshalb bleib ich bei meiner Variante und mache die Statusmeldungen zu Telemetriemeldungen, dann gibt es diesen Fehler nicht. Zugegeben, es ist schon etwas weit hergeholt und beim nächsten Umschaltvorgang würde sich das wieder synchronisieren, aber wenn ich es schon im Vorfeld vermeiden kann ist es mir persönlich lieber.

Auf jeden Fall überlegenswert! Spricht für die Flexibilität von MQTT.

Ich habe mir inzwischen zur Einstellung des Puls-Delay gedanken gemacht. Beim HC-SR501 ist das ja doch frickelig.
Ich habe für mich eine bessere Lösung gefunden.
Ich stelle alle HC-SR501 auf die kleinste Pulsweite von ca. 5-10Sec ein. (Poti ganz links zum Anschlag)
Das eigentliche Delay kommt dann über das Command PulseTime hier beschrieben!
https://github.com/arendst/Sonoff-MQTT-OTA-Arduino/wiki/Commands

z.B: PulseTime 160 --> 60s Einschaltdauer! PulseTime 220 --> 120s Einschaltdauer!

Das doif di_Sonoff_2_Alarm verkürzt sich, da über die motion nur noch eingeschaltet wird.

Code Auswählen Erweitern

([Motion_2:"on"]) (set Sonoff_2 on)
Das Ausschalten des Strahlers erfolgt jetzt nach der mit  PulseTime eingestellten Zeit.
d.h. Das Delay des Bewegungsmelders kann jederzeit über das WEB und/oder FHEM auf eine neue Wuschzeit eingestellt werden.

Weitere Motion Meldungen innerhalb der  PulseTime verlängern die Einschaltzeit des Strahlers.
Das ist für mich die optimale Lösung
Billy

[Reinhart]

wie man sieht ist dieses Thema sehr ausbaufähig und du testest zum Glück auch sehr viel.

Ich habe den Beitrag nun ins Wiki gestellt, vielleicht kannst du einmal darüber schauen, da ja der Beitrag mehr oder weniger von dir ist und ich alles ungetestet geschrieben habe.

https://wiki.fhem.de/wiki/Sonoff#Sonoff_Switch_mit_Bewegungsmelder_HC-SR501

LG

[Billy]

Danke für dein WIKI update.
Glaube mir ich weiß was das für eine Arbeit ist.

Ich habe den Beitrag nun ins Wiki gestellt, vielleicht kannst du einmal darüber schauen, da ja der Beitrag mehr oder weniger von dir ist und ich alles ungetestet geschrieben habe.

Habe drüber gelesen ist m.E. alles ok
Wenn einer Fragen hat kann er sich ja melden.

Billy

[Reinhart]

ok, dann lasse ich das Wiki vorerst so, irgendwas findet man eh immer zum nachbessern. Das Wiki ist übrigens nicht "meines", sondern ist öffentlich und es kann hier jeder seine Ideen (nach Anmeldung) einbringen und an den Einträgen mitarbeiten.

Das mit der PulsTime ist überhaupt eine tolle Sache, z.B: für Garagentore die nur einen kurzen Impuls brauchen. Arends hat sich das gut überlegt mit den direkten Kommandos in der Konsole. Das einzige was bei ihm noch fehlt, wären Rules wie bei ESPEasy. Aber Großteils hat er die durch die Kommandos nachgebildet und die sind dann sogar auch bedienerfreundlicher.

LG