I finally received my Ruuvitag sensors from the Kickstarter campaign a few weeks back. Everyone else seemed to get theirs months before (boohoo) but finally they did arrive. So now that I had them, what could I do with them? After a few weeks of finishing Lennu Run, I had the time to try them.
EXECUTIVE SUMMARY: If you just want the pretty pics and the link to go play Lennu Run, skip to the end. If you like pages of digressing nerd-talk, keep reading all the way.
I was mainly interested to try prototyping some “smart home” type stuffs with them. There was a post before on the Ruuvitag site about how someone had set up collecting the data into InfluxDB and visualizing with Grafana. Since that has recently been my setup for IoT/timeseries data collection and visualization, I figured that sounds like a good start. As it was implemented in Java it made it even better suited for me. Because I know it well.
So I got myself a Raspberry Pi 3 box with all the twinkies to go with it. To act as the Bluetooth hub to collect the measurements from the actual sensor tags and push into the actual database. I run InfluxDB on another host in my network, along with Grafana. So there.
Installed Raspbian on the Pi, downloaded the Ruuvi Collector code from Github. Tried to compile it and make it run. It uses some command line tools called “hcitool” and “hcidump” to collect the data from the tags (over Bluetooth Low Energy – BLE). What a weird way to do stuff – parse command line processes from a Java program. One would think proper Bluetooth support would exist in Java but then again one would think many things that are never true. If it works and is free.. My thanks.
Of course, being a nerd I just had to fork it and change it in multiple non-essential ways just to see how it works and to pretend to simplify it for myself. See Github.
Anyway. Raspbian was used in the Ruuvi Collector example as a hub, so I used it. Of course, the hci-tool versions on Raspbian are old and outdated, and the Ruuvi Collector website actually mentions you should upgrade them. OK, can’t be that hard can it? Yes it can.
Newer versions are not in the Raspbian repositories. Downloaded the sources for the packages online, after lots of messing around, finally got them to compile. Overall, a bit more complicated than I was looking for, and could not get them to work. No idea why really, and no time/resources to debug the source code. Others had some issues as well, so no go for me. Nice. I though RPi was supposed to be easy and nice way to do all this stuff for dummies like me. Obviously, I thought wrong.
Alternatives? People on the internets talk about using on “stretch” version of Raspbian which uses newer versions. Stretch seems to be some kind of a testing branch of the OS distribution. There is some mention about just taking the BLE packages from there and leaving the rest as the Jessie version (the current version of Raspbian). Others complain about potential to mess the system up. So why don’t I just upgrade my RPi to stretch as a whole? Because.
I then ran the whole Stretch upgrade to make my Raspbian upgrade fully to the stretch version. I figured all dependencies would better work and all. Haha. First off, the Raspbian desktop changed so I no longer could even find where to configure wireless connections (wifi/bluetooth). Somehow my previous configs still seemed OK as wifi worked so just SSH in and try it. “hcitool” and “hcidump” both were also installed and new enough versions. I also upgraded the kernel with rpi-update just to be sure. So am I all set? Of course not.
The hci-tools complained about not finding the BT device. So install a bunch of BT packages for Pi. No more errors. But running the command line tools, I expect they should dump BT traffic out. I see no data at all. How nice. Tried to fix that with all sorts of tricks for half a day. Then I had enough and re-installed Raspbian to the Jessie version. Found some links to instructions by the Ruuvi Collector author (scrin) on Ruuvi Slack about only downloading the bluetooth packages from the stretch repo and leaving the rest as is. After doing that, the tools were finally right versions and they actually see some data. How nice.
Some useful commands in this process:
Give the commandline tools the needed permissions (from RC site):
sudo setcap 'cap_net_raw,cap_net_admin+eip' `which hcitool` sudo setcap 'cap_net_raw,cap_net_admin+eip' `which hcidump`
If the RuuviCollector keeps exiting with no message, try these (the collector should tell you to do so):
hcitool lescan --duplicates hcidump --raw
Running these, you should see all sorts of live captured bluetooth data printed on the console. As I mentioned, I had issues with various versions of the hci-tools. Even if you get no errors running these two commands (hcitool and hcidump), it does not mean the hci-tools would not have issues. I initially got errors trying to run these two commands. After various fixes, they would start but not log anything. So no errors but no data either. Only after installing the Raspbian Stretch hci-tool versions on top of otherwise plain Raspbian Jessie install they started to print all the BT traffic, and I figured they were finally working.
Also, might be useful to try (just in case missing some BT stuffs from Raspbian):
sudo apt-get install pi-bluetooth
Install InfluxDB somewhere with a network connection accessible from the Pi to have a place for the data. Really very simple to do (even for me), so no big instructions here, the link is good.
To keep the Ruuvi collector running, install the “screen” command on Raspbian and create the virtual screen to keep the RC running:
sudo apt-get install screen screen -S ruuvicollector
To get the stretch versions of the BT packages and the hci tools (yes, I used emacs):
sudo emacs /etc/apt/preferences.d/jessie.pref Package: * Pin: release a=jessie Pin-Priority: 900 sudo emacs /etc/apt/preferences.d/stretch.pref Package: * Pin: release a=stretch Pin-Priority: 750 sudo emacs /etc/apt/sources.list.d/jessie.list deb http://mirrordirector.raspbian.org/raspbian/ jessie main contrib non-free rpi sudo emacs /etc/apt/sources.list.d/stretch.list deb http://mirrordirector.raspbian.org/raspbian/ stretch main contrib non-free rpi sudo apt update sudo apt install bluez -t stretch sudo apt install bluez-hcidump -t stretch
After all this was finally running, I updated all my Ruuvi tags to the latest Weather Station firmware, set them to high-precision mode (press the B button inside the Ruuvitag so the faint red led blinks twice a second), and tagged them (with pencil on cover) with their MAC address so I know which one is which, and deployed them around the house. In the fridge, the freezer, the living room, outside, and in the sauna. The basic dashboard looks something like this:
I picked up the use of grouped SingleStat panels with Sparklines for nice effect from scrin’s dashboards. (S)he also has some nice stats panels there, should look into those as well someday. There is a bunch of interesting information to be had from these measurements and dashboards by moving the tags around the places they are in, measuring temperature, humidity, pressure etc around different places in appliances and stuffs. And figuring out why the temperatures seem too high only to find there must be something wrong but not with the tag..
Perhaps more interestingly, I figured it would be nice to try something a bit different as well. So I was hoping to use the sensors not just to capture temperature, humidity and air pressure. But also use the accelometer to capture some events.
Looking at the accelerometer numbers, I couldn’t quite understand the readings at first. They were anything from 0 to 1 even if you don’t move it / accelerate at all. Again, scrin tried to explain it to me on the Ruuvi Slack. The important thing to get, I guess, is simply that the change in those values is what matters, not what the reading is so much. Or maybe sometimes it is, I just don’t get them so well. Software nerd-alert. Some graphs from playing with a tag below:
Here, the tag was initially on level surface with the bottom down as you might expect. At point 1, I flipped it upside down (belly up). This moved Z acceleration value from 1 to -1 while X and Y stayed constant. At point 2 I turned the tag on its side. At points 3 and 4 I rotated it on its side a bit each time. What do those changes mean? I have no idea! But it moves! It rotates! Ooh.
I put the fridge temperature monitor in the fridge door, on one of the door shelves. I figured maybe I could use the accelometer to capture the door movement to see when the fridge is being used and when not, or how long the door is open. By capturing the spikes in the acceleration of the sensors as the door is opened and closed. Probably the profiles would also look different as the opening usually is a bigger jerk than closing. Some graphs of the experiment below.
I highlighted two red areas where in the first one I was opening the door and in the second one I was closing it. You could very well set up some nice algorithms from these, and integrate them into the data-stream to get the events. But the results were not consistent. Quite often it would miss the door being opened.
After trying for a bit and asking some questions on the Ruuvi Slack, I figured it does not work quite this way. The accelerometer only captures changes in the movement speed. And even at the high-frequency setting, the sensor is only capturing the data twice a second. So if you start to pull the door open in between, nothing shows in the accelerometer graph. The tag is steadily moving before and after the initial pull, but not accelerating any more. So I guess unless the measurement polling happens just at the time of the initial pull, the curve just stays flat.
I also tried to set the sensor in the door shelf on its side, as it is round, so it would roll a bit when the door is opened and give some acceleration readings. The graph showing one such event is below. So if I managed to get the sensor to roll, the event is bigger. But again this does not happen all the time.
What else could I play with?
I tried to take one of the tags and set it hanging from a string/ribbon. Then simulate some wind to see if it would work to measure wind speed with the accelerometer. So like the fridge door where you get the relevant temperature, humidity, and air pressure anyway and just want to play with the potential acceleration as well. See my awesome setup below.
See. At least I made it hang from a fancy ribbon. Of course I did not leave it by the door or the wall. So I let it hang freely and tried to put a fan on it. Turns out I don’t have any good fans (breaking news..). So I asked the kids to blow on it. The figure below shows the accelerometer readings for this.
On mark “1” is the first bigger blow. Mark “2” is when they tried to say BOO to it, and blow on it very gently. Maybe the tag got just a bit scared? Mark “3” is the final attack and boss fight. Or something like that. Verdict. Plausible. A reference wind speed meter would be nice for tuning the algorithms for the data though.
Finally, I also thought about putting the tag in a water, leave it floating, and see if it could catch any interesting readings, such as a water drops falling on it at different rates using the accelerometer (rain). Water temperature? Or a sail boat? 🙂 See below, at least it floats. Not by much but anyway.
So it all seemed good to go for a short while with a very flat line. Then the flatline got really flat, and I got no readings any more. So I figured I drowned it and it is dead. Fished it out and it started pushing readings immediately. I guess water kind of blocks radio waves and bluetooth very nicely. I am just a software nerd so what do I know. But it’s nice to play with toys. Thats what I keep telling myself..
Anyway, for illustration, see the lines below. The highlighted blue parts are where the silence happened. First time when I was testing it, second time when I put it back after to take pics. ’cause Pics or It Didn’t Happen. The general dottiness is generally just how the tag sends data, some packets don’t seem to make it or so. The other graphs I put here are just using connected mode in Grafana to bridge the gaps.
Overall, I would say the Ruuvi tags are a nice way to meter your house and surrounding areas. Quite a bit of setup to get all this to work still. Ruuvitag was actually very easy to take into use and update. Just the Raspbian bluetooth side was a load of trouble.
The more interesting internet of things has to wait a bit still I guess. Maybe it will start with my HP printer that has this nice feature of opening up an unsecured WIFI hotspot that cannot be disabled unless you disable the whole Wifi in it. Well, the Ruuvis are only broadcasting so better on that sense at least.. Although I have no idea about the security of the Ruuvi Collector either.. 🙂