In the series of don’t-we-already-have-more-than-enough-of-these-gizmos: Today I made a simple power conscious cloud-connected weather sensor. While the design itself is trivial, it seems that ready-made devices available seriously lack in connection options and customisability – while doing something like this is a simple matter of programming™.
What a temperature-thingie should do?
Here in Malaysia electricity isn´t exactly the most reliable resource. I have had to throw everything in fridge/freezer away every now and then – wouldn’t it be great to actually be able to monitor that freezer – or, maybe be able to check if I have left AC on by mistake.
- Let’s make it a general purpose compact sensor that measures light, temperature and humidity.
- I need it to have low power use to be able to use batteries – you would not pull a cable to fridge, would you? (Yeah, sure you would, but I would not.)
- I want connectivity enough to be able to read it from where ever – having a home-intranet-only visible device would be so..2014.
- I want it to be free from obscure and proprietary 3rd party APIs and to be able to connect to any system – I have had these devices with one app to use with – or then they have required obscure base station or hub. Also, generally after release I haven’t seen too much interest from vendor to make any updates. Nil, nada – which brings me to..
- It must support OTA upgrades so that I can reconfigure the device to my taste once I have installed it – I would not like to drive to the device just to push specific reset or upgrade-now button.
- DMCA-free, and also from other toxic mental substances.
- I do not know all the use cases so I want under-the-hood&frunk&trunk visibility, 100% hack-ability. I know for most of the gang this really means nothing, but let me tell you: Embedded code isn’t rocket science, not today, not any more. Unless you write code for SpaceX – then I salute you.
No matter how careful I am, my hardware designs seem to require a second iteration. Here my mistakes were:
- Putting the DHT22 temperature&humidity sensor next to micro controller – heat leakage results 2..4 C higher readings if device is on 100% of time. I was expecting this, but not this much. Also, DHT22 isn’t exactly industry grade device.
- Wiring DHT22 NIL pin to DATA pin. Who knew that in China NIL equals to GND. Wire cutters resolved this problem.
- Wiring piezo buzzer to Microcontroller’s DAC pin that cannot output tones: “Do not be lazy when designing hardware.” I will need to jump wire that to another output. (not used here yet, though)
Resolving two out of three the hard(ware) way, one remains to be resolved in code.
Technology based challenges
How much sleep is required to dissipate the heat?
Saving power by putting device to sleep is a no-brainer for embedded devices. I am happy Photon supports both shutting down external parts, and as well going full-on deep sleep that resets the device. Calculating linearly from leakage above (this is incorrect method, but close enough) putting device to sleep for 600 seconds and waking up for 5 seconds should limit the leak. (Again, seconds are not right measure here, power quota is: the device takes about 10x current when establishing wi-fi connection, assuming 5×10/600 = max 10% of 4 °C..0,2..0.4 °C – which should be acceptable)
How to contact or OTA-upgrade a 99% sleeping device?
Particle cloud does not yet offer persistent calls or events that would be waiting for Photon when it connects to WiFi, but the device sends an event to cloud on connect. (Thanks for Particle support for recommendation!) With a simple python script to respond to that I can ask the device to go to safe mode for firmware upgrade. No servers needed.
For the upgrade to function, the only downside is that Photon needs to run a while – network communications aren’t that fast right after boot-up: If I only boot the device, collect sensing information and shut down immediately, the cloud function does get called in device before it goes to sleep again.
One might be able to handle this by timing the call properly, but easier is to keep device on line for two extra seconds, so that the function response can be processed on the same cycle.
Now the upside of having this function in the device is that once safe mode is called, the device reports back once it gets there: it provides visibility all-the-way until ready for device firmware upgrade [DFU] . And once DFU is complete that reports back too. I call this an extremely well thought user experience.
Does it blend?
Yes it does, but more than that it allows me to integrate against anything I like – and modify the functionality to the extent of my soul and available RAM/Flash. Instead of being free (as free beer) this model gives freeDOM like first seconds after base or hot-air-balloon exit. (Sorry, no affiliation with Dom Perignon)
Warranty? – Take a look at a shiny piece of metal and see it looking right back at you.
Demo: Readings in JSON, and safe mode triggered with Python script
Source code in git hub: https://github.com/takkulan/eDHT
Plea: Vendors, please make your embedded devices firmware open source. Once you stop maintaining them, we would like to continue and add to your awesomeness!
(Disclaimer: ..but do not open source in case you have stolen code or violated license terms)