oops, thanks @PerseusX my bad. I meant to type H5052, these are the first Govee BLE I purchased and was not able to find again.
Has anyone had success adding a H5055 ble cooking thermometer?
If you are looking for the H5052, you might want to try the H5072. According to Govee, the āH5072 is the upgraded version with more quick and stable data transmissionā Amazon.com: Customer Questions & Answers
Iām quite happy with my two H5072s, which are inside refrigerators. My RPi generally picks up 10-20 samples per minute from each, through multiple walls.
Thanks, @SteveOnorato ! Interesting, I wonder if you have newer firmware in your Govee H5072ās. I have not done any firmware updates to the Goveeās I have as I did some early on with H5052ās and found changes in behavior that seemed negative. And I worried they would do something to make it more difficult to get readings without their app and cloud.
Also, be aware. The rate at which the units take temperature, humidity and pressure readings is different than the frequency at which the units broadcast BLE advertising packets. On top of this is the whole dimension of how many of these advertising packets your ācollectorā sees and captures.
Perhaps a bit hard to get from the graphs, but the H5075, H5102 and H5072 units only seem to update their sensor reading every 5 to 10 minutes, where as the H5052, H5072 and Xiaomi LYWSD03MMC ATC MI update several times a minute.
I posted some other analysis earlier in this thread from my github page. However, here are two additional graphs showing that my Govee H5075, H5102 and H5072 units do not update their sensor reading as frequently as the Govee H5074 (not shown), H5052 (not shown) and Xiaomi LYWSD03MMC ATC MI units. As you see, I went down a real rabbit hole with these sensors. I got the Govee H5052 at a Amazon sale a number of years ago and then they quit selling them, so I tried some of their various other units, H5075, H5102 and H5072. These yielded less frequent updates of sensor readings. I found only the Govee H5074 yielded results as good as the H5052. However it does not have a display and uses and expensive coin cell battery vs. the H5052 with display and inexpensive, cheap and long life 3 AAA alkaline batteries.
Most use cases probably do not need the higher sampling rates, but it was interesting to discover. And they make for nicer graphs
Humidity readings are a slightly different story, but parallel the temperature update rates for all except the Xiaomi LYWSD03MMC ATC MI which updates humidity slower.
The other dimension I found was temperature ranges and accuracy over the ranges. I found the H5052, H5072 and Xiaomi LYWSD03MMC ATC MI to have the widest temperature ranges and accuracy over ranges.
Like you, one of my use cases was to get reading inside a refrigerator and freezer. I found the H5052ās to work great in this use case, but the H5072 did not work below 32 degrees Fahrenheit.
I wonder whatās causing yours to work that way. My H5072 seems to update the reading roughly every 2 seconds (on both the screen and in the BLE packets). I pulled one H5072 out of the fridge and logged the following readings over the course of 1 minute just now. (These are the values that my Home Assistant instance is getting through the BLE packets.)
time temp hum batt (raw) rssi
2021-04-24 00:28:01 4.900000 69.800000 80 (49698) -79
2021-04-24 00:28:03 4.900000 71.000000 80 (49710) -69
2021-04-24 00:28:05 5.000000 72.000000 80 (50720) -77
2021-04-24 00:28:07 5.100000 72.900000 80 (51729) -76
2021-04-24 00:28:11 5.400000 74.800000 80 (54748) -79
2021-04-24 00:28:17 6.000000 82.500000 80 (60825) -75
2021-04-24 00:28:19 6.500000 84.500000 80 (65845) -89
2021-04-24 00:28:26 7.200000 88.700000 80 (72887) -91
2021-04-24 00:28:32 7.800000 91.000000 80 (78910) -90
2021-04-24 00:28:38 8.300000 92.400000 80 (83924) -80
2021-04-24 00:28:40 8.600000 92.600000 80 (86926) -83
2021-04-24 00:28:42 8.800000 92.900000 80 (88929) -85
2021-04-24 00:28:44 8.900000 93.100000 80 (89931) -81
2021-04-24 00:28:48 9.200000 93.400000 80 (92934) -87
2021-04-24 00:28:50 9.300000 93.600000 80 (93936) -87
2021-04-24 00:28:54 9.500000 93.800000 80 (95938) -83
2021-04-24 00:28:56 9.600000 93.800000 80 (96938) -80
2021-04-24 00:28:58 9.600000 93.900000 80 (96939) -85
2021-04-24 00:29:00 9.700000 94.000000 80 (97940) -84
Govee app (which I donāt normally use) says:
Firmware version 1.01.00
Hardware version 1.00.01
Product Model H5072
Thanks for the info, itās good to know that it is possible to get better readings than I am seeing with the H5072. I will have to revisit how I am communicating with those units, as I like the fact that they use 3 AAA alkaline batteries rather than the smaller more exotic types.
Iām trying to set up this integration to make my H5179 work.
I get this error:
Logger: homeassistant.components.sensor
Source: custom_components/govee_ble_hci/sensor.py:206
Integration: Sensore (documentation, issues)
First occurred: 7:36:54 (1 occurrences)
Last logged: 7:36:54
Error while setting up govee_ble_hci platform for sensor
Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.8/site-packages/homeassistant/helpers/entity_platform.py", line 205, in _async_setup_platform
await asyncio.shield(task)
File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/home/homeassistant/.homeassistant/custom_components/govee_ble_hci/sensor.py", line 206, in setup_platform
adapter = get_provider().get_adapter(int(config[CONF_HCI_DEVICE][-1]))
File "/srv/homeassistant/lib/python3.8/site-packages/bleson/providers/linux/linux_provider.py", line 10, in get_adapter
adapter.open()
File "/srv/homeassistant/lib/python3.8/site-packages/bleson/providers/linux/linux_adapter.py", line 31, in open
self._socket = socket.socket(socket.AF_BLUETOOTH, socket.SOCK_RAW, socket.BTPROTO_HCI)
AttributeError: module 'socket' has no attribute 'AF_BLUETOOTH'
I have a Home Assistant Core installation using Python 3.8.6 virtual environment.
I have not seen that error before but it is saying that the HCI device does not have AF_Bluetooth. I am assuming this is running in a Docker container, it is possible that the instance of Home Assistant is out of date. AF_bluetooth was added in to the Alpine python3 package in version 3.8.1. Try updating the Docker image.
This error means that python isnāt built with Bluetooth support. For the BLE monitor integration I added instructions in the faq on how to solve this.
Thatās the same solution I copied it into the FAQ.
The meat thermometer is not supported.
I need some help with this. I recently bought a H5174 (which is not yet supported) and I added support for it (untested/unverified).
I think I am having problems in general getting the integration to work at all. While the āhcitool lescanā command always fails with āSet scan parameters failed: Input/output errorā, which from what I gathered is because my machine has a Bluetooth 5.0 chip, it looks like I am getting the data using the bluetoothctl command, which is what I used to add support for this model.
Anyway, I wonder if Iām running into a bleson bug. It never gets the EVT_LE_ADVERTISING_REPORT
notification, which means āLast mfg dataā always says āNoneā:
homeassistant_1 | 2021-05-03 09:28:32 DEBUG (SyncWorker_3) [custom_components.govee_ble_hci.sensor] update_ble_loop called
homeassistant_1 | 2021-05-03 09:28:32 DEBUG (SyncWorker_3) [custom_components.govee_ble_hci.sensor] Last mfg data for BDAddress('A4:C1:38:XX:XX:XX'): None
homeassistant_1 | 2021-05-03 09:28:43 WARNING (HCISocketPoller) [bleson] TODO: unhandled HCI Event packet, type=HCIPacket(event_name='Command_Status', event_code=15, subevent_code=None, data=b'\x02\x01\x04', length=3)
homeassistant_1 | 2021-05-03 09:29:32 DEBUG (SyncWorker_6) [custom_components.govee_ble_hci.sensor] update_ble_loop called
homeassistant_1 | 2021-05-03 09:29:32 DEBUG (SyncWorker_6) [custom_components.govee_ble_hci.sensor] Last mfg data for BDAddress('A4:C1:38:XX:XX:XX'): None
It seems like Iām getting this bleson āunhandled HCI Event packetā whenever the device sends its information.
Based on btmon output, I am getting BLE message (LE Extended Advertising Report (0x0d)) (which should be EVT_LE_ADVERTISING_REPORT
) from the sensor:
> HCI Event: LE Meta Event (0x3e) plen 53 #115 [hci0] 26.757586
LE Extended Advertising Report (0x0d)
Num reports: 1
Entry 0
Event type: 0x001a
Props: 0x001a
Scannable
Scan response
Use legacy advertising PDUs
Data status: Complete
Legacy PDU Type: SCAN_RSP to an ADV_IND (0x001a)
Address type: Public (0x00)
Address: A4:C1:38:XX:XX:XX (Telink Semiconductor (Taipei) Co. Ltd.)
Primary PHY: LE 1M
Secondary PHY: No packets
SID: no ADI field (0xff)
TX power: 0 dBm
RSSI: -75 dBm (0xb5)
Periodic advertising invteral: 0.00 msec (0x0000)
Direct address type: Public (0x00)
Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
Data length: 0x1b
1a ff 4c 00 02 15 49 4e 54 45 4c 4c 49 5f 52 4f ..L...INTELLI_RO
43 4b 53 5f 48 57 50 75 f2 ff c2 CKS_HWPu...
@ MGMT Event: Device Found (0x0012) plen 72 {0x0003} [hci0] 26.757706
LE Address: A4:C1:38:XX:XX:XX (Telink Semiconductor (Taipei) Co. Ltd.)
RSSI: -75 dBm (0xb5)
Flags: 0x00000000
Data length: 58
Name (complete): GVH5174_0C44
16-bit Service UUIDs (complete): 1 entry
Unknown (0xec88)
Flags: 0x05
LE Limited Discoverable Mode
BR/EDR Not Supported
Company: Nokia Mobile Phones (1)
Data: 0101035caa64
Company: Apple, Inc. (76)
Type: iBeacon (2)
UUID: 57485f53-4b43-4f52-5f49-4c4c45544e49
Version: 30032.65522
TX power: -62 dB
My machine is a Intel NUC7PJYH (which has an integrated Bluetooth 5.0 chip) and Iām running Debian 10 Buster on it. HASS is running in a docker container. It didnāt seem to matter whether itās running privileged or not, setting capabilities also didnāt seem to affect this. I donāt have any other Govee sensors to test with, but I suspect none of them would work.
Is this pointing to a bleson bug?
EDIT: So I think I am only getting these messages because I did a āscan onā in bluetoothctl. When I just restart HASS it seems like it canāt enable BLE scanning:
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #101 [hci0] 65.077794
Scanning: Enabled (0x01)
Filter duplicates: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #102 [hci0] 65.078745
LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Command Disallowed (0x0c)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #103 [hci0] 66.027513
Scanning: Disabled (0x00)
Filter duplicates: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #104 [hci0] 66.027756
LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Command Disallowed (0x0c)
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7 #105 [hci0] 66.027794
Type: Active (0x01)
Interval: 10.000 msec (0x0010)
Window: 10.000 msec (0x0010)
Own address type: Public (0x00)
Filter policy: Accept all advertisement (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #106 [hci0] 66.028752
LE Set Scan Parameters (0x08|0x000b) ncmd 1
Status: Command Disallowed (0x0c)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #107 [hci0] 66.028782
Scanning: Enabled (0x01)
Filter duplicates: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #108 [hci0] 66.029749
LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Command Disallowed (0x0c)
Seems like maybe the problem is what some other projects ran into as well: use le extended commands set if supported by vicamo Ā· Pull Request #30 Ā· frawau/aioblescan Ā· GitHub or Intel NUC problem (RTL8822CE also), LE Set Scan Enable -> Command disallowed) Ā· Issue #61 Ā· custom-components/ble_monitor Ā· GitHub
Maybe bleson needs a similar fix?
EDIT 2: Yep I think thatās the problem, bleson doesnāt properly initiate BLE scanning. Bluetoothctl enables it like this, and it works:
@ MGMT Command: Start Discovery (0x0023) plen 1 {0x0001} [hci0] 944.311994
Address type: 0x07
BR/EDR
LE Public
LE Random
< HCI Command: LE Set Random Address (0x08|0x0005) plen 6 #193 [hci0] 944.312398
Address: 00:29:21:B2:1D:3B (Non-Resolvable)
> HCI Event: Command Complete (0x0e) plen 4 #194 [hci0] 944.426695
LE Set Random Address (0x08|0x0005) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Extended Scan Parameters (0x08|0x0041) plen 8 #195 [hci0] 944.426865
Own address type: Random (0x01)
Filter policy: Accept all advertisement (0x00)
PHYs: 0x01
Entry 0: LE 1M
Type: Active (0x01)
Interval: 11.250 msec (0x0012)
Window: 11.250 msec (0x0012)
> HCI Event: Command Complete (0x0e) plen 4 #196 [hci0] 944.427496
LE Set Extended Scan Parameters (0x08|0x0041) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Extended Scan Enable (0x08|0x0042) plen 6 #197 [hci0] 944.427572
Extended scan: Enabled (0x01)
Filter duplicates: Enabled (0x01)
Duration: 0 msec (0x0000)
Period: 0.00 sec (0x0000)
> HCI Event: Command Complete (0x0e) plen 4 #198 [hci0] 944.429497
LE Set Extended Scan Enable (0x08|0x0042) ncmd 2
Status: Success (0x00)
@ MGMT Event: Command Complete (0x0001) plen 4 {0x0001} [hci0] 944.429590
Start Discovery (0x0023) plen 1
Status: Success (0x00)
Address type: 0x07
BR/EDR
LE Public
LE Random
So, i think bleson needs this implemented: Intel NUC problem (RTL8822CE also), LE Set Scan Enable -> Command disallowed) Ā· Issue #61 Ā· custom-components/ble_monitor Ā· GitHub
I wrote up a bug for this: "LE Set Scan Enable" fails with "Command Disallowed (0x0c)" on some hardware Ā· Issue #84 Ā· TheCellule/python-bleson Ā· GitHub
While bleson is a rather well liked and well written library, the author has indicated that he either does not have enough time to devote to it or is busy with other projects. Unless a pull request is submitted, I do not think this will fix but I could be wrong.
In either case, I am looking into replacing bleson at some point with another library that does nonblocking BLE scanning to allow other Bluetooth components to be installed along with this one. At the moment I am trying to finish up a few bug fixes and then will start on a rewrite that will incorporate many of the features @PerseusX has and hopefully can find a library that will fix the Intel NUC issues as well.
Iāve got a NUC with Home Assistant setup in KVM. I was able to pass through the onboard bluetooth to my VM through USB pass through. I was surprised it showed up in the USB host device since it is onboard, but it worked nonetheless. I can see the bluetooth controller through the HA terminal using bluetoothctl and I even did a scan to find my Govee BLE device (H5075) all within HA. The problem I am having is that the integration doesnāt appear to be connecting to my bluetooth controller since I am getting unknown statuses for both temperature and humidity. I wonder if it has something to do with my hci_device setting? I have mine set to the default of hci0, but based on the bluetooth controller information I have in the attached picture, I donāt see where hci is mentioned anywhere. Does anyone know what I might be doing wrong here?
You are likely running into the exact same problem I ran into, see 2 posts up. Unfortunately, thereās no fix or workaround for this, currently.
Thanks for the reply. Yea, I think I am running into the same issue. I searched this forum trying to find an answer first, but I clearly used the wrong keywords and should have read what you wrote 2 posts up!
Hi all, very new to HA but figured out forwarding my bluetooth dongle to use a H5074 and used a linux virtualbox to find MAC address, happy to help others with that if they need help.
I added the sensor, humidity % works, but temperature says unknown. Any ideas? The freezer temp is -5 degree F currently, is there a range that I am outside of, is that why its returning UNKNOWN?
Also, could someone give me a quick guide on how to have alexa or google home say āthe freezer is too warmā every 5 minutes if temp is above for example 5 degrees F?
Joe
The default minimum temperature is -20C/-4F. The latest version allows you to change this. Given those are the default values for rounding
, decimals
, period
, and use_median
, they can be removed if desired. Try the config:
sensor:
- platform: govee_ble_hci
temp_range_min_celsius: -30
govee_devices:
- mac: "E3:60:59:41:E4:74"
name: Freezer
If you are still occasionally receiving āunknownā values, add log_spikes: True
, which should display the value it received.