I got it back to business. I had to remove the battery about 10 times and then it started to give some other lights than solid red light. So when I removed the battery and put it back, i got just constant red light but I couldn’t connect to the tag. After couple of reset cycle it started to work normally. I got the tag week ago so the battery shoulnd’t be so old.
I believe it was Scrin who observed some time ago that “wiggling” the battery a bit can improve contact if some dust or whatever gets between the battery and the clip. If the contact is bad, the battery can provide acceptable voltage when idle but it will dip substantially under peak loads, like when booting up or transmitting, which can lead to constant rebooting.
That does indeed look odd from 6:00 to 8:30 it looks normal, except that voltage is increasing, which sounds like the load has been smaller at that time. Could be either bad contact with the battery or something really wrong with the tag. Have you tried to gently wiggle the battery clip against the battery surface as well as rotating the battery while the battery is inserted to tag to make sure there’s no excess dust or grease?
So is there working image for this project? Downloaded this two times today and both times i get corrupted zip file
It seems that some programs have trouble with the unzipping The image was zipped on Mac OSX with Keka, maybe I should try zipping with 7-zip
The CRC is actually wrong, some programs just ignore it. Either the zip is actually corrupt, or this Keka does not create proper checksums
I tried using Keka to unzip it. Does not ignore the wrong checksum.
Worse yet, I had a previously unzipped copy of the image and tried it on a brand new Pi 3B (not the B+ that I spoke of in this thread) and the Pi fails to start up.
dbus.socket: Unit lacks Listen setting. Refusing.
Didn’t have ANY issues with the last fresh load of ruuviberry onto a new Pi 3B.
Any ideas? I’ll also research the error logs elsewhere, but thought someone might have already had this experience.
I wonder what has corrupted the image
The image was scheduled to be updated anyway, so I suppose that task got bumped up in priority
Updated image is now available at
MD5 of the zip is f37960e8733d99f7a6c2687452c40f24
and MD5 of the image is 570d489116f91883260900f3e2b64d39
User: pi, password: raspberry.
The Raspberry acts as a WiFi hotspot, SSID “RuuviGW” and password “ruuvi-gateway”.
Grafana user/password is admin/admin .
Port 80 is redirected to port 3000 (Grafana) and everything should start on boot.
Blog post draft detailing on how the tag was set up is at
I haven’t yet had a chance to download, unpack and flash the image to verify the integrity, maybe tomorrow.
The prepared image works fine. For some use cases it may be good to downsample the data.
E.g. after one year with 5 ruuvitags I got problems with the amount of data in the database.
Because I have to search a little bit to get it working, here is an example how to set up downsampling.
In this example the original data will be stored for 7 days, and deleted after this time.
For long term storage 30 minutes mean values of some measurements will be stored.
Step by Step:
Connect to raspberry shell and type influx to start the influx db command line interface.
Switch to ruuvi database
> use ruuvi
Change the duration of the default retention policy to e.g. 7 days. So that after 7 days the detailed data will be deleted.
> ALTER RETENTION POLICY autogen ON ruuvi DURATION 7d
Create a new retention policy for the long term data
> CREATE RETENTION POLICY "forever" ON "ruuvi" DURATION INF REPLICATION 1
Check the results
> SHOW RETENTION POLICIES
name duration shardGroupDuration replicaN default
---- -------- ------------------ -------- -------
autogen 168h0m0s 168h0m0s 1 true
forever 0s 168h0m0s 1 false
Create a continuous query for the data that you would like to store long term.
In this example the mean values of 30 minutes intervalls will be stored for temperature, humidity, pressure and battery voltage
> CREATE CONTINUOUS QUERY cq_30m ON ruuvi BEGIN
SELECT mean(temperature) as “mean_temperature”, mean(humidity) as “mean_humidity”,
mean(pressure) as “mean_pressure”, mean(batteryVoltage) as "mean_batteryVoltage"
FROM ruuvi.autogen.ruuvi_measurements GROUP BY time(30m), mac FILL(null) END
Nice tip and well explained example
Though I would recommend doing everything else first and then alter the default retention policy as the last step, to avoid accidentally losing data while fiddling with those
Isn’t it port 3001? Or did that change in this image?
The grafana default port is 3000, We’re using 3001 in some other applications
Never mind. I must have changed it to 3001 on my very first install and propagated that through my own image when the online image got corrupted. My bad.
However, a note of relevance from the grafana docs if you are deploying sensors in a multi-user environment: “The default Grafana port is 3000, this port requires extra permissions on windows. Edit custom.ini and uncomment the http_port configuration option (; is the comment character in ini files) and change it to something like 8080 or similar. That port should not require extra Windows privileges.”
Thanks for updated image, it works fine now!. Just few observations:
If you have latest Raspberry 3B+ , it is not able to boot with that (http://storage.ruuvi.com/ruuviberry_2018_04_18.img.zip) image. Most straightforward way to get it working is to boot older raspberry with the image installed on Micro-SD card and run
$ sudo apt update
$ sudo apt upgrade
After update, you may boot 3B+ with the card.
Tags work reliably with 3B+, but just as a side note, there seems to be temperature compensation problem with tags. I have one tag monitoring Green House where temperature changes during the night. That seems to affect readings that should be otherwise stable, like battery voltage and acceleration. See graphs (Brown line is Green house, others are inside the house).
(as a new user I have to upload other images in separate posts below)
As you can see Acceleration changes only with GreenHouse sensor but no others (so it’s not moon affecting Earths G).
Is/should Ruuvi use voltage regulator instead of relying on battery voltage, which is known (because of Lithium) to be affected on Temp. In Bosh chip data sheet there is instructions on compensation of readings, are they applied? I haven’t check accelerometer chip data sheets what it says about compensation.
Our tomatoes can live with this error, but if more certainty on readings is needed, one way is to (Temp) calibrate sensors and apply corrections to DB.
Nice work with Ruuviberry image and Ruuvi Collector!
PS: In case someone has Bluetooth problems with PI after using BT keyboard or mouse, you must ‘unpair’ them first, to allow BT adapter to go to HCI-mode. Wireless keyboards etc. are HID devices and cannot be used at the same time (not even configured).
The battery voltage really varies with the temperature, so there is nothing to compensate.
Both humidity and pressure calculation use temperature when converting from raw ADC value to physical value.
Accelerometer is not temperature compensated, as STM does not provide any kind of compensation curve.