Category Archives: DS18B20

ESP8266 Progress

There can be no doubt that I still have some way to go in terms of reliability with my test rig in Spain before putting this stuff in charge of the heating back home in the UK:

  • Raspberry Pi 2 is on an un-interruptible supply but does not 100% recover from loss of broadband. One example made my Apache instance disappear until I rebooted the Pi !! I’ve just instigated a check for Google connectivity every 15 minutes leading to a reboot if no success – hoping this will solve the problem.
  • ESP8266 board mostly recovers from power failure but I have one example of it simply not communicating until next power cycle. Will soon do some tests removing the power for various periods from milliseconds upwards.

Highcharts - click to enlargeOther than these points, I’m starting to get somewhere.  I have plant-watering control running, a kitchen light under dusk to midnight control using my Node-Red scheduler referred to elsewhere – and as of this morning I’m logging external temperatures locally every 15 minutes using MQTT and Node-Red to ask for temperature, MQTT, Node-Red and MYSQL to store the temperature (as read by a DS18B20 using my own ESP8266 fast code) and local HighCharts and PHP to read the temperature from the DB (including missing values) on a chart on the Pi (up to now I’ve always used GroveStreams for everything but I’d like to try storing information locally). I’ve documented all of this in previous blog entries. At some point I want to scrap the PHP and use JS within Node-Red.

Scheduler - click on the image for larger versionBuilding up to this seems such overkill – but then now it is done, the sky is the limit – setting these up (below – and remember – click on any image to show full size version) took no time at all. I used the scheduler with a new addition to my little ESP board, a timer option which turns the output (ESP-01 for example) on on request for X minutes – the board then turns the output off all on it’s own.

So for the watering I just sent the same message at dusk and dawn, a timed request for 4 minutes of watering. I figured dusk and dawn were as good a time as any and no chance of blasting hot water onto the plants (believe me, in Spain if you try this at lunchtime from a typical black pipe watering system, you’ll fry the plants).Node-Red

The lower block above simply puts out the temperature request every 15 minutes and above that an MQTT block picks up the incoming temperature and fires in insert command off to the MQTT node.

Si2302Meanwhile I’ve been pondering a device I’d not specifically come across until yesterday, the Si2302 N-channel MOSFET.  From EBay these work out at a few pence each (like, 3p in quantity) and are simply tiny SMT devices (but large enough to solder by hand).  I’m thinking these might do for powering LED strips, both simply on-off control and PWM.  If I’m reading the spec right, these should work just fine from the 3v + output of an ESP8266 with no other components (no base resistor for example) and with 1 amp’s worth of LED STRIP (12v) attached I reckon the chip should dissipate no more than 80mw. Of course my maths could be miles out but I’ve a few samples on the way to give this a shot and if they pan out I’ll stick them on the next board.

Has anyone had any experience of this particular MOSFET?


Easy MQTT Graphing

I’m quite excited this morning, had an email from Kamil Baczkowicz – could I please try the latest beta of MQTT-SPY – I’ve been encouraging him to add graphing for the MQTT input as even Node-Red doesn’t do this out of the box.. sure enough he’s cracked it. Here’s a working example, I have my DS18b20 running so that it returns the temperature from my little ESP8266 board every 5 seconds. I got up this morning, loaded the new BETA of MQTT-SPY and…

graphing MQTT

Don’t ask me why my DS18B20 started varying by 2 degrees this morning (after being on all night) then settling at 20c – I have no idea what it’s playing at.

What more could you want (I know, lots). Simply right click the incoming stream and you have your graph with options to show everything up to the last 24 hours. I’m sure more is on the way. I just keep getting more impressed by the fast, simple package. It’s a .JAR file incidentally so whatever operating system you’re on you’ll need JAVA installed but that seems to be pretty universal except (and I’ve never figured out why) the mobile operating systems such as Android. If anyone figures out how to get this working on an Android tablet, you will be my best friend ever if you report back in here.


The ESP8266 Grand Master Plan

So… here’s where I’m up to with my little project… currently stalled until we can figure out why the ESP8266 is not recovering from loss of WIFI.

The plan

This is “the plan.  Using the basic MQTT code, I’ve added the ability to control GPIO0 and take input from say a Dallas DS18B20 chip.  I have the ESP8266 on a little board with a 3v3 regulator to ensure it gets decent quality power from a typical cheap 5v supply.  The MQTT software uses a block at 3c000 to store non-volatile information and it’s only using a small part of the 4K available.

Why 4K, because that’s the minimum size of FLASH you can erase – and if you can’t erase, you can’t write. Here is my understanding of the FLASH. You can write a 0 to it – but not a 1. So when you erase the FLASH – which can only be done in 4K blocks as a minimum in this case, the bytes are all set to 255 or 0xFF if you prefer Hex, or 11111111 in binary.

You can then write to that block – and read it as often as you like. The path that Tuan has taken to store user info, passwords etc is to use a 16K block at 3c000, use the first and second blocks to store information (the same information, ignore the third block and use one byte of the 4th block to tell you which of the first two has accurate info. The reasoning for this becomes obvious after a while, you don’t want to lose your info in the event of a power failure during erase or program. So, lets say you have a binary flag in the top block set to 1. That means that the existing data is held in the second block. You wish to change something – read the data into RAM, erase block ZERO, write a copy of the data to block zero and update that flag accordingly – if any of that fails, the data stays in block zero, if it succeeds the software will know to use block 1 from now on when powering up to get the data. Simples. GROSSLY wasteful, but simple.

So as well as input, output and non-volatile data I’ve also added a real time clock able to go for days without update but as it happens my MQTT fires out the correct time every minute. Should the broadband fail however, the clock will still keep ticking.

Now that the system can send messages and receive them including subscriptions to the time, dawn and dusk and other info, I have a state variable which tells it what it is doing – that is described at he top – and involves sending a message with number 0 upwards – which gets stored in FLASH. So 0 turns the output off, 1 turns it on all the way up to 5 which has it operating as a proper thermostat with 2 lots of on-off times.

All works a treat – except… it is not recovering from lost WIFI. So next steps – harassing Luan to ensure his MQTT code is ok and asking him to check to see if the new SDK helps – personally I’m just not that sure how the new SDK is dropped in. The instant this works – I’ll put this in a box with the solid state relay jobs I detailed earlier – and – Bobs your uncle.  First useful ESP8266 outcome. Now, given that there is plenty of code space, that APPARENTLY you can double the clock speed to 160Mhz if you need more power and the availability of ESP8266 boards with many more pins – who knows how this will develop.