External perimetral lights and motion detector with Sonoff + radar + night/day

[xoseperez]

Originally reported by: P.B. (Bitbucket: PieBru, GitHub: PieBru)

---

Hi, I'm trying to IoTize my house perimetral lights and I would like to use Espurna.

I'm using Sonoff Basic (or Wemos + solid state relay), motion sensing with radar doppler (RCWL-0516 or similar), night/day sensing using a software sunset/sunrise algorithm I already developed specifically for small MCUs as Arduino.

Thanks to the radar and maybe with an additional PIR, these perimetral things could be also an informative source for external motion, a sort of additional alarm sensors to be centrally filtered and coordinated with other sources.

I already tested all the above and I would use Espurna as a basic framework, so I need some hint. This is the solution I tested using a Wemos D1 mini, a relay and a RCWL-0516:

1. To reduce false positives for power supply spikes, I soldered a 470uF capacitor directly on the VIN/GND of the RCWL, powered by the Wemos 5V pin trough a 15 ohm resistor. 3.3V seems not enough in my tests, even if someone says it should work.

2. The RCWL output goes to Wemos GPIO14 (D5) trough a 10K resistor.

3. In hardware.h I added the second button to WEMOS_D1_MINI_RELAYSHIELD, no PULLUP and no DEFAULT_HIGH here:

#!arduino
    #define BUTTON2_PIN         14
    #define BUTTON2_MODE        BUTTON_SWITCH 
    #define BUTTON2_RELAY       1

All seems to work so I can proceed, but I need:

1) Some hints for an option (#define) to activate the relay after N seconds (typically 3) of HIGH on GPIO14. This is useful to reduce false positives, as when the RCWL output stays high a only 2 seconds it's a false positive.

2) Some hints for an option (#define) to leave the relay ON for at least N seconds after activation (typically 30-60), even if the GPIO14 goes low. This is a typical feature of radar bulbs and other automatic flood-lights.

3) An hint on the best place where to insert the isdark() function, which uses sunset/sunrise algo to simulate the photoresistor.

A MQTT motion notification should be sent even when ifdark() does not activate the relay.

At the end, all could be eventually integrated with the new scheduler.

I'm quite fluent in C and MCU but a newcomer in Espurna, can you help me to pinpoint the needed steps? After extensive testing I will pull request all to Espurna.

Thanks,

Piero

[xoseperez]

Original comment by P.B. (Bitbucket: PieBru, GitHub: PieBru):

---

Whatever time provider does the job, NTP is ok as it is for the scheduler.

Sunrise/sunset needs the julian day which is obtained from year/month/day, and an approximate latitude/longitude which can be #defined or obtained from IP geoloc. After testing some algorithms I decided to adopt the one by Mike Chirico (2004), it's enough simple and precise. The computation need to be performed only once a day. Then from sunrise/sunset we can obtain dusk/dawn (offset 6 degrees) and midday/midnight.

Then I developed a MCU-friendly DST algo (Daylight Saving Time), the formulas are inspired by Wei-Hwa Huang (US), and Robert H. van Gent (EU). This first version is valid for US and EU only but can be implemented for other zones https://en.wikipedia.org/wiki/Daylight_saving_time_by_country

Now I'm tinkering with Espurna code, hope to have soon something to test.

Piero

[xoseperez]

There are RELAY#_DELAY_ON and RELAY#_DELAY_OFF settings that I think would help you achieve points 1 and 2 in your first post. Setting RELAY2_DELAY_ON to 3000 will postpone the relay switching on for 3 seconds, if a relay OFF command is issued during those 3 seconds the action will be cancelled. Then with the RELAY2_DELAY_OFF to 30000 you can force the relay switching OFF 30 seconds after the PIR signal has gone LOW.

How is the sunrise/sunset logic implemented? Do you need NTP or an RTC?

[xoseperez]

Original comment by P.B. (Bitbucket: PieBru, GitHub: PieBru):

---

Dived a bit into Espurna code, IMO these ideas could be satisfied by two independent functions.

Xose, do you think this could be viable?

1. A scheduler addition to support "When time is" +-N minutes from sunset/sunrise and maybe also dusk/dawn. As I sayd before, I already developed MCU-optimized algorithms for this.

2. A BUTTONx addition (attached to GPIOxx as #defined in Sonoff Basic) to support sensors which activate after a long debounce (typ 3", a sort of BUTTONx_DEBOUNCE_DELAY = 3000) and stay on a minimum time (typ 30-60"). For the security goals described before, on/off should be signaled via MQTT.

I would prefer to keep sunrise/sunset logic in the ESP, this way it is resilient to wifi failures.

Thanks,

Piero

[xoseperez]

See #1263

[mcspr]

Also see #2417 Sunrise / sunset time is there. ""When time is" +-N minutes from sunset/sunrise" is something I have seen in the linked issues, but... I wonder if this can be solved by moving one coordinates slightly so the sun arrives earlier or later. (and 'after' also solved with pulse and delays)

edit: ...or at least with the 'calendar' default time string. one possible impl may look like dzvents 'within', 'before' and 'after' time keywords

edit2: nvm. https://github.com/xoseperez/espurna/wiki/Scheduler#relative-time not as expressive as domoticz scripting, just 'before' and 'after'