I had a similar issue in v0.6 and found that if there was too much interference between once of the sensors where it wouldn’t register messages within the time period, an error was thrown with trying to average rssi. You may have a similar issue, check Supervior->System->log provider>core for any errors around the time the sensors last recorded a value.
Here’s the error messages. Not sure if there’s a conflict with the wyzesense component.
2020-09-13 12:48:45 ERROR (HCISocketPoller) [root] Uncaught thread exception
Traceback (most recent call last):
File “/usr/local/lib/python3.8/threading.py”, line 932, in _bootstrap_inner
self.run()
File “/usr/local/lib/python3.8/threading.py”, line 870, in run
self._target(*self._args, **self._kwargs)
File “/usr/local/lib/python3.8/site-packages/bleson/providers/linux/linux_adapter.py”, line 58, in _socket_poller
data = self._socket.recv(1024) # blocking
BrokenPipeError: [Errno 32] Broken pipe
2020-09-13 12:48:47 DEBUG (Thread-3) [custom_components.wyzesense.wyzesense_custom] Trying to parse: b’55aa5303320187’
2020-09-13 12:48:47 DEBUG (Thread-3) [custom_components.wyzesense.wyzesense_custom] Received: b’55aa5303320187’
2020-09-13 12:48:47 DEBUG (Thread-3) [custom_components.wyzesense.wyzesense_custom] <=== Received: Packet: Cmd=5332, Payload=
2020-09-13 12:48:47 DEBUG (Thread-3) [custom_components.wyzesense.wyzesense_custom] ===> Sending: Packet: Cmd=53FF, Payload=ACK(5332)
2020-09-13 12:48:47 DEBUG (Thread-3) [custom_components.wyzesense.wyzesense_custom] Sending: b’aa555332ff0283’
2020-09-13 12:48:47 DEBUG (Thread-3) [custom_components.wyzesense.wyzesense_custom] ===> Sending: Packet: Cmd=5333, Payload=b’000001748903451a’
2020-09-13 12:48:47 DEBUG (Thread-3) [custom_components.wyzesense.wyzesense_custom] Sending: b’aa55530b33000001748903451a02f0’
2020-09-13 12:48:47 DEBUG (Thread-3) [custom_components.wyzesense.wyzesense_custom] Trying to parse: b’55aa5333ff0284’
2020-09-13 12:48:47 DEBUG (Thread-3) [custom_components.wyzesense.wyzesense_custom] Received: b’55aa5333ff0284’
2020-09-13 12:48:47 DEBUG (Thread-3) [custom_components.wyzesense.wyzesense_custom] <=== Received: Packet: Cmd=53FF, Payload=ACK(5333)
2020-09-13 12:49:14 ERROR (MainThread) [homeassistant] Error doing job: Future exception was never retrieved
Traceback (most recent call last):
File “/usr/local/lib/python3.8/concurrent/futures/thread.py”, line 57, in run
result = self.fn(*self.args, **self.kwargs)
File “/config/custom_components/govee_ble_hci/sensor.py”, line 186, in update_ble_loop
adapter.start_scanning()
File “/usr/local/lib/python3.8/site-packages/bleson/providers/linux/linux_adapter.py”, line 276, in start_scanning
self.set_scan_enable(False)
File “/usr/local/lib/python3.8/site-packages/bleson/providers/linux/linux_adapter.py”, line 132, in set_scan_enable
self.write_buffer(cmd)
File “/usr/local/lib/python3.8/site-packages/bleson/providers/linux/linux_adapter.py”, line 51, in write_buffer
self._socket.send(data)
OSError: [Errno 77] File descriptor in bad state
I just got my H5075. Installed the component through HACS. Can someone educate me on how to find the MAC address?
If you have Windows 10, use Bluetooth LE Explorer from the App store. Once installed, filter by: A4:C1:38
On a Mac – but let me see if i can find something simliar
That’s a new one. Given the time frame between the bleson error and wyzesense debugging information, there is a good chance the is a conflict between the two. I am not familiar with wyzesense, does the camera or hub use bluetooth? Are you recording system resource usage using glances or graphana? If so, how strained is the system at this time?
OK – Still not able to figure this out on osx. I can get the UUID, but not the MAC Address. anyone do this successfully?
Maybe it’s not conflict with wyzesense. I only have the Govee integration installed and nothing else. I also switched from the onboard bluetooth to using a USB bluetooth dongle. Still the same error:
2020-09-14 18:34:43 ERROR (HCISocketPoller) [root] Uncaught thread exception
Traceback (most recent call last):
File “/usr/local/lib/python3.8/threading.py”, line 932, in _bootstrap_inner
self.run()
File “/usr/local/lib/python3.8/threading.py”, line 870, in run
self._target(*self._args, **self._kwargs)
File “/usr/local/lib/python3.8/site-packages/bleson/providers/linux/linux_adapter.py”, line 58, in _socket_poller
data = self._socket.recv(1024) # blocking
BrokenPipeError: [Errno 32] Broken pipe
2020-09-14 18:35:43 ERROR (MainThread) [homeassistant] Error doing job: Future exception was never retrieved
Traceback (most recent call last):
File “/usr/local/lib/python3.8/concurrent/futures/thread.py”, line 57, in run
result = self.fn(*self.args, **self.kwargs)
File “/config/custom_components/govee_ble_hci/sensor.py”, line 186, in update_ble_loop
adapter.start_scanning()
File “/usr/local/lib/python3.8/site-packages/bleson/providers/linux/linux_adapter.py”, line 276, in start_scanning
self.set_scan_enable(False)
File “/usr/local/lib/python3.8/site-packages/bleson/providers/linux/linux_adapter.py”, line 132, in set_scan_enable
self.write_buffer(cmd)
File “/usr/local/lib/python3.8/site-packages/bleson/providers/linux/linux_adapter.py”, line 51, in write_buffer
self._socket.send(data)
OSError: [Errno 77] File descriptor in bad state
I think another process is closing the socket… As you are on a Ubuntu system, I wonder if there there is a service in the background that does periodic Bluetooth scans and blocks the bleson library from finishing. I am not sure. Try downgrading to v0.6 or v0.5 and see if it still persists.
I downgraded to 0.5 and works well for the longest time now. It’s been solid for more than 10 hours now.
Sorry, I am not sure what to suggest other than to stay on that version for now. If anyone else has this issue, we can try to find the similarities in the system to try to find a cause. With all of the possible variables in your set up and not being able to reproduce it, there is not much I can do on my end.
Okay thanks. I’ll stay on 0.5 for now. Thanks for the assistance and nice component!
tl;dr I don’t have anything significant to contribute – just want to say thanks!
First, a huge note of thanks to @Thrilleratplay for awesome work! I picked up four H5075s and absolutely ZERO issues setting them up. FWIW the HA installation is a “bare” Ubuntu system – I had no trouble identifying the Govee’s with a Linux scanning tool (they also showed up on Windows and Android scans as well).
Second, I have BT device tracking set up and it seems the Govee sensors knocked that out, so I followed @Martso’s lead and picked up the external BT dongle. Device id is hci1 – took a few seconds to update the config and restart and now BT device tracking is working again.
Third, I’m a little sad about the RSSI issue (-62 forever) – I dug a bit into the Bleson source but didn’t spot any obvious places where something’s amiss…though the spot where the byte reading is shifted from unsigned to signed and the subsequent logic smelled a bit odd to me:
But it wasn’t obvious that it will always return a constant value (unless the initial value is out of range?), so yeah. 
Fourth, the sensors themselves are all over a small 2-story house, and no signal issues through multiple walls or floor. It’s really a delight when things work!
Cheers,
Matt
PS EDIT: I actually have 1 small bit of advice…the installation instructions on github were a bit confusing re: where “additional options” go in the configuration.yaml, since there isn’t an example of their usage in the README. Took a bit of trial and error to figure out that they’re on the same indentation level as govee_devices. So: maybe add something like decimals: 1 to the example?
Unfortunately, the RSSI issue is not that simple. It isn’t the conversion, the signal itself is returning constant values. This may be due to the socket filtering, an issue with python not properly reading the value or something else. BluePy does a direct connection to the device to read the RSSI value but as the device is scanning, I do not think they occur at the same time reliably.
Darn. I was afraid it was something like that. Oh well I’ll take what I can get! 
I think I found the cause. I entered a PR for the bleson library but it will need to wait until it is verified, merged in and a new package release.
That’s very cool!!! I’m curious to see what you spotted!
It took a while, but I recently was able to grab a screenshot of a decent example (rather than just one or two off readings) that demonstrate the pattern clearly:
In these examples, the not-displayed sensors are non-Govee/non-bluetooth temp sensors, which don’t align with any of the readings of the problematic Refrigerator temp reading. As you can see, the Refrigerator sensor value gets recorded at various points as identical to every one of the other Govee temp sensors (which is definitely not the actual reading).
Rearranging the fridge contents so that there’s less liquids near the H5075 “resolves” the issue. Note that I wasn’t intentionally fixing and recreating the situation in the example, it intermittently continues until the fridge contents are rearranged.
Using v0.5. The Kitchen sensor is an H5075 about 6 ft away in the same room as the Refrigerator sensor. The Upstairs Freezer is an H5074 a foot or two above (same appliance). “Freezer” and “Bedroom” are in other parts of the house (in different directions from the server & bluetooth dongle).
I see what you mean. The only thing I can think of that would possibly cause this is due to you using v0.5, which relies on hcitool and hcidump. Using these were a hack, and basically scrape the stream of data picked up from the hci interface. The packet from a device in the refrigerator may be so corrupt/truncated that the MAC address and packet length messes up the parser and bleeds into the next packet. If this is true, there should not be a recorded value for the kitchen/bedroom temp the same time the Refrigerator temp freaks out.
Interestingly both have entries, though the humidity readings don’t match. In fact the temperature state itself seems to be the only off value (packet id, rssi, battery level seem unaffected).
I’ll try the latest component version next week.
| 17037150 | sensor.refrigerator_temp | -4.2 | {"last packet id": 8389902, "rssi": -88, "battery_level": 79, "last mean of": 26, "median": -20.1, "mean": -20.1, "unit_of_measurement": "\u00b0F", "friendly_name": "Refrigerator temp", "device_class": "temperature"} | 2020-09-15 11:26:23 |
| 17037152 | sensor.freezer_temp | -4.2 | {"last packet id": "F82016D0", "rssi": -59, "battery_level": 86, "last mean of": 27, "median": -20.1, "mean": -20.1, "unit_of_measurement": "\u00b0F", "friendly_name": "Freezer temp", "device_class": "temperature"} | 2020-09-15 11:26:23 |
| 17037151 | sensor.refrigerator_humidity | 67.4 | {"last packet id": 8389902, "rssi": -88, "battery_level": 79, "last mean of": 8, "median": 90.2, "mean": 67.4, "unit_of_measurement": "%", "friendly_name": "Refrigerator humidity", "device_class": "humidity"} | 2020-09-15 11:26:23 |
| 17037153 | sensor.freezer_humidity | 58.6 | {"last packet id": "F82016D0", "rssi": -59, "battery_level": 86, "last mean of": 27, "median": 58.6, "mean": 58.6, "unit_of_measurement": "%", "friendly_name": "Freezer humidity", "device_class": "humidity"} | 2020-09-15 11:26:23 |