Hi all. Better say straight away that I am very new Ruuvi, not that new to the whole IoT world and far too long a time in IT overall.
I’ve been looking at Ruuvi sensors which I am very impressed with. What I’m less impressed (or really I should confused) about is using Gateways to collect data from the Ruuvi sensors locally and forwarding the data onto some form of Cloud processing system. It seems essential for any real world application, with even just one local sensor, that a gateway of some sort would be required. I get that. However, the implementations (I may well be wrong here, its only what I’ve found so far) mostly seem to rely on a deprecated HCIDump utility wrapped in Python which does not sound like a long term solution to me.
It would be great to build something with a bit more of a future that is light weight. So something that makes the collected sensor data available to other code or just scripts locally to de-couple the collection of the data from sending the data to the Cloud. Thus giving more flexibility in WAN connectivity.
A hardware model for this might be a Pi Zero (with its built in Bluetooth etc) connected to a Hologram Nova USB cellular modem. I’d ideally like to see something that can get data form the sensors and send it on via the Nova. Thus optimising the airtime used on the cellular network and hense the costs. I know that there was one implementation that used the RuuviCollector but this is a bit heavy weight and uses a network connection to an Influx Database so is not WAN de-coupled.
If anyone knows of any projects that fit the bill here, please let me know. Please also let me know if I’ve got this completely wrong :-).
This is a really interesting topic. For me (as a software developer) the most interesting part is the software solution, but hardware solutions are almost as interesting, especially if they are opensource (and thus trivial to write your own versions of firmware for example).
As the creator of RuuviCollector, I am aware of the deprecation of most hci-family of tools under bluez, and in that sense this is a bit of an “unknown time”. As most are not aware, the reason for deprecating some of the tools (hcidump in particular) is the lack of active maintainers, not because there’s a better direct or better replacement. Thus, for most software solutions based on Linux (thus, using the Linux kernel bluetooth stack, bluez) there is no straight-forward option to switch to, at least not yet. Although for controlling, hcitool can be replaced with the D-Bus Device api, but there’s no equal direct equivalent for hcidump, as far as I know. If anyone knows any, please share
For hardware, I’d love to see something in the “Raspberry Pi range” in terms of complexity and price (or actually a bit cheaper even, as the requirements would be smaller), but more dedicated towards this kind of use case than a Raspberry Pi. Wouldn’t really need to run a “complete OS”, nor any “human interface” outputs like display and audio, and instead features like those replaced by features more suitable for this, for example a builtin cellular modem.
Having now read this article https://tobru.ch/ruuvitag-with-c-h-i-p-node-red-influxdb-and-grafana/, I’ve used the underlying idea of Node-Red with Noble and the RuuviTag Node but skipping the use of Influx/Grafana and implementing it all on a Pi Zero. In my Node-Red flow I just write the sensor data out to a file which can then to read by a script that sends the data to a Cloud Server (also running Node-Red) via a Hologram Nova Cellular Modem (https://hologram.io/nova/). Not as light weight as it could be but definitely decoupling the RuuviTag data collection from the WAN side of things. Richard.
By the way, what about the SDCard “problem” of RPI zero? It seems that some months later or some dozens of months SDCard become … “damaged” … or am I wrong? I am still looking for a good HW cheap gateway but no luck until the moment
Another “issue” with Raspberry Pi’s in general is that the voltage feeds are unregulated, so for example using a phone charger that actually supplies a tad over 5V as a power supply is bad for the Pi in the long run, as then the voltage fed to the SD card is a tad over the intended voltage, which is known to break especially cheaper cards over time.
So to maximize SD card life on a Raspberry PI:
Use only “proper” power supplies
Prefer “high endurance cards” (ie. those intended for dashcams)
Try to minimize the writes to the SD card (turn off unnecessary logging etc)
Well Rigado can be counted out as well. I approached them to buy a single gateway on their edge service and they said that I need to show potential to buy many gateways over a short time before I could join up and get one gateway. So much for experimenting with Ruuvi tags …
Thats also my experance with Rigado, and if I remember correct it was also bit on the expensive side.
My goal is 50-100 USD for a wifi/lan based gateway, or 100-150 USD for LTE gateway
I have to agree with you Richard. I purchased RUUVI tags about a year ago and apart from Android app, I cannot do anything else with them.
I thought RUUVI were planning to release iOS version of weather station app and provide a good gateway solution (not raspberry Pi gateway which is unsuitable for commercial apps).
RUUVI should be taking it to the next level with custom gateway and their own cloud server platform. Something like Kontakti are doing.
I think Raspberry Pi looks cumbersome for commercial installs and adding LTE modem is awkward. You need a gateway to look professional like Rigado. Perhaps you can make Raspberry Pi look good with new encloure etc but I have not seen anything here.
Hi Lauri,
Thats good news with new gateway. I just feel that this will take a long time to develop especially if you are using new Nordic nRF91 module. And to make your own unique cloud backend would also be great but again it will take time.
I am talking about what is available right now to keep people interested and get some apps going. The RUUVI tags are great with open source etc but I cannot use them right now for any commercial jobs as they lack a gateway and backend.
It’s true that cost effective complete professional-looking BLE-LTE gateways (especially open-source) are hardly available. RuuviTracker will fix this.
But as we need low-cost solutions today, what about if we would make RPi Zero W as the official RuuviTag BLE-WiFi gateway option? We’ve been thinking about this a while now and have tried to find alternative, “more professional” options. But they all seem to have their cons. Too expensive, only for big businesses, low build quality, shabby closed firmware, no CE/FCC/BTSIG certifications and the list goes on.
So we could make Zero W + official Pi Foundation casing available on Ruuvi Shop.
Maybe even shipped with a pre-flashed SD card which would have Bluewalker (?) + RuuviCollector + InfluxDB + Grafana preinstalled. Or at least we would maintain clear step to step instructions how to set it up.
Hi, I really like the idea of using the Pi Zero W and I have been experimenting with that concept myself. However, as I said in the first post, I would prefer to use a configuration that decouples the sensor data collection from the Cloud data storage. This would allow for GSM connections (Hologram) that do not persists and consume expensive cellular air-time. To this end I’ve been using Node-Red with node-red-contrib-ruuvitag (https://github.com/ojousima/node-red) to collect the sensor data and then send it on to a Web Service directly via WiFi or periodically via Hologram. I also think the setup should be simple so I’ve added RaspiWiFi (https://github.com/jasbur/RaspiWiFi) to allow the Pi to act as an WiFi AP for its initial setup (more work needed here though!). Richard
Ref RuuviTracker. It can act as an LTE gateway among many other things.