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.

It’s getting REAL!

So the four-4-US$12 flow sensors have turned up.  The minimum measurable flow rate appears to be 1 litre a minute.  To put this in perspective Bob Hawke (ex Australian Prime Minister) sculled a yard glass (1.4 litre) of beer in a record (for the time) 12 seconds.

In comparison irrigation “emitters” tend to be in the ranges of:

• 2,0 liters/hour – 1/2 gallon per hour
• 4,0 liters/hour – 1 gallon per hour
• 8,0 liters/hour – 2 gallons per hour

Now this will be per emitter so you will need around 8 times 8,0 liters/hour “emitter” in a line to get a 1 liter/minute flow by napkin scribbles.  A whopping 30! 2,0 liters/hour “emitter” will be needed to get a 1 litre/minute flow in a line.  Note, there may well be more than enough “emitter” to turn the paddle but that will depend upon the individual installations.

Not really a problem as the intention was to use this as a leak detector as the rate will be driven up but the leak, especially if your dog has dug up and chewed through a hidden hose, as evidenced by …

… mind you that one didn’t need a leak detector to find.

These sensors are advertised as low precision in any event so really not a problem.  So this won’t be of use to meter your water usage.

I am playing with the idea of higher precision flow sensors – to set time-versus-budget constraints  – but I will roll that in as a separate option as such a flow meter can likely go on the input rather than output lines, and as we are using MQTT the high precision flow-sensor can also be separate unit to the valve controller/line flow sensor.

All the signal integration will occur in the main host.

Connecting NodeMCU to a NTP server

Ignore the IP suggested in example.

Search google for “NTP server”.

Being Australian I am using one from the pool listed at:

http://www.pool.ntp.org/zone/au

Code therefore becomes:

sntp.sync("0.au.pool.ntp.org",

 function(sec,usec,server)
   print('setting time to:', sec, usec, "from: " .. server)
   rtctime.set(sec, usec)
   sec, usec = rtctime.get()
   print('time set to: ', sec, usec)
 end,

 function()
   print('failed!')
 end
)

The difference between times that you will see, when running this gem, is in and around 7 milliseconds which is the cost from function calls is all.

The idea would be to use a timer, set to max time and auto mode to run this occasionally to keep the time on the node synced with your local world.  That is:

tmr.register(6, 6870947, tmr.ALARM_AUTO, sntp.sync(...)) -- see above code

You might like to set a flag if the sync fails, or publish a mqtt alarm, or something more useful as the print will be lost on the world since we are deploying nodes in the real-world sans terminals.  Although consider loss of sync might also be loss of wifi access and so likely loss of communications with your mqtt server – so devilishly complicated this will all be.

 

 

Differences between WeMOS and UNO pin numbering

The table below shows the mapping between the UNO pins, the pins on generic 4 relay shields, the ESP8266, and the WeMOS UNO clone for you info.

	UNO	Relay on Shield	ESP8266 IO Index	ESP8266 Pin	WeMOS IOL/IOL1
	PD4	4	2	GPIO4	D2
	PD5	3	3	GPIO0	D3
	PD6	2	4	GPIO2	D4
	PD7	1	5	GPIO14	D5

 

OpenSprinklette

So, just got delivery of my 5 WeMOS uno clones …

 

… and 5 …

… we are now ready for OpenSprinklette!  All up AUS$11.00.  Only four channels but add a second unit for sum total of AUS$22.00!

So, a little work as we need to convert the 12volt AC to DC, should work a treat as the WeMOS board is happy to take 9-24V and also provides the 5V the relay board needs (apparently the 3.3V outputs should be okay *whimper*).

Now, since the “leak” (and the $3K water bill for the quarter) I will fit flow sensors to ensure flow is within expected range – so the unit can raise alarms.  Got 4 from Aliexpress for US$12 (or US$3 per sensor) which is better than the AUS$15 per sensor LittleBird is pinging people for similar devices.  Just needs a 3.3V zener and a 220 ohm resistor to adapt the 5V output of the sensor to the 3.3V inputs on the WeMOS.  Will build that onto a protoshield. (Anyone know what the connector type is from the photo below?)

The NodeMCU provides NTP so I can run timers on WeMOS.  MQTT to the ODROID-W server (in the house) to pick up the watering times, weather off internet to decide upon whether or not to water etc.

A second two will be used for remote control of back and front yard lighting.  So remote ON/OFF and IR triggered to boot.

 

Tossing the coin …

… is it the hardware or the software?

Not having any luck with the ESP8266 (as an ESP-01).

Seems I have to re-flash it over and over.

All I do in load the mqtt library and then create a client.  It then seems after a couple of minutes the chip hangs and then I get the chip jamming my bluetooth and I think now also my wireless networking at my PC.

If the led is glowing dimly rather than brightly seems to be the warning.  This sometimes happens when I plug in the USB.  That is I don’t get a bright led, it just barely glows … and of course my mouse then stutters across the screen as it is being jammed.

Not sure that it isn’t also temperature related as I did have the thing plugged in almost permanently this last week.

It may be a problem with the board design given the problem with the USB power tripping the problem and then its the potential for  also seeing the mqtt tripping it due to some bug.  Will take a little work to sort out since there seems to be two routes to same problem.  The potential hardware one though is the killer.

It will likely not be much use in the applications I want to use them in as I don’t want to be cracking boxes and jiggling bits all the time.

Still, I am curious.

When I tried a build tool on the web, to reduce the distro footprint, the crack up pumped wingdings to the terminal.  The full distro not so much.

Both times the mqtt.Create() call would close up shop after a while and the light on the board would dim and the jamming would commence.

If I can’t use them for reliable mqtt clients they’ll go in the bin.

The real problem being that nodeMCU is no longer actively supported.  Likely, was a curious side effect of hackers opening hardware design.  I guess they thought other so-called opensource hardware was making money.  However, Chinese knockoffs of the ESP-xx range abound.  Someone will have to front up to take over the baseline.

The other quirk.  I for some dumb reason decided to run the tools in my GoogleDrive folder so that any files was creating from the ESPlorer IDE would be backed up.   Go figure, the IDE creates a *.lck file when it runs (who knows why).  In any event the strange thing was that GoogleDrive would pick it up and you could not delete it.  That meant once you closed the IDE you could not open it again.  Found a tool on Microsoft site has “special powers” and so I got things working again.  I also moved the application folder back onto my trusty D drive.

Dam Open Source!

Go figure, trying to get luagravity working on the ESP8266.  This is to have a little reactive programming going on!

Not to happen so far.

First luagravity won’t compile on ESP8266 as the full distro does not have enough memory.  Although the file is not that large.

I went to nodemcu forum to get help.

Told to “nick off” (nicely) as nodemcu is no longer in active development.

Got directed to an auto build tool.

Auto built a minimum size distro to see if that would allow me to squeeze luagravity on.

Got a binary and so simply had to flash it.

Flashed it.

ESPlorer IDE would not connect to chip on any baudrate.

Hmmm.

Tried reflashing the original distro.

Same deal!

No longer can connect on any baud rate.

In fact a strange defect appears to occur in the hardware.

I found that I either get the power led on when I power up the board OR I don’t.  When I don’t I found my bluetooth mouse was not behaving.  Turned out the ESP8266 is jamming my bluetooth (at least) when the power led doesn’t come on (but not because the power led doesn’t come on of course, there is something deeper happening).

Might have to pull another chip from the drawer to see what is what.

So much for reactive programming on the ESP8266.