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.
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.