Tag Archives: github

screenshot_2018-09-23-17-28-33

Useful notifications from your home appliances using Node-RED

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.

grafana-consum

Continue reading

20170528_105440s

Grid-eye camera (sliced, of course)

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.

Continue reading

20170426_224506s

Slices of a clock

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

20170426_224545s

Continue reading

20160819_002338x

RFM69 WIFI Gateway

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.

Home WSN version 2

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.

Continue reading

XBee to MQTT gateway

So far I’ve posted about hardware and theoretical stuff like network architecture or naming conventions. I think it’s time to move to the software side.

The core of the sensor network I’m deploying at home is the Mosquitto broker that implements MQTT protocol. It manages the messaging queue, listening to messages posted by publishers and notifying the subscribers.

I’ve been working in parallel to have at least some pieces in place to get and store information from the pulse counter sensor. These are an XBee to MQTT gateway and a couple of consumers: one storing info into a MySQL database and another one pushing it to cosm.com.

I want to introduce you the first piece: the xbee2mqtt daemon. It’s already available on github under GPL v3 license. It publishes the messages received by an XBee radio to the Mosquitto instance. The radio must have a Coordinator API firmware loaded. Right now the gateway understands frame IDs 0x90 and 0x92 which account for “Zigbee received packet” (i.e. data sent through the serial link of the transmitting radio) and “Zigbee IO data sample” (that’s an automatic sample of selected analog and/or digitals pins on the transmitting radio).

I’ve tailored the daemon to my needs, but trying to be as generic as possible. The design is based on small components:

  • The “xbee” component takes care of the connection to the radio and the packet parsing.
  • The “router” maps xbee addresses/ports to MQTT topics.
  • The “processor” pre-processes values before publishing them.
  • The “mqtt” component takes care of the message publishing.
  • And the XBee2MQTT class (which extends Sander Merechal’s fabulous daemon class) glues everything together.

You can read the code to get a full insight of what it does but I’d like to explain here some decisions I’ve taken.

I’ve abstracted the message source to an address and a port. The address is the 8 bytes physical serial number of the radio (SH and SL) and the port is the pin (adc0, adc1,… dio1, dio2,…). 0x90 packets are mapped to virtual ports. The sender can define the name of the virtual port (like “battery:4460\n”) or otherwise a generic name will be used (“serial” by default).

The routing is a basic functionality. As I already explained in my previous post about topic naming conventions I think the mapping should be done in the gateway because no other component should have to know about the physical structure of the wireless (XBee) network. So the xbee2mqtt daemon maps all the messages to MQTT topics with semantic meaning. You can also allow default topic mapping which will publish any message received by an undefined address/port combination to a topic like /raw/xbee/<address>/<port>.

The processor uses a strategy pattern to pre-process any incoming value. I will be using this to do some calculations on the adc7 value the XBees report (that’s the voltage monitor pin) to convert it to the real voltage the batteries are providing.

All the components have been designed so they can be injected to any code that depends on them. This is a common pattern (dependency injection) that favours decoupling and provides a clean way to define strategies at runtime, for instance when mocking components in the unit tests.

As always, comments are more than welcome!