Unit testing your code is peace of mind. It has two main direct benefits that impact on your confidence about the code you are writing:
Testing expected behaviors
Avoiding regressions (i.e. breaking something that was working fine before)
Unit testing embedded systems is a bit more involved since there is the additional constraint of the hardware itself, sometimes more than one device or even different platforms. Quitting (or not even thinking about it) is the easy answer to the problem. All of us have debugged expected behaviors with inline prints. But automating some of these tasks have a huge benefit on the code quality and development speed. Continue reading →
Some time ago I worked on a home project to get a notification when my washing machine had done its job based on monitoring its power consumption. There was a good reason for that, the machine was outside the house and I had already forgotten about the laundry several times. And when that happens your only option is to wash it again, because it really smells musty…
Monitoring your appliances
Use ESPurna 🙂
OK, there are different ways to get the info about power consumption. But since we want to be able to process the data ourselves most commercial products won’t be suitable unless we modify it.
Alternatively, those that use radio communication to send data from the meter to the base station might be suitable for a man-in-the-middle hack. For instance, if you own an Efergy power meter you must know you can sniff the data it sends using a simple RTL-SDR dongle.
But for most cases, your best chance is to get your hands on a commercial product with an ESP8266 chip in it and change the firmware to suit your needs. You can write your own or use an existing firmware like ESPurna, that already supports a bunch of power metering smart switches.
What info do you need?
The idea is to report (via MQTT) power data from each individual appliance very minute. You can then use Node-RED along with InfluxDB and Grafana (or Graphite) to receive, persist and graph your data like in the image below.
Tindie is a great place to find uncommon electronic components or weird/interesting boards. I use to stroll around it’s products to basically see what’s new. It’s like Kickstarted but for real. One such uncommon and new electronic components is the Panasonic’s Grid_EYE AMG88 [datasheet, pdf] infrared sensor. And I first learn about it through Peasky Products breakout board at Tindie.
And if you have been reading me lately you might know I’m going through my own LED fever. My latests “sliced” projects are not the only ones I’m working on at the moment. So it was not surprise my brain immediately linked an 8×8 IR array with an 8×8 LED matrix display. You see?
So what do you have if you throw in a box an IR sensor and a LED matrix, add a small microcontroller, a LiIon battery and a charger and a step-up to power the LEDs? Well, in my case the outcome has been a bulky but nice camera (albeit a very poor resolution one).
I know there are commercially available IR Cameras like this one [Ebay]. They have 300k pixels and can overlay a normal image over the IR image and other fancy stuff, but they are also more expensive (around 200€ the best deal) and waaaaaay less fun to build.
There are so many ways to tell the time. DIYers have been doing clocks since the Ancient Egypt (obelisks lacked portability, thou). Every modern maker has a clock amongst her first projects. I have done some myself, including a fibonacci clock, a wordclock with a fancy green matrix effect and an unreleased project that hopefully will see the light someday soon.
But recently I came back to the idea behind the wordclock before, to extend it in different ways:
Replace the ATMega328P with an ESP8266 (NTP support and user interaction)
Smaller sizes (8×8 LED matrices)
Smaller PCB, less buttons
Add buzzer for alarms
Replace the 3D printed part with a wooden grid cut in laser
Completely closed enclosure, better presentation
Fix some issues with the original board (like the lack of a beefy capacitor across the LED matrix power lines).
Some 3 years ago I started building my own wireless sensor network at home. The technology I used at the moment has proven to be the right choice, mostly because it is flexible and modular.
MQTT is the keystone of the network. The publisher-subscriber pattern gives the flexibility to work on small, replaceable, simple components that can be attached or detached from the network at any moment. Over this time is has gone through some changes, like switching from a series of python daemons to Node-RED to manage persistence, notifications and reporting to several “cloud” services.
But MQTT talks TCP, which means you need some kind of translators for other “languages”. The picture below is from one of my firsts posts about my Home Monitoring System, and it shows some components I had working at the time.
All those gears in the image are those translators, sometimes called drivers, sometimes bridges, sometimes gateways. Most of them have been replaced by Node-RED nodes. But not all of them. This is the story of one of those gateways.