Govee H5075 Issue

[jchang10]

Hi, I just started experimenting with BLE. I wanted to provide some feedback on my one and only device. ;) The Govee H5075 seemingly worked fine with passive BLE monitoring in home assistant, so I was hopeful.

I tried the ESP and was not having any luck. It took me a while to understand that Home Assistant WAS getting the data packet, but it was just dropping it.

It looks like the ESP data packet is about 30 bytes longer or so than what just using passive was using. I have not yet looked into why on the passive side yet (there is a lot more code there to sift thru). However, looking at the much smaller ble_gateway.cpp file. I noticed this.

https://github.com/myhomeiot/esphome-components/blob/aa1b7a8c8d1dec5b963ec33ad74029777b7556f0/components/ble_gateway/ble_gateway.cpp#L27-L31

Looking at this line, basically the valid data is all up to scan_result.bda[2]. Scan_result.bda[1] and [0] seems to be garbage to me. However, because the 2 garbage structs are sent to passive in the data packet, and the way that passive reads the last bda[1] (which is the garbage one and ignores the good one bda[2]), the packet gets dropped.

Thus, I wonder if there might be something else that this function above could do to mitigate these kinds of errors. It seems that bda[0] to bda[5] are all written out regardless if the values are valid or not?

I hope this makes sense to someone. I am just starting out, so thank you for the attention!

Jae

[myhomeiot]

Hello, bda[] contains the MAC address of the device, you can count it's as a garbage but without it Passive BLE Monitor can't identify device.

BLE Gateway doesn't do anything except forming HCI BLE packet using data from BLE advertisement packet and some extra flags like RSSI, event type, etc. So if you have a problem recognizing your device or parsing the data, open the issue in Passive BLE Monitor repo and provide information about device and packets which you get using BLE Gateway.

But before doing this, be sure that MAC address of your device, data from which you passing is defined in Passive BLE Monitor configuration, if it's not defined BLE Monitor will drop the packets from device which is not configured to monitor.

Regards

[jchang10]

Hi. Thanks for the quick reply! Yes, the MAC address and the common name all coming thru fine, In fact, these are all coming thru in this order: mac, common name, uuid, and the sensor values. I guess that would be bda[5], bda[4], bda[3], and bda[2] for those values.

It starts getting strange and bad starting with bda[1]. Once passive sees the garbage in bda[1], it assumes the entire packet is bad, even though it received everything else fine. Passive just did not know to stop processing I guess.

Thus, for now, I just hacked a line in passive to stop processing the garbage struct and process what it has. In this way, at least my little Govee temp sensor can hobble along.

Yeah, I thought in principle the "gateway" function should be straight-forward, but I as surprised to see differences in the way passive processes packets vs the way the gateway does it. I dont understand things enough to give more than that. I was just hoping it might trigger some other suggestions.

Ill add a comment on the passive side, too. I was surprised to see how busy their scan code is. After adding a couple of debug print statements, I realize one thread is just in a fast busy loop processing BLE packets, seemingly infinitely. Not sure what that is about.

[myhomeiot]

Passive BLE Monitor designed to get data from Bluetooth adapter which gives data in HCI format, ESP doesn't get Bluetooth data in HCI format, so BLE Gateway wrap the data with HCI header for Passive BLE Monitor. You can see the BLE advertisement data in scan_result.ble_adv all rest it's a HCI header.

I think if you provide raw packet data from your device in issue of Passive BLE Monitor @Ernst79 will be able to help you and fix parsing for your device.

[Ernst79]

Yep, just send me the packet that you pass through to BLE monitor and i can have a look for you, what is wrong

[Ernst79]

@myhomeiot I analyzed the data, and I noticed that the forwarded message contains two "manufacturer specific data" packets. I'm not sure if this is or isn't allowed in the BLE specifications, can't find it in the docs. Do you know if these double "manufacturer specific data" packets are from one BLE advertisement from the sensor, or are they joined together by BLE Gateway?

Below my post in the BLE monitor issue, for the analysis. Might be interesting to understand where the issue is.

If I convert your packets to a hci string, you have the following strings.

043e2b02010000116c2438c1a41f0d09475648353037355f36433131030388ec02010509ff88ec0003329c6400d9
043e4602010000116c2438c1a43a0d09475648353037355f36433131030388ec02010509ff88ec00012d6e64001aff4c000215494e54454c4c495f524f434b535f48575075f2ffc2b3

The first parses fine, where this "manufacturer specific data" part 09ff88ec0003329c6400 is used to get the measurements

result  ({'firmware': 'Govee', 'temperature': 20.9564, 'humidity': 56.4, 'battery': 100, 'rssi': -39, 'mac': 'A4C138246C11', 'type': 'H5072/H5075', 'packet': 'no packet id', 'data': True}, None)

The second results in an error and contains two "manufacturer specific data" parts.

09ff88ec00012d6e6400
1aff4c000215494e54454c4c495f524f434b535f48575075f2ffc2

What goes wrong in the parser is that it the second part is overwriting the first part, before it is parsed.

[myhomeiot]

@Ernst79 The BLE Gateway copy BLE packet data as is but I will take a closer look inside ESPHome BLE code and maybe I find something.

@jchang10 Can you post here the log from ESPHome which contains 4-5 raw packets from device?

[jchang10]

Hi. Sure. Here is a straight copy and paste. There must be some other BLE devices, but unknown by me. The Govee was the identified mac 'A4:C1:38:24:6C:11'.

`[16:54:40][D][ble_gateway:063]: [A4:C1:38:24:6C:11] Packet 043E4602010000116C2438C1A43A0D09475648353037355F36433131030388EC02010509FF88EC00033DE664001AFF4C000215494E54454C4C495F524F434B535F48575075F2FFC2B2
[16:54:40][D][esp32_ble_tracker:720]: Found device CC:F4:11:87:0C:D1 RSSI=-91
[16:54:40][D][esp32_ble_tracker:741]:   Address Type: PUBLIC
[16:54:45][D][esp32_ble_tracker:720]: Found device C5:1E:63:C6:F8:7E RSSI=-79
[16:54:45][D][esp32_ble_tracker:741]:   Address Type: RANDOM
[16:54:46][D][esp32_ble_tracker:720]: Found device 07:69:D7:F3:3F:57 RSSI=-91
[16:54:46][D][esp32_ble_tracker:741]:   Address Type: RANDOM
[16:55:01][D][esp32_ble_tracker:720]: Found device D7:26:2D:A1:9C:FE RSSI=-93
[16:55:01][D][esp32_ble_tracker:741]:   Address Type: RANDOM
[16:55:25][D][ble_gateway:063]: [A4:C1:38:24:6C:11] Packet 043E4602010000116C2438C1A43A0D09475648353037355F36433131030388EC02010509FF88EC00033DE864001AFF4C000215494E54454C4C495F524F434B535F48575075F2FFC2B8
[16:56:05][D][esp32_ble_tracker:720]: Found device 16:CA:BD:20:77:5E RSSI=-92
[16:56:05][D][esp32_ble_tracker:741]:   Address Type: RANDOM
[16:56:09][D][ble_gateway:063]: [A4:C1:38:24:6C:11] Packet 043E4602010000116C2438C1A43A0D09475648353037355F36433131030388EC02010509FF88EC00033DE864001AFF4C000215494E54454C4C495F524F434B535F48575075F2FFC2B2
[16:56:14][D][esp32_ble_tracker:720]: Found device 60:95:05:99:1C:70 RSSI=-83
[16:56:14][D][esp32_ble_tracker:741]:   Address Type: RANDOM
[16:56:14][D][esp32_ble_tracker:745]:   TX Power: 2
[16:56:28][D][esp32_ble_tracker:720]: Found device 6A:3D:AA:96:97:3F RSSI=-80
[16:56:29][D][esp32_ble_tracker:741]:   Address Type: RANDOM
[16:56:29][D][esp32_ble_tracker:745]:   TX Power: 2
[16:56:32][D][ble_gateway:063]: [A4:C1:38:24:6C:11] Packet 043E4602010000116C2438C1A43A0D09475648353037355F36433131030388EC02010509FF88EC00033DE664001AFF4C000215494E54454C4C495F524F434B535F48575075F2FFC2B8
[16:56:54][D][ble_gateway:063]: [A4:C1:38:24:6C:11] Packet 043E4602010000116C2438C1A43A0D09475648353037355F36433131030388EC02010509FF88EC00033DE664001AFF4C000215494E54454C4C495F524F434B535F48575075F2FFC2AC
[16:57:16][D][ble_gateway:063]: [A4:C1:38:24:6C:11] Packet 043E4602010000116C2438C1A43A0D09475648353037355F36433131030388EC02010509FF88EC00033DE764001AFF4C000215494E54454C4C495F524F434B535F48575075F2FFC2B7
[16:57:45][D][ble_gateway:063]: [A4:C1:38:24:6C:11] Packet 043E4602010000116C2438C1A43A0D09475648353037355F36433131030388EC02010509FF88EC00033DE664001AFF4C000215494E54454C4C495F524F434B535F48575075F2FFC2B1
[16:58:30][D][ble_gateway:063]: [A4:C1:38:24:6C:11] Packet 043E4602010000116C2438C1A43A0D09475648353037355F36433131030388EC02010509FF88EC00033DE664001AFF4C000215494E54454C4C495F524F434B535F48575075F2FFC2B9
[16:58:48][D][esp32_ble_tracker:214]: Starting scan...
[16:58:49][D][esp32_ble_tracker:720]: Found device 27:75:F4:17:32:05 RSSI=-89
[16:58:49][D][esp32_ble_tracker:741]:   Address Type: RANDOM
[16:58:49][D][esp32_ble_tracker:720]: Found device 48:7F:52:F2:FE:3A RSSI=-72
[16:58:49][D][esp32_ble_tracker:741]:   Address Type: RANDOM
[16:58:49][D][esp32_ble_tracker:745]:   TX Power: 2
[16:58:49][D][esp32_ble_tracker:720]: Found device 40:CB:C0:E8:CE:F3 RSSI=-89
[16:58:49][D][esp32_ble_tracker:741]:   Address Type: PUBLIC
[16:58:49][D][esp32_ble_tracker:745]:   TX Power: 2
[16:58:50][D][esp32_ble_tracker:720]: Found device 7C:96:D2:36:FD:0E RSSI=-72
[16:58:51][D][esp32_ble_tracker:741]:   Address Type: PUBLIC
[16:58:51][D][esp32_ble_tracker:743]:   Name: 'Beoplay P2'
[16:58:51][D][esp32_ble_tracker:720]: Found device 60:95:05:99:1C:70 RSSI=-66
[16:58:51][D][esp32_ble_tracker:741]:   Address Type: RANDOM
[16:58:51][D][esp32_ble_tracker:745]:   TX Power: 2
[16:58:52][D][esp32_ble_tracker:720]: Found device 61:6F:BC:EC:90:68 RSSI=-89
`

[jchang10]

https://github.com/custom-components/ble_monitor/issues/641

Looks like Ernst fixed the issue. That was quick! It looks like he basically collects the manufacturer specific data and just retains the first packet now, which works for my simple little case.

Thus, IMHO, this issue is closed. However, I still do wonder why the second packet is being sent. IE, is it truly garbage or no?

Here is one of the packets again: b'\x04>F\x02\x01\x00\x00\x11l$8\xc1\xa4:\r\tGVH5075_6C11\x03\x03\x88\xec\x02\x01\x05\t\xff\x88\xec\x00\x039\xfcd\x00\x1a\xffL\x00\x02\x15INTELLI_ROCKS_HWPu\xf2\xff\xc2\xb2'

https://github.com/Thrilleratplay/GoveeWatcher Ha. I did find this link where it mentions the company INTELLI_ROCKS and the second packet. Anyway, it is definitely coming from the Govee device. ;)

[Ernst79]

In BLE monitor, we now (7.3.1-beta) collect both packets, and parse them both. If one of them is parsing as a supported device, it will use that one

[myhomeiot]

@Ernst79, @jchang10 Glad that issue was resolved, thanks for great cooperation!