Chez Toi IOT design goals 1

Summary of the goals (part 1):

• Independent of external Internet
• Attached hardware functions irrespective of connection status
• MQTT control
• Automatic reconnect after connection failure

Reasons / Consequences

Independent of external Internet:

France is still a long way from being the cybercountry that e.g. the UK and the US are. Many rural areas (including mine) still have no cable, ancient copper wire - some not even supporting ADSL. prior to getting my (expensive) satellite connection I could barely manage 1.5k bps - yes, k not M - up the phone line as I'm 6.5km from the nearest exchange. There is no way then, that I'm going to equip my home with commercial devices that rely on the manufacturers' "cloud" to operate. If I did that, I'd have no automation every time there was a heavy storm.

The options then were to a) build everything from scratch (which is what I originally set out to do...) or b) find some commercial hardware which is easy to modify. The latter took on a life of its own once I discovered ITEAD's Sonoff range of devices that I now love, but "easy" is a relative term - which is a lot of the reason for this blog. The "Essential Information" links go into a lot of detail about that, do read them before setting out on a similar exercise.

So a raspberryPi runs my MQTT server and the excellent NODE-RED which applies the "intelligent wiring" to the system.

There is a side-effect which is a benefit or a hindrance depending on your point of view. If you like to be able to check the temperature of your hallway while you are on holiday in the Amazon, then it's a hindrance, because you can't get to it from the Internet. If - like me - you have a background in IT security, that's a 100% benefit, because nobody else can either...

Attached hardware functions irrespective of connection status

All of the early examples and other firmware I looked at in the "thinking" stage had fundamental flaws. The majority would "break" and usually reboot when there were connection outages. 99% of the ESP8266 examples you find out there work the same way - there is a "classic" connection method which runs in setup. Unfortunately, setup runs exactly once. If you get an outage during your main loop, the only way "back" is a reboot.

I don't like that for a number of reasons. 1) It looks like poor design / cheap programming. 2) While the device is rebooting - no matter how quickly that may be - it isn't servicing your burglar alarm or preventing you from falling downstairs in the dark. 3) The majority of the code that didn't commit the worst sins was badly structured so that while trying to fix the outages, it couldn't be servicing the hardware even without a reboot. You know what they say: "If you want something doing properly..."

So from day 1, my aim was twofold: 1) No reboots. Never. Ever. 2) Hardware gets first look-in every time and works whether you are connected or not. In short, the system has to be "connection-agnostic" or "bombproof".

The consequence of that one decision was a lot of sleepless nights, swearing, some pretty hairy code and re-acquaintance with programming errors I last saw 40+ years ago, e.g. the dreaded and impossible-to-find timing bug - the "heisenbug"

MQTT control

ESP8266 hardware, while magnificent, has limited resources. I needed to minimise the amount of intelligence built into each device for a million obvious reasons and MQTT control allows a lot of heavy lifting" for a low code footprint in each device. Plus it's the de-facto standard these days and I wanted both wider application and portability

Automatic reconnect after connection failure

This has already been mentioned and is a natural consequence of "...irrespective of connection status" as it's a lot harder to do than it sounds. It involves conceptual "layering" of the code (like most OSs) so that the hardware "layer" has as little possible in common with the connection layer and the two operate autonomously and independently. Fun, I can tell you.