Ruuvitag-listener problems with 2.5.9 firmware?

RuuviTag General Discussion
#1

I am interested in logging data from around 20 RuuviTags, probably using a Raspberry Pi Model 3B+. A prototype using the ruuviberry image worked until I encountered problems with influxd running out of memory …

One of the other options I am investigating is ruuvitag-listener. This works fine with the official 1.2.12 firmware in the default RAW mode. However, with the 2.5.9 firmware in the default RAWv2-fast mode no data is seen.

I’m not yet sufficiently fluent in Rust to spot if there is a simple fix. Has anyone else looked into this?

#2

My first guess is that RAWv2 parsing is not supported by that library, but I didn’t find where data is parsed on a quick glance so I’m not sure.

#3

Another option is bt-mqtt-gateway, which uses the ruuvitag-sensor Python package that supports Data Format 2, 3, 4 and 5. I have created a demo here:

This runs fine on a Raspberry Pi 3B collecting data from 4 RuuviTags.

The architecture looks like this:

ruuvitag-demo-diagram
ruuvitag-demo-diagram.png1866×692 110 KB

#4

3B+ should be able to handle 20 tags. Is this Pi running other applications?
I think some tuning should fix this.

What are you requirements for update interval?
What interval are tags transmitting ? 1sec? 5sec?
Have you tried adjusting

ruuvi-collector.properties
measurementUpdateLimit=30000

to reduce the number of insertions into the database.

Are you seeing log messages indicating out of memory ?
How often does the problem occur?
Does it “self-correct”?

You might also look into these settings in /etc/influxdb

wal-fsync-delay = “5s”
cache-max-memory-size = “300m”
query-timeout = “90s”
log-queries-after = “10s”
log-enabled = false
suppress-write-log = true
level = “warn”

retention policy can also have a big impact. See:

#5

Many thanks for the useful comments. I threw this system together in a rush and with very little thought. It’s just the unmodified ruuviberry image and I have left it to do its own thing for a number of months. Worked fine as a proof-of-concept and has produced some useful information on the building’s performance.

I suspect it would be wiser to just use the Raspberry Pi to collect the data from the RuuviTags and forward it somewhere else for longer term storage and analysis! Running grafana-server on the Raspberry Pi accessing data for long time periods may well have been the source of the out of memory issues.

For production hardware it would probably be wise to have some form of UPS to protect the Raspberry Pi from power outages. One possibility might be a PiJuice HAT.

The Ruuvi Dongle might be an alternative to a Raspberry Pi. Note that it only uses USB as a power supply (similar to the ZigBee CAD for Smart Meters which can be used to monitor electricity and gas usage.

For storage of time series data InfluxDB (1.x or 2.x) or Prometheus look like the main options.

For Bluetooth LE scanners bluewalker is another option.

Time for some more investigation …

#6

this is what I learnt as I saw ruuviberry image and was thinking, I would not need half of it.
I using InfluxDB 1.7 (running 2.0 beta concurrently - cannot connect to Grafana - major drawback for me).
Using Node-Red to collect data from tags and pushing data to InfluxDB and Grafana for visualisation.

It was pretty easy in the end. I am using slow mode, as I am looking for data every 5 sec. And publishing to Influx every 5min as I do not need seconds resolution.

Using this in Node-Red

I wanted to run everything in Docker, but because of bluetooth I run all native on raspberry. I could run influx and grafana in docker, but in the end committed that raspberry to these tasks only.

One more thing with Raspberry and SD cards, they will eventually degrade, so if you want to have years of data the database should not be on there.

@koan thanks for sharing looks pretty good

#7

It’s possible to have access to Bluetooth in a Docker container. These are the relevant parts of my Docker Compose file:

  bt-mqtt-gateway:
    image: zewelor/bt-mqtt-gateway
    container_name: bt-mqtt-gateway
    restart: always
    volumes:
      - ./bt-mqtt-gateway:/config
    # These capabilities are needed for Bluetooth
    cap_add:
      - NET_ADMIN
      - SYS_ADMIN
    # The Docker host should have working Bluetooth
    network_mode: host
    depends_on:
      - mosquitto

In short: the container should use host network mode and have capabilities NET_ADMIN and SYS_ADMIN. And of course your host should have working Bluetooth.

#8

mate, I need to try this. I haven’t been able to make it work last time, but it might be more relevant to a noble package and node.js version that actually a docker.

Thanks a lot!! will try and post back, just need to find fresh raspberry board :wink: