RuuviBridge: a RuuviCollector replacement with Home Assistant support for Gateway users

Long story short, I finally got my hands on a Ruuvi Gateway and I wanted to use it as a drop-in replacement for my RuuviCollector setup, with better support for Home Assistant so I created this project called RuuviBridge which acts as a “data bridge” between various sources and consumers of data. You can use this software without having a physical Ruuvi Gateway device by using a compatible gateway software, such as the ruuvi-go-gateway.

The basic idea is that there are configurable sources of data, right now it supports polling the Ruuvi Gateway directly (if you don’t have a MQTT server), or subscribing to a MQTT topic where the Ruuvi Gateway is configured to feed the received data (recommended option), but I may add more in the future.

Data from each source is then parsed into a “common format” and optionally processed, by default the processing includes calculating “extended values” such as dew point, absolute humidity, air pressure, total acceleration and so on, which is the same as with RuuviCollector.

After the processing step the data is sent to each configured consumer of data, which include InfluxDB (in RuuviCollector format), Prometheus, and MQTT. The MQTT part optionally includes creating Home Assistant MQTT Discovery topics for automatically configuring the tags as devices with all available values as sensors, with properly configured names, units, icons and other attributes.

The automatically created devices in Home Assistant have data that look like this:

Allowing you to create all kinds of dashboards with ease:

With all relevant attributes properly configured for the entities:

Note that some details are subject to change if I figure out some improvements or someone has some feedback.

Any feedback, improvement ideas and questions are welcome :slight_smile: The documentation is a bit crude at the moment but I’ll be improving it over time.

4 Likes

Very cool! Thank you for this tool.

I gave it a try with MQTT, here are my findings:

My GW publishes under ruuvi/<gwmac>/<tagmac>. With mqtt_listener.topic_prefix = ruuvi it subscribes to ruuvi/+ which doesn’t match this scheme. So I configured mqtt_listener.topic_prefix = ruuvi/+ and that worked (subscribes to ruuvi/+/+).

The result is:

{"mac":":41:E6:67:AA:9C/DD:23:90:34:8F:48","timestamp":1640723174,"data_format":5,"temperature":7.95,"humidity":100,"pressure":96417,"accelerationX":-0.084,"accelerationY":-0.008,"accelerationZ":1,"batteryVoltage":2.749,"txPower":4,"rssi":-67,"movementCounter":32,"measurementSequenceNumber":27675,"accelerationTotal":1.003553685659118,"absoluteHumidity":8.239237400553863,"dewPoint":7.949999999999999,"equilibriumVaporPressure":1068.5843099085037,"airDensity":1.1907614846612853,"accelerationAngleFromX":94.80142042521246,"accelerationAngleFromY":90.45674795227025,"accelerationAngleFromZ":4.823197769093058}

Doesn’t look too bad, but the mac seems to be scrambled. Shouldn’t there be only the mac address of the tag? It contains part of the GW mac.

Probably because of the scrambled MAC address, processing.filter_mode = named doesn’t work with the mac format from config.sample.yml.

Good catch, that was a slight oversight in parsing the tag mac address from the topic, the logic didn’t really account for the use of wildcards in the prefix. That should be fixed now, which should also fix the names and named filter mode not working.

I’ve published a new version, please give it a go and see if it now works properly

Thanks a lot, the new version now works as expected. And thanks for adding proper logging, that makes it easier to so what is going on, although for debugging purposes a few more logs would help.

Two things:

  1. The gateway produces a lot of measurements, every few seconds (that might be the interval the tags send their measurements). This is too much for my use case, I’d only need a measurement every few minutes. Should there be a way to only forward measurements every few minutes (configurable) to sinks, maybe configurable per sink?

  2. While I understand that the main idea behind the project is to forward messages from the gateway, would you also consider adding a bluetooth source? My use case would be to replace the heavy (Java) RuuviCollector at places where I don’t have a gateway running. I’m using ruuvitag-gollector there, but would love to use RuuviBridge to have the same data format available. Running RuuviCollector on a Raspberry Pi Zero is possible, but a pain.

Thanks for the feedback. I’ve released a new version with the ability to limit the update interval for each sink separately. I also did a few improvements in logging, but in general logging will be improved over time as the code structure “stabilizes” and I figure out useful things to log.

A bluetooth source is a bit tricky, as it’s totally platform dependent (depends on the OS, the bluetooth stack used, and in some cases even the bluetooth hardware) and I’d like to keep RuuviBridge as platform-agnostic as possible to allow running it on (almost) any OS.

However I do plan on adding support for some lightweight “3rd party software gateway” implementations, or possibly even implement my own if I can’t find any feasible ones. Requirements being lightweight and publishing the raw, unparsed data like the Ruuvi Gateway does.

Edit:

Actually… I figured a software replica of the Gateway would be rather easy to implement, since it would be just forwarding the raw data without needing to parse it or do any other complicated logic, so I went ahead and created ruuvi-go-gateway

1 Like

I’m now running v0.1.4, and it looks perfect to me! Thank you very much. I’ll give ruuvi-go-gateway a try when I find time, that’s exactly what I was looking for.