Category Archives: DS18B20P

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.

Facebooktwittergoogle_pluspinterestlinkedin

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.

Facebooktwittergoogle_pluspinterestlinkedin