For anyone interested, I added a simple debugger to the GoveeWatcher repo that displays the information provided by the govee_advertisement.py
. It can be found here. It is not intended to be used on the same system as this component if this component is active in Home Assistant as the bleson library would create a conflict in the scanning.
This might help some as well with BLE sensors…
I wrote this program to collect BLE temperature and humidity data and publish to MQTT, it also allows you to dump the raw data from BLE type 0 and type 4 advertising packets. It is a c language program, so you will need to compile it on your Linux flavor. I have it running successfully on Raspberry Pi and Intel Ubuntu. The code has several temperature and humidity sensors decoded.
If you have multiple Bluetooth adapters in your machine, you can run multiple instances of the program. However, so other tools like hcitool will not run at same time.
Hello, thanks for the work on this project. I just started and joined the community. I just started yesterday and have a prebuilt HA VM running with all the latest on Oracle Virtual Box. Thru the forum, I was able to find the MAC addresses of my pair of Govee H5101 using Windows Bluetooth LE Explorer. I think I have everything setup. I used your suggestion to execute a “core log” command and I am noticing an error: “OSError: [Errorno 19] No such device”. Screenshot with stack below. I’m trying to figure out next troubleshooting step. perhaps the Oracle Virtual Box vm cannot access the bluetooth? Any ideas on what to check? If I cannot use this vm, this is just a learning experience until the Rpi 4 shows up in the mail soon. That would have bluetooth support built into the HA VM I assume.
Thanks in advance.
I believe in VirtualBox, Bluetooth adapters are filtered by default. It may be considered a USB device depending on your system and would need to be whitelisted in the VM’s settings. On the HA command line, you should be able to see the device by running bluetoothctl list
, if nothing is listed, then it is appearing in the VirtualBox.
Okay, so I was using the onboard Intel bluetooth chip and that was having trouble loading drivers in hassos. I don’t think I can directly run “bluetoothctl list” on this image of HomeAssistant. I may be wrong, but I get an error. Today, I installed a USB Bluetooth and I disabled it on the host OS and whitelisted it in the Oracle VirtualBox settings and restarted. I believe I am past the hardware issues. I just ran a “core log” command again and now it seems to be in the python code to read the sensors, but I don’t get any readings from either of the Govee configured. Several screenshots below to show my configs:
If you could kindly recommend any additional troubleshooting steps to try next?
I seem to get an error “statistics.StatisticsError no median for empty data” in statistics.py
TIA
Have you rebooted the VM since doing this? Not just restarted HA. The kernel module may not load via hotplug. In the command line, can you run lsmod
? You should see something that references bluetooth. Beyond that, I am not sure. This would be a better question for a HA Virtualbox thread. This one may be helpful
I think my image is hass.os which makes it seem I don’t have full linux capability. The lsmod command errors (see screenshot). I did reboot the VM and it definitely seems to be “seeing” the USB Bluetooth device (Cambridge Silicon Radio)… I guess my question is I’m trying to determine how far it is getting. Is it possible for me to add some debug statements to the console? I’m trying to determine if it is even getting as far as scanning for bluetooth devices. I assume my configuration.yaml is simply whitelisting the bluetooth devices that I am interested in. I did read your post about govee_advertiesment.py. Since it seems with this OS, I cannot directly execute scripts, would it be possible to modify any of the scripts like sensor.py to add additional debug statements?
I noticed in sensor.py it has _Logger.debug on line 79. Can you help me figure out what log file may contain these statements? I’m not noticing any statements like on 79 _LOGGER.debug(“Starting Govee HCI Sensor”).
The original error OSError: [Errno 19] ]No such device
indicates it cannot find the Bluetooth adapter. Try to move the thermometer closer and wait at least 15 minutes. The later errors mean it can collect enough information. What version of the component are you using? I thought I fixed that particular error.
I apologize if I wasn’t clear. The original error was using the internal Intel bluetooth. Once I switched to the Cambridge Silicon Radio USB bluetooth, it seems it can hit the scripts.
I’m on version 0.7.1 and my temp sensors are H5101
In case it helps, with the unmodified version of your component, I was getting “statistics.StatisticsError no median for empty data” for my deep freezer since packets were getting processed but all the measurements were getting discarded as spikes (due to being below -20 C (-4 F). Should be easy to reproduce the issue if you temporarily change CONF_TMIN to something bogus that will make all your readings out-of-range.
You were clear, I understood that. If Bluetooth wasn’t scanning it would give an OSError of some sort. Are you running any other Bluetooth HA components? Move the thermometer near the host machine to ensure that it isn’t out of range.
@SteveOnorato Thanks, I’ll try that but I was more surprised that the error still existed and thought I fixed it.
I will try moving closer. Does this apply to BOTH temp sensors? one is outside.
The Integration that comes to mind may be the Alexa integration. I think it may use bluetooth?
No, either one should be enough if the MAC addresses are correct. I don’t think the Alexa Media Player would interact with HA via Bluetooth. Place the one that is inside next to the host. The one outside likely is out of range but until the indoor sensor display data there is no way to confirm it is not another issue…
Thought some might find something of interest in these graphs. I am still doing some analysis of the data and I do have a couple other sensors that I may add to the tests.
Of the sensors I have tried, the units that yield the finest granularity of reading for both temperature and humidity are the Govee H5052 (no longer available) and H5074. The Xiaomi LYWSD03MMC with custom code is at the same level in it’s temperature data, but does not yield the same number of samples for the humidity readings.
This analysis says nothing about the absolute accuracy of any of the readings, it may be possible to extract some relative comparison between sensors.
Okay! After commenting out the outside H5101 in my configuration.yaml, moving the kitchen H5101 directly next to the bluetooth, and doing a full physical laptop shutdown and restart (and restart of HASS.OS)…
Success!!! I can get a reading!!
The weird thing is my iPhone Govee app can read both bluetooth sensors and I am sitting next to the laptop with it. So I’m kinda doubting it is a sensor range issue.
Next step will be to uncomment the outdoor sensor in the configuration.yaml and try again with two sensors configured. It is really cold outside, not sure if that has to do with the statistics.StatisticsError previously seen?
I’ll post what happens.
Okay, so I managed to break it again…
When two H5051 are in my configuration.yaml, I don’t get any readings. That was the only change I made. I did notice an interesting thing in the VM console. Not sure if these files are related?
The error probably killed the polling thread for the component. This component captures the BLE advertisement while the app connects directly via Bluetooth. The difference is that if the app can sync the data from the devices memory if it there is interference. You may want to try the beta release for the outdoor temperature. I am in upstate New York and it is currently 29F outside; the beta version should handle freezing temperatures for the H5101.
The next test I will do is isolation test the outdoor sensor. I will bring it in next to me, 1 foot from the bluetooth USB. I will comment out the kitchen sensor. This will accomplish a few things. 1. It should double confirm the MAC address. 2. It will let us know if it is a distance issue. 3. Depending on its temp reading at the time, it may tell us if it is temp range issue.
Based on what you are saying, it sounds like you may have a fix for the low temps in the beta version? I’ll have to look around for that. I’m assuming it would be on github…
It is starting to point to #2 - a possible distance issue.
Next step is to enable both in my configurations.yaml and see if that works.
At this point, I’m unsure if it is a distance issue or low temp issue…
Okay, so we have success with two sensors now. I’m still unsure if it is a distance thing (since my iphone Govee app can read them from anywhere in the house) or if it was related to low temp.
Thanks for all of your help getting this working!!