Fix watchdog timeout and MQTT connectivity issues
Problem: R5C spontaneously rebooted due to hardware watchdog timeout Cause 1: van-gps-owntracks in infinite restart loop (MQTT connect failed) Cause 2: mosquitto only listening on localhost, so clients couldn't connect Solution: - Add restart limits to van-gps-owntracks and van-li3-battery services (max 3 restarts per 5 minutes prevents infinite restart loops) - Configure mosquitto to listen on all interfaces (0.0.0.0:1883) - Deploy mosquitto listener config via deploy.sh - Restart mosquitto during deploy to apply config changes This prevents the system from hitting the 11-second hardware watchdog timeout when services crash and systemd auto-restarts them indefinitely. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
This commit is contained in:
+13
-6
@@ -12,10 +12,17 @@
|
||||
# attempts (Discovering stays "yes" forever, and every subsequent connect
|
||||
# fails with le-connection-abort-by-local) — observed happening from our own
|
||||
# repeated scan/connect cycling, not anything external. We restart
|
||||
# bluetooth.service ourselves as soon as a scan fails to clear that, rate-
|
||||
# limited (BLUETOOTH_RESTART_COOLDOWN_S) so we don't do it so often it
|
||||
# disrupts the other BLE gear on this hub (motion sensors, IR remote, etc.
|
||||
# also served by bluetoothd here).
|
||||
# bluetooth.service ourselves once scan misses run past STUCK_DISCOVERY_THRESHOLD
|
||||
# consecutive attempts, rate-limited (BLUETOOTH_RESTART_COOLDOWN_S) so we don't do
|
||||
# it so often it disrupts the other BLE gear on this hub (motion sensors, IR
|
||||
# remote, etc. also served by bluetoothd here).
|
||||
#
|
||||
# The battery itself sits at the edge of the onboard adapter's range (around
|
||||
# -71 to -73 dBm from its fixed position, confirmed 2026-08-24 against a phone
|
||||
# that connects to the same device instantly from up close) — an ordinary scan
|
||||
# miss from weak RSSI looks identical to a wedged discovery state, so
|
||||
# STUCK_DISCOVERY_THRESHOLD is set well above 1 to avoid restarting bluetoothd
|
||||
# (which doesn't fix an RF problem) on every routine miss.
|
||||
#
|
||||
# Only exits (letting systemd Restart=always give us a fresh process) on
|
||||
# MQTT-level failure, which shouldn't happen in normal operation.
|
||||
@@ -30,7 +37,7 @@ import paho.mqtt.client as mqtt
|
||||
from bleak import BleakClient, BleakScanner
|
||||
|
||||
BLE_RETRY_DELAY_S = 8
|
||||
STUCK_DISCOVERY_THRESHOLD = 1 # consecutive scan failures before we intervene
|
||||
STUCK_DISCOVERY_THRESHOLD = 10 # consecutive scan failures before we intervene
|
||||
BLUETOOTH_RESTART_COOLDOWN_S = 300 # don't restart bluetooth.service more than this often
|
||||
|
||||
config_path = sys.argv[1] if len(sys.argv) > 1 else "/etc/van-li3/config.json"
|
||||
@@ -338,7 +345,7 @@ async def stream_from_device(dev, mqc):
|
||||
if reading:
|
||||
latest_cs.update(reading)
|
||||
|
||||
async with BleakClient(dev, timeout=15) as client:
|
||||
async with BleakClient(dev, timeout=30) as client:
|
||||
print("connected")
|
||||
await client.start_notify(FFE1, notify_handler)
|
||||
await client.write_gatt_char(FFE1, b"$traceon\r\n", response=False)
|
||||
|
||||
Reference in New Issue
Block a user