I updated my RPi3B+ by doing sudo apt update and sudo apt full-upgrade. As a result, the collector went a bit bonkers and wouldnât start at all because something went missing. I installed things according to the blog post which demonstrated creating the system.
Everything seems to be working, the service runs just fine upon reboot. However, it will not collect any data.
â ruuvicollector.service - RuuviCollector Service
Loaded: loaded (/etc/systemd/system/ruuvicollector.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2020-09-03 20:59:55 EEST; 34min ago
Main PID: 473 (java)
Tasks: 14 (limit: 2065)
CGroup: /system.slice/ruuvicollector.service
ââ473 /usr/bin/java -jar /home/pi/RuuviCollector/ruuvi-collector-0.2.jar
ââ709 hcidump --raw
Sep 03 20:59:55 ruuvicollector systemd[1]: Started RuuviCollector Service.
Sep 03 21:00:01 ruuvicollector java[473]: 2020-09-03 21:00:01.858 DEBUG [Config] Tag names: /home/pi/RuuviCollector/ruuvi-names.properties
Sep 03 21:00:01 ruuvicollector java[473]: 2020-09-03 21:00:01.897 DEBUG [Config] Config: /home/pi/RuuviCollector/ruuvi-collector.properties
Sep 03 21:00:02 ruuvicollector java[473]: 2020-09-03 21:00:02.417 DEBUG [Main] Starting scan with: [hcitool, lescan, --duplicates, --passive]
Sep 03 21:00:02 ruuvicollector java[473]: 2020-09-03 21:00:02.441 DEBUG [Main] Starting dump with: [hcidump, --raw]
Sep 03 21:00:02 ruuvicollector java[473]: 2020-09-03 21:00:02.486 INFO [Main] BLE listener started successfully, waiting for dataâŚ
Sep 03 21:00:02 ruuvicollector java[473]: If you donât get any data, check that you are able to run âhcitool lescanâ and âhcidump --rawâ without issues
Sep 03 21:01:02 ruuvicollector java[473]: 2020-09-03 21:01:02.482 INFO [Main] Successfully reading data from hcidump
If I now run hcitool lescan in terminal, data collection starts immediately.
If I close the ssh connection and open a new one, hcitool lescan gives me an error: Set scan parameters failed: Input/output error.
It suddenly started working after launching sudo systemctl enable ruuvicollector.service one more time in terminal. After reboot, still collecting data. A really weird thing because the service was already enabled and running.
I have an RPi Zero W running Ruuvi-collector, Influxdb and Grafana with 10 Ruuvitags spread around my house. After moving the RPi to a better location it has been running flawlessly (for my purposes - Iâm only grabbing a reading every 5 minutes) for several months.
On Saturday night I decided to do an apt upgrade-full and all was fine (or so I thought) but clearly I forgot to check my dashboard after the reboot until the early hours of this morning to find I had a similar issue to the op. Nothing had been logged since Saturdayâs reboot.
Unfortunately the fix above didnât work for me.
It took a little while to troubleshoot (partly because I was doing it from my phone using ConnectBot) but after working fine for months it seems that the Pi user that was running the service was no longer allowed to collect the data.
Started the Ruuvi-collector service and everything was working again.
Itâs odd that a user that did have enough rights to run something then had those removed as part of an update, but Iâm pleased that I got it working again and only lost about 32 hours of readings.
As it happens, I also upgraded the system over the weekend and the measurements stopped. I think it may have something to do with one of those bluetooth packages which were also updated this time.
I donât know what finally made it work, running hcitool lescan or running the .jar package manually worked and got the measurements to the database but after a reboot, nothing would happen.
I just used systemctl to stop, start, disable and enable the ruuvicollector.service many times and at some point, things started working. Iâll have to test your method the next time I have this issue.
I run the upgrade every now and then as a security measure. Grafana and InfluxDB actually run on my PC, I use RPi just to talk to the tags and collect data, then send it over the network to the database.
I didnât try those commands that you mentioned, so I donât know if they would have helped.
Puuteknikko seemed to not have any luck with them.
It was useful to know that I wasnât the only one caught out by this. I too suspected one of the Bluetooth packages.
Just like Puuteknikko I do updates occasionally for security reasons mainly, although this isnât technically necessary as my Pi isnât accessible from the internet (I donât publish anything externally). So I guess this may be one of those situations where if it isnât broken, donât fix it.
Amusingly my main task on Saturday was to create a Test Debian VM on my PC which is as similar to the Pi as possible, so that I could test backing up and restoring the databases for InfluxDB and Grafana. Updating the Pi was just an after thought while I was logged in.
I am planning to see if Grafana 8 will break any of my dashboards and will upgrade to that if it works.
I know this is a pretty old thread, but I figured Iâd comment. I also had grafana running and randomly it stopped collecting the data after an update. I donât know which update as I did a âset and forgetâ setup. When I rebooted it wasnât collecting data, so I manually ran hcitool lescan (as root) and it returned data as expected and noticed the collector started going again, so I forgot about it for a while. My battery went out on one of my devices and roughly around the same time(coincidence), my service stopped collecting data again, but from all 3 tags, not just the one with the battery change. I tested the hcitool and hcidump and both are not running properly from the pi user. I added pi to the bluetooth group and still nothing. I didnât want to spend too much time troubleshooting it, so I updated the service script to run as root instead of pi and I also now see the âSuccessfully reading data from hcidumpâ and grafana showed the data immediately. This is a raspberry pi not running anything critical, so Iâm not opposed to having root run a java application.
I can make things work again by running sudo systemctl stop ruuvicollector.service and sudo systemctl start ruuvicollector.service. After this the system survives a reboot as well.
lyghtkruz said" I tested the hcitool and hcidump and both are not running properly from the pi user." The setcap should fix that.
+++++++
What did you upgrade RPi from ?? to??
What Model RPi do you have?
First I would add RestartSec=300
to /lib/systemd/system/ruuvicollector.service to prevent rapid restart upon failure .
I have had better luck with a script starting RuuviCollector which waits for influxd to be ready.
changing the ExecStart
to ExecStart=/home/pi/RuuviCollector/RuuviCollector
#!/bin/bash
# sudo systemctl start ruuvicollector
cd "${0%/*}"; pwd
logger -p daemon.notice " ++ /lib/systemd/system/ruuvicollector.service:ExecStart=/home/pi/RuuviCollector/RuuviCollector pwd=$PWD"
# Restart=always;RestartSec=300. <- This causes systemd to restart this script incase it fails so ...
# To disable RuuviCollector: edit this script: change echo and logger to say NOT start and uncomment out the exit 0
# then sudo systemctl stop ruuvicollector
echo ++ Did start /home/pi/RuuviCollector/RuuviCollector
logger -p daemon.notice " ++ Did start /home/pi/RuuviCollector/RuuviCollector"
##exit 0
########### Wait until influxdb is ready by issuing a simple select #####################
for(( i=1; i<30; i++ )) # wait 19+5 * 30 = 12 minutes before giving up
do
# It may take 27 seconds if influxdb is running # 1/14/19 on Raspberry Pi Zero took 11 minutes before influx was ready accept a connection
# It takes 19 seconds to timeout if influxdb is not even running
/home/pi/RuuviCollector/startupQuery.sh
rc=$?
if [ $rc -eq 0 ] ; then logger --priority daemon.info "++ ruuvicollector: influxdb now accepting transactions"; break; # loop and go
else logger --priority daemon.info "++ ruuvicollector waited for influxdb $i times, rc=$rc and still waiting"
sleep 5
fi
done
if [ $rc -ne 0 ] ; then logger --priority daemon.emerg "++ ruuvicollector gave up waiting for influxdb"; exit $rc; fi
#############################################################################################
# Since sudo systemctl stop ruuvicollector issues TERM ; trap that here to generate log entry
trap 'logger --priority daemon.alert " ++ /home/pi/RuuviCollector got sig TERM" ;exit 15' TERM # will exit with x'80' + 15 i.e.143
trap 'logger --priority daemon.emerg " ++ /home/pi/RuuviCollector got sig QUIT" ;exit 3' QUIT
java -jar target/ruuvi-collector-0.2.5.jar
rc=$?
logger -p daemon.notice " ++ /home/pi/RuuviCollector/RuuviCollector exited with rc=$rc"
exit $rc
As you can see Iâm seriously into logger. I route most of syslog to a common server in addition to /var/log.
/home/pi/RuuviCollector/startupQuery.sh
#it's the return code we're interested in
echo "select last(temperature) from ruuvi_measurements tz('America/New_York')" | influx -database ruuvi -precision rfc3339
