PIRrring along … not really

Knocked together a temporary wifi PIR sensor.

So, with fencing contractor turning up for a 3 day task of replacing the side and back fence on our property, I thought I would throw together a couple of motion detectors to keep an “eye” on the backyard at night.

The plan was to use a couple of WEMOS D2 R2 2.1 I have. Along with dual 16340 battery shields and also a side-dish of HC-SR501 PIR Sensors, a wifi based motion detector is born.

I did hack this into my opensprinklette system, adding the PIR as “gadgets”.

I have a node-red setup with text-to-speech, and a ping to my MQTT server provides and audible warning. It also sends an email to my personal account. I would have sent an SMS to my phone, as I have a second phone with an old SMS server on it (no need for external accounts). Just cannot find where I put that phone (DOH!). In any event, works a treat with vanilla code.

The problem is I have tried getting the light-sleep mode working to try to get as much oomph out of the batteries (to cover off most of the night). BUT. But, it seems the wake function is not so reliable. I can get it to wake not long after it sleeps, a couple to three times but, with a light-sleep function, it seems to work for a couple of times – then naught, stays asleep.

I have a LWT set up so the WIFI on the board is getting turned off (since the LWT is reported by the MQTT server). With a little too strenuous waving you can get thang to reconnect to the WIFI and report movement at least once, maybe half a dozen times, buth then goes to sleep and never wakes (or really I am not going to wait for the very long and boring timeout that has been set).

I note the example code loves GIO02 (which is the BUILTIN_LED on the D1 R2). I have also tried various other GIO, assuming it may be problematic on some IO and not on others. There is a warning not to use GIO16, which I heeded.

Without a sleep function, I the thang can tick over and ping the node-red flow I have set up reliably, with no obvious problem with false alerts. So I relented and went with that.

I have decided to set it up to run all night on my desk, facing away from seductive heat signatures. I have a “herald” message, and I assume the battery will die into the night, so I’ll see a LWT. That way I can gauge how long an approach that does not use any sleep mode will provide movement detections.

Speaking about opensprinklette, I am half way through designing a cleaner board. But then found a not bad board on Aliexpress. The (take a deep breath if you’re going to say it) LILYGO® T-Relay ESP32 5V Relay Module 8 Channel With Optocoupler Isolation (if you’re turning blue … I told you so!).

I might have a look at a port of opensprinklette to that board, though it would need a separate 24VAC to board DC conversion.

UPDATE

Ran the simplified code all night. Only reading the PIR and then sending an email if high. Ran for about 4.5 hours, which was probably okay for the job – it really only had to work for one or two nights. So, with a recharge in between and a half the night covered, goodenuff.

The problem, and as many people are reporting for this PIR, quite regular false detects. False since I had it running on my desk, in the dark, facing the back panel of a bookcase. So darkened room. No movement. In the morro, chockablock my email was with “Boo! Movement detected” messages sent from node-red.

The “missing” false alarms when running initial tests appears simply because the false alerts were intermittent, and the initial bench tests were short runs.

I thus dropped the ESP8266 based approach for an ESP32 based, as the ESP32 SDK seemed simpler to sort. However, two problems. One, the WEMOSBAT board seemed not to charge the battery (I have one on my Manual PnP for a wireless peddle that seems fine). The other, I can happily get the dang thing to sleep, but never wakes, though that may be the problem with the board charging or the 5v circuit.

Fence is up now, no need to proceed, BUT I will try another WEMOSBAT board to see if I’ve got a dud board or a dud battery.

Small steps

I have roughed a node-red config node and it’s visible counterpart.  I decided to call wemos nodes “sectors” – since the usual rort is to call a single channel on an irrigation controller, controlling a single solenoid, a zone.

I have set up for 4 sectors each using a WeMOS D1R2 with a quad relay shield.  That provides up to 16 zones (4 per WeMOS).

You need to mod the relay shield with a couple of pullup resisters.  This is to get around a design shortfall on the WeMOD D1R2.

I am using a protoshield in between the WeMOS and the relay shield to allow for fidgeting with design changes. I added a four position dip to set the zone id BUT I dropped that in favour of the config node concept.

That gives me back 4 pins for GPIO. The problem is the out and out lie that the WeMOS is a Uno form factor. The ESP8266 has to cheat by using the same GPIO pins across a couple of Arduino socket pins.

I will add the rain gauge input later.

The idea is an input line such as the following as the title of the google calendar event:

sector1=1,sector3=4,sector2=0,sector3=1

The line above shows you some of the input features I will aim for, being:

• You don’t need to nominate all four sectors or even all four individual zones of a sector.
• You can order the sectors in any order.
• The zones per sector are number 0..4 with 0 being the global all on/off id for all 4 zones on the addressed sector.

I did think about using JSON as input but the problem is that if you have two tokens the same then the object construction takes the later value in the line for the key.  Oh well.

For this to work you attach two google calendar event sniffers, one to flag the start of an event and one to flag the end.  Both feed into the opensprinklette-configurator to decode the events into MQTT calls to the 4 WeMOS D1 R2.

Of note, the configurator maps between chipid() and sector# (and back again) so planning the sprinkling can be in people-talk (relatively speaking).  At least you don’t have to remember which WeMOS chipid() was allocated to what sector.

Of course, there are quirks to do with the distributed system.  There will be a watchdog on the WeMOS to automatically turn off the water to a zone after 45min.  To plan out longer watering you will need back to back calendar events (shorter than 45min to avoid the watchdog).  If that is offensive please send money to help me pay the water bill of a runaway commercial setup ($3,000 in fact).

The other option I guess is send the duration to the WeMOS node and let it do the countdown.

I will play with a couple of timing approaches to see what is most robust – given you could have the ISP gateway drop out, the node-red crash, the emqttd crash, the OPiZ drop of the network.  Not to mention, google calendar hickups – I occasionally get a baulk around credentials lapsing that somehow comes good again.  Oh and of course, the WeMOS could also behave badly.

All in all needs a good bashing to help weed out nuisances.

Back to work

So, at last, now that the OPiZ setup saga is over (fingers crossed) we begin over.

I built a new nodemcu firmware for the WeMOS to include:

• bit
• end user setup
• file
• GPIO
• MQTT
• net
• node
• RTC Time
• SNTP
• timer
• UART
• Wifi

A few coding snippets later and  the WeMOS can catch the mqtt topic running on the OPiZ feed by the node-red on the OPiZ.

So, I can now parcel up the OPiZ as the house server and tidy up the sprinkler system.

I did note that the WeMOS did not come up first time I bombed the firmware.  That was sorted (it seemed) by selection the 4MB Flash option on ESP8266Flasher.  The ESP-12E on the WeMOS has a 4MB flash and I noted that there is a branch of the nodemcu frozen in time now for the 512kB chips – so go with the master branch if you have the WeMOS D1 R2.

I did also manage to break a hoodoo now that nodemcu does away with autoconnect for the MQTT.  The timer callback scheme works a treat.  I can reboot the OPiZ and the WeMOS will reconnect once emqttd is up and running again.  Of course, I have a LWT setup so that the emqttd server will tell the node-red if the WeMOS drops off the channel.

This is getting exciting now.

PEP Project kick off

So, I downloaded and installed and then run Arduino IDE 1.8.3.

I included the ESP8266 core.

I grabbed the blink example for the ESP8266 and bombed the WEMOS D1 R2.

We are blinking.

I then disconnected power and installed the ITD 2.8 inch touch screen shield (V1 I suspect).

I added power and led blinked PLUS I have back lighting on the LCD.

So far so good.

Next is grab and install libraries for the LCD to see what needs to be done on the WEMOS to port them.

Looks like some work to set up for the ESP8266.  Should be fun.

Errr … no.

I should have looked at this sooner as the ESP8266 does not have enough GPIO.  When you look more closely the UNO compatibility is met by sending the same signal to a couple of the arduino pins but for the most part you cannot run the TFT board on the WEMOS after all.

So,  I dusted off an old MEGA1280 to play with the TFT library.  No biggy, a little messy but might then look at simply adding a ESP-01 module to provide the MQTT client over the serial buss from the MEGA.  Once I get the hang of this I might as well order a couple to three mega2560+3.2 inch TFT from Aliexpress.

I can then set them around the house and front/back yards to control various things – for when I don’t have my phone on me.

Mind you, I also had to back date to Arduino 1.0.5 to program the MEGA1280.  I keep it around as it has been used to play with avrFORTH and OCCAM (except Plumbing doesn’t appear to work on Windoze 10 grrrrr)