1

Raspberry Pi 4 Model B Rev 1.2, Raspbian GNU/Linux 10 (buster)

This is a remote Pi that reads temperature sensors (indoor and out) and posts the results to a web host.

Cha Am Weather

The sensor reading has worked fine for many months and just started to continuously fail yesterday morning:

pi@raspmountain:~ $ sudo hcitool lescan
Set scan parameters failed: Connection timed out
pi@raspmountain:~ $ sudo service bluetooth restart
pi@raspmountain:~ $ sudo service dbus restart
pi@raspmountain:~ $ sudo hciconfig hci0 down
pi@raspmountain:~ $ sudo hciconfig hci0 up
Can't init device hci0: Connection timed out (110)
pi@raspmountain:~ $ sudo hcitool lescan
Could not open device: No such device

pi@raspmountain:~ $ sudo systemctl status bluetooth
● bluetooth.service - Bluetooth service
   Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset:
   Active: active (running) since Tue 2021-08-10 08:53:47 +07; 1min 39s ago
     Docs: man:bluetoothd(8)
 Main PID: 22250 (bluetoothd)
   Status: "Running"
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/bluetooth.service
           └─22250 /usr/lib/bluetooth/bluetoothd --noplugin=sap

Aug 10 08:53:47 raspmountain systemd[1]: Starting Bluetooth service...
Aug 10 08:53:47 raspmountain bluetoothd[22250]: Bluetooth daemon 5.50
Aug 10 08:53:47 raspmountain systemd[1]: Started Bluetooth service.
Aug 10 08:53:47 raspmountain bluetoothd[22250]: Starting SDP server
Aug 10 08:53:47 raspmountain bluetoothd[22250]: Excluding (cli) sap
Aug 10 08:53:47 raspmountain bluetoothd[22250]: Bluetooth management interface 1.1
Aug 10 08:53:49 raspmountain bluetoothd[22250]: Loading LTKs timed out for hci0
Aug 10 08:53:57 raspmountain bluetoothd[22250]: Failed to set mode: Failed (0x03)

I've confirmed that the sensors themselves are working fine from a different Pi:

pi@raspcondo:~/webcam $ sudo hcitool lescan
LE Scan ...
08:66:98:D8:ED:5B (unknown)
08:66:98:D8:ED:5B (unknown)
1A:29:FA:EB:50:D2 (unknown)
A4:C1:38:73:1D:5C (unknown)
A4:C1:38:73:1D:5C LYWSD03MMC
A4:C1:38:69:6C:A2 (unknown)
A4:C1:38:69:6C:A2 LYWSD03MMC

(The two named devices are sensors.)

Because of the Covid lockdown and travel restrictions in Thailand, it is unlikely that I'll be able to visit this place any time soon. I haven't tried rebooting the Pi, yet.

What next?

Improve this question
4
  • I would try to reboot the pi and see if that helps. How did you "I've confirmed that the sensors themselves are working fine from a different Pi:"?
    – Gil
    Commented Aug 11, 2021 at 2:31
  • hcitool is one to tools that has been deprecated so you might want to use bluetoothctl or btmgmt. However I do not think that is causing your problems. You might want to have look at the RPi Bluetooth where there are various issues open around Bluetooth on the Pi 4
    – ukBaz
    Commented Aug 11, 2021 at 6:09
  • 1
    @Gil - There are two Raspberry Pies at this location. Both have reverse SSH tunnels set up between them and my Mac at home. I logged in to the "other" Pi and confirmed via hcitool that the sensors are working.
    – Buadhai
    Commented Aug 11, 2021 at 6:14
  • @ukBaz - I had no idea that hcitool is deprecated. I guess I was following an outdated tutorial. Time to learn some new things.-- As for rebooting the Pi I hesitate to do that when I'm not present. If it doesn't boot back up it will be down until I'm able to get there; possibly weeks from now.
    – Buadhai
    Commented Aug 11, 2021 at 6:24

1 Answer 1

Reset to default
3

If I were to install a Pi which won't be physically reachable later, the first thing I would test is whether it comes back online after a restart.

If you have installed kernel updates during the Pi's uptime, you may need to reboot the kernel so that the kernel you run matches the updated kernel objects that are on the SD card. If you want to avoid reboots in the future, you might refrain from updates, or sudo apt-mark hold linux-image-rpi, though you may miss critical security updates this way.

There's also a chance your Pi got a random RAM corruption since last reboot. There are no provisions on consumer electronics to deal with such events, users are simply expected to reboot.

Improve this answer
5
  • My plan, thwarted by Covid, is to connect each Pi to a HomeKit enabled outlet. If a machine freezes up I can cycle the power remotely. On both of these Pies I have the hardware watchdog enabled. Before I deployed each, I tested the watchdog using a fork bomb to make sure they would reboot. However, my faith in the watchdog was tested recently when one of the Pies simply stopped and only restarted 25 days later when there was a fortuitous power outage. Nothing in any log I looked at gave me a hint as to what went wrong. Also note that I never do updates unless I am physically present.
    – Buadhai
    Commented Aug 11, 2021 at 7:36
  • @Buadhai Are you sure the system was really reset by the watchdog and not simply crashed because of the fork bomb? You could have set max-load-1 to, say, 2, and then exceed that load with e.g. stress --cpu 3.
    – Dmitry Grigoryev
    Commented Aug 11, 2021 at 13:49
  • 1
    @Buadhai Anyhow, if your Pi came back after a power outage, why do you think there will be a problem with sudo reboot?
    – Dmitry Grigoryev
    Commented Aug 11, 2021 at 13:54
  • 1
    In case you haven't guess already, I really don't know what I'm doing here. Anyway, based on your encouragement I rebooted the Pi. It came up just fine and Bluetooth seems to be working again. Thanks for your patience.
    – Buadhai
    Commented Aug 11, 2021 at 21:41
  • 1
    @Buadhai That's great news!
    – Dmitry Grigoryev
    Commented Aug 12, 2021 at 6:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.