ThermoPro becomes unvailable

Configuration
1

Hi all,

I got three ThermoPro TP357S and one TP357 but they all got the same problem.

After some time (sometimes 30 minutes, sometimes a few hours) they become unavailable.

When I restart home assistant, they are available again. But again only for a limited time.

Since one of the devices sits directly on top of the host running home assistant, it shouldn’t be a connectivity issue

I’m using version 2024.1.2.

From the home assistant log:

Jan 06 21:48:39 foobar systemd[2138]: Started homeassistant.service - Home Assistant.
Jan 06 21:49:54 foobar hass[1038170]: 2024-01-06 21:49:54.549 WARNING (MainThread) [homeassistant.bootstrap] Waiting on integrations to complete setup: default_config
Jan 06 21:49:55 foobar hass[1038170]: 2024-01-06 21:49:55.375 DEBUG (MainThread) [thermopro_ble.parser] Parsing thermopro BLE advertisement data: <habluetooth.models.BluetoothServiceInfoBleak object at 0x7f6271025440>
Jan 06 21:49:55 foobar hass[1038170]: 2024-01-06 21:49:55.378 DEBUG (MainThread) [thermopro_ble.parser] Parsing thermopro BLE advertisement data: <habluetooth.models.BluetoothServiceInfoBleak object at 0x7f627102cb40>
Jan 06 21:49:55 foobar hass[1038170]: 2024-01-06 21:49:55.378 DEBUG (MainThread) [thermopro_ble.parser] Parsing thermopro BLE advertisement data: <habluetooth.models.BluetoothServiceInfoBleak object at 0x7f62715919c0>
Jan 06 21:49:55 foobar hass[1038170]: 2024-01-06 21:49:55.378 DEBUG (MainThread) [thermopro_ble.parser] Parsing thermopro BLE advertisement data: <habluetooth.models.BluetoothServiceInfoBleak object at 0x7f62716653c0>
Jan 06 22:42:55 foobar systemd[2138]: Stopping homeassistant.service - Home Assistant...
Jan 06 22:42:57 foobar systemd[2138]: Stopped homeassistant.service - Home Assistant.
Jan 06 22:42:57 foobar systemd[2138]: homeassistant.service: Consumed 1min 29.837s CPU time.
Jan 06 22:42:57 foobar systemd[2138]: Started homeassistant.service - Home Assistant.
Jan 06 22:42:59 foobar hass[1043895]: 2024-01-06 22:42:59.840 DEBUG (MainThread) [thermopro_ble.parser] Parsing thermopro BLE advertisement data: <habluetooth.models.BluetoothServiceInfoBleak object at 0x7fc00d384ec0>
Jan 06 22:43:00 foobar hass[1043895]: 2024-01-06 22:43:00.014 DEBUG (MainThread) [thermopro_ble.parser] Parsing thermopro BLE advertisement data: <habluetooth.models.BluetoothServiceInfoBleak object at 0x7fbfda3b1b40>
Jan 06 22:43:00 foobar hass[1043895]: 2024-01-06 22:43:00.110 DEBUG (MainThread) [thermopro_ble.parser] Parsing thermopro BLE advertisement data: <habluetooth.models.BluetoothServiceInfoBleak object at 0x7fbfda3b2540>
Jan 06 22:43:02 foobar hass[1043895]: 2024-01-06 22:43:02.806 DEBUG (MainThread) [thermopro_ble.parser] Parsing thermopro BLE advertisement data: <habluetooth.models.BluetoothServiceInfoBleak object at 0x7fbfd8a49640>
Jan 06 22:43:05 foobar hass[1043895]: 2024-01-06 22:43:05.073 DEBUG (MainThread) [thermopro_ble.parser] Parsing thermopro BLE advertisement data: <habluetooth.models.BluetoothServiceInfoBleak object at 0x7fbfd9a04340>
1 Like
2

I’m getting the same issue with the same sensors. I just read here that if you run bluetoothctl scan on on your system it would come back online so I tried it and it worked. The debug logs did not show anything going wrong just that the sensor value goes from whatever value to unavailable.

At the moment, I added a cron job on my host to run the above command for 2 seconds every minute. I’ll see if the sensor is showing unavailable later on.

3

I had the same issue and I am using a shelly usb gateway. changing the bluetooth scanning option of the usb gateway from “passiv” to “active” solved the issue for me.