Simply Dashing!

I’ve finally gotten around to making a web frontend for my Raspberry Pi & Arduino wireless sensor network.

I chose Shopify’s Dashing dashboard, as its opensource and can be installed locally and not via some cloud crap.

Essentially you have a HTML template into which you feed JSON data. I got a bit tied up in the JSON formatting so it took longer than it should have to get working (about 3 hours) but once I realised that most of the job placeholders were a single line of JSON, and not a whole entity, it was quite straightforward. Here’s 90% of my entire dashboard code:

SCHEDULER.every '30m', :first_in => 0 do
    require 'sqlite3'
    db = "/var/tmp/weather.db"
    study = db.execute "SELECT reading FROM weather WHERE node=2 ORDER BY date DESC LIMIT 3"
    send_event('study_temp', { current: study[0][0].round(2), last: study[2][0].round(2) })

    shed = db.execute "SELECT reading FROM weather WHERE node=1 AND type=2 ORDER BY date DESC LIMIT 3"
    send_event('shed_temp', { current: shed[0][0].round(2), last: shed[2][0].round(2) })

    outside = db.execute "SELECT reading FROM weather WHERE node=1 AND type=1 ORDER BY date DESC LIMIT 3"
    send_event('outside_temp', { current: outside[0][0].round(2), last: outside[2][0].round(2) })

    lounge = db.execute "SELECT reading FROM weather WHERE node=3 ORDER BY date DESC LIMIT 3"
    send_event('lounge_temp', { current: lounge[0][0].round(2), last: lounge[2][0].round(2) })
    light = db.execute "SELECT reading FROM weather WHERE node=4 ORDER BY date DESC LIMIT 1"    
    send_event('lightsensor', { value: light[0][0].round(1) })

    bedroom = db.execute "SELECT reading FROM weather WHERE node=0 ORDER BY date DESC LIMIT 3"
    send_event('bedroom_temp', { current: bedroom[0][0].round(2), last: bedroom[2][0].round(2) })


Here’s a screenshot of the finished dashboard, including an additional widget that shows the RPi-1B’s very stretched RAM:

It installed a lot easier on Debian Sid than Raspbian Wheezy, but I hear Raspbian Jessie is easier due to updated bundler/exec_json/nodejs packages – every time I use Ruby I seem to go through dependency hell, Ruby seems to have a lot of issues with backwards/forwards compatibility with Gems – why things like bundler/rvm are necessary I guess. Makes Java look portable.

RF24Network Updates & More

I’ve made my Pro Micro/Mini ISP breakout board and Raspberry Pi nRF24L01+ breakout board as per my previous post and decided to get on with trying out RF24Mesh. The problem there was that with the newer commits to RF24 and RF24Network, I was getting no response from the Arduino’s to the RPi.

After some debugging with the author of the libraries on GitHub, we managed to find the culprit – not really the clone issue or the differing module issue, but actually a bit of an oddity in how dynamic payloads and dynamic ACKs work together. So with the Development branch re-opened, we now have the modules talking again. It may need some more work to get mesh working though. So for now I’m sticking to RF24Network, not RF24Mesh.

I’ve migrated all of my various sensor modules to a more streamlined setup – essentially there’s a daemon listening on the Pi which directly populates the database now, rather than the previous separate cronjob. It also handles taking measurements from the DS18B20 sensor on the Pi breakout. The daemon also accepts TCP connections should I want to use an ESP8266 sensor, its also handy for debugging using netcat. Each module sends each sensor reading separately, so each RF24 transmission is under 16 bytes long, rather than pushing the 32 byte limit.

One of my new modules is a 3.3v 8MHz Pro Mini 328, from which I have removed the LED’s and regulator to drop the current use. I’ve also configured its fuses and boards.txt to run at 1MHz from the internal oscillator and set all unused digital pins to INPUT_PULLUP. Now its using under 4uA at sleep. The boards.txt entry looks like: Mini 328 (1.8v, 1MHz internal osc, BOD off)

I then added the BH1750FVI light sensor to the circuit and found that the sleep current was the same as when it was awake taking readings, about 110-145uA, instead of 5uA the manufacturers claim. So I switched to using the BH1750FVI library as it had better sleep support. Alas that didn’t fix things and I decided the module simply wasn’t sleeping. After some reading of the datasheet and playing with code I finally figured out that after calling power_on and reset to wake the device from a power_down, you have to set the resolution mode again. I also found that disabling the pullup resistors on the I2C pins helps, as the module already has internal pullups. I’ve tested it down to 1.5v, which is quite far below any of the components ratings, but it works….

// include libraries
#include <Wire.h>
#include <BH1750FVI.h>
#include <RF24.h>
#include <RF24Network.h>
#include <SPI.h>
#include <LowPower.h>

// global vars
BH1750FVI lightMeter;

// init network ce,csn
RF24 radio(9,10);
RF24Network network(radio);
const uint16_t this_node = 4;
const uint16_t other_node = 0;

void gotoSleep()
    // sleep radio

    // sleep mcu for 225x8/60=30mins
    for(int i=0; i<225; i++)
        LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF);

    // wake radio and sensor

void setup(void)
    // set unused digital pins to input pullups to save power
    const int unusedPins[] = {0,1,2,3,4,5,6,7,8,14,15,16,17};
    for (int i=0; i < 13; i++)
        pinMode(unusedPins[i], INPUT_PULLUP);

    // init sensor

    // disable pullups as sensor already has them
    pinMode(SDA, INPUT); // a4
    pinMode(SCL, INPUT); // a5

    // init radio
    network.begin(90, this_node);

void loop()
    // pump network

    // take a sensor reading, pad to 2dp
    long lux = lightMeter.GetLightIntensity() * 100;
    if (lux == 0)
        // take another reading, its not ready
        lux = lightMeter.GetLightIntensity() * 100;

    // create data structure - bh1750=type11
    char txBuffer[16] = "";

    // transmit
    RF24NetworkHeader header(other_node);

    // sleep

I finally got my hands on a Particle Photon. However I found a bug in the way it reports its error status to dfu-util, it flashes ok but says it hasn’t. The fix is in 0.4.5 but requires a bootloader ID upgrade, so it won’t be 100% fixed until 0.4.6, unless I get a JTAG programmer to set it in the meantime. Otherwise it seems to be more mature than the Spark Core – well they fixed most of the issues there before working on the HAL for the Photon I guess.

I’ve also started playing with an MRFC522 RFID reader/writer and some cards/keyrings – worrying how easy it is to clone those things! I’ve also got some HC-05 Bluetooth modules to play with next.

We’ve also made a few commits to arduino-mk this month.

RF24Mesh Sensor Nodes

I’m going to get back into making Arduino sensors for the house/garden. I’m going to use the RF24Mesh library this time instead of just RF24Network so that the sensors can forward packets along from each other, hopefully meaning that I can use the smallest radio modules instead of the PA+LNA variants which suck a lot more current e.g. 45-115mA instead of 15mA.

I plan on using a bunch of 3.3v Sparkfun Pro Mini boards with the regulator/LED removed, and fed a clean 3.3v to VCC from a Pololu step-up regulator, with a 10uF decoupling capacitor across VCC/GND on the radio.

As I hate programming with a USB UART and dupont cables to the Pro Mini, I decided to make a little ISP breakout board. That means I can connect my USBASP using a regular 6-pin ICSP cable and feed the Mini 3.3v – I must remember to set the jumper! As luck would have it, it actually has the same pinout as the Pro Micro (contrary to various pinout documents) so I could even use it with that to make burning the Leonardo bootloader easier.

On the Raspberry Pi side I’m going to make a breakout board with a LM1117T-3.3 regulator to supply a clean 3.3v with enough current for the radio, from the 5v GPIO pin as the 3.3v GPIO pin can only source 50mA. It’ll also have a header for the radio and decoupling capacitors.

Both of these boards are going to make use of the 24×18 perfboards I got recently, rather than veroboard I usually use.

More Gadgets On Order

I’m just waiting for a right angle USB cable – to connect the RPi’s A connector to the USB DAC’s B connector in my radio.

I’ve built/tested my servo camera mount, just got to test it on the Pi (I used Arduino) and figure out how to mount the Pi’s camera to the bracket – probably a piece of wood with four screws.

I’ve modified my RF24 weather station code to also transmit commands to an Arduino to blink an LED (or eventually fade an LED strip) based on Tweets, rather than just receive sensor readings.

The acrylic for the Pi Radio arrived – with a small amount of Dremel’ing the 20×4 LCD, 2x speakers and 3x buttons fit fine. I then used the slot-in design of the original glass to fix the acrylic to the box.


I’ve been playing with the rewritten RF24 and RF24Network librariy forks and am impressed. The RF24Network library is a much more reliable way of using multiple nodes than just using the same channel/pipe and hoping you won’t get timing conflicts with RF24 e.g. I’d find the data from 2 nodes would merge! Also hardware SPI finally works on the Raspberry Pi.

I’ve updated my weather station scripts, I now have the RPi as the master receiving node0 (with a new 17dBm antenna!); the MOSFET-based Arduino as node1 in the shed, but with the BMP085 pressure/altitude disabled as it was returning absolute rubbish, I think its a hardware issue and not the Adafruit lib; and the older non-MOSFET Arduino as node2 in my office, just reporting its DS18B20 readings in an attempt to prolong battery life – I’ve desoldered the DHT11/BMP085 to see if that helps.

I’ve breadboarded up a node3 that’s powered by a CR2032 coincell and just has the ATmega328P, chip-antenna nRF24L01+, TO92-packaged DS18B20 and two resistors, just to see how the battery life goes. I might even make a 5v board that can be mains powered – or a USB-powered SFE Pro Micro….

My new scripts are here and a graph of the results showing both sensor boards is below: