Govee H5055 Decoder Request

[BastiJoe]

Hi guys,

thanks a lot for this great project. I am just setting up my smart home on OpenMQTTGateway and Mosquitto + Openhab basis.

Is your feature request related to a problem? Please describe. I would like to integrate my bbq thermometer govee h5055 via mqtt. Therefore i realized a python based decoder for the Govee H5055 here: https://github.com/BastiJoe/govee_h5055_mqtt I am switching from my Raspberry to OpenMQTTGateway on ESP32 and therefore would be glad, if my BBQ Thermometer Govee H5055 would work with OpenMQTTGateway as well.

Describe the solution you'd like I would like to contribute to the decoder project somehow but I am quite a newbie to this stuff. I tried to explain how the manufacturer message can be decoded in png and pptx files here: https://github.com/BastiJoe/govee_h5055_mqtt Can someone help me create a pull request for the decoder project in C?

Thank you very much in advance.

Best regards

Basti

[BastiJoe]

Looks still the same

[DigiH]

Thanks for testing @BastiJoe!

My wild guess checked off as wild, but not much else ;)

[1technophile]

@BastiJoe do you see other devices with a servicedatauuid ?

If you want to verify that the gateway is currently reading the servicedatauuid correctly, you can download nrf connect on your phone,

• click on advertiser
• click on +
• add a display name
• click on "scannable"
• add a record
• click on Service UUID
• add a 4 digit value
• click on OK
• toggle the switch to activate the beacon And check if you see it on your mqtt broker

If not you may have an issue with the firmware configuration.

Example:

Into MQTT Explorer:

{"id":"5A:E7:70:BD:09:A4","mac_type":1,"name":"My phone","rssi":-84,"txpower":-7,"servicedata":"09","servicedatauuid":"0x7776"}

[h2zero]

Hi guys,

I'm still not understanding why we are not seeing the serviceUUID, especially due to the fact that we see it there also:

@1technophile Is that the data from the device in question?

What you're seeing in that picture is the advertisements of the service UUID's of the device and also the service data from a different UUID (0xFE95, in this case). To be able to detect the 0x5550 service UUID we would need to provide a new input parameter to the decoder as an array of advertised UUID's. This could be done but would require changing the code from the input side as well (OMG/TheengsGateway/ etc.).

I haven't read through all of these posts in detail yet as I've been very busy, but I'll have a closer look later.

[BastiJoe]

Hi @1technophile For other sensors i get service data uuid

[DigiH]

Glad that @h2zero and @1technophile are getting involved, as this part is outside of my expertise. If we could get access to the array of advertised UUIDs for the model decoder it would be the most distinct unambiguous identification.

I'm wondering though if this is very unique to the H5055, or if other devices might benefit from an advertised UUIDs implementation as well. Govee however also have changed their BT advertisement scheme, as all subsequent devices seem to all broadcast their unique names, which can be used for clear identification, and don't use part of the MAC address any longer at the start of the manufacturerdata, but also unique identifiers - from what I can deduct from other model's implementations.

Thanks

[1technophile]

@1technophile Is that the data from the device in question?

@h2zero yes for sure as we see it in nRF connect also. This service UUID is different from the UUID field that we can condition with the decoder currently, if I understand?

From a NImBLE Arduino perspective, it should be retrieved by getServiceUUID and not getServiceDataUUID isn't it?

[h2zero]

Yes, they are different. What needs to happen for a universal application is to create an array of the advertised services using getServiceUUID and getServiceUUIDCount in a loop. Then the jsonobject could have an advertisedServices entry with an array containing the service UUID's.

That all needs to be taken care of from the input side, it would be a simple matter from there to check for it in the decoder.

[DigiH]

Hi @BastiJoe, the H5055 decoder has been merged and is included in the 0.2.2 release. Please verify with this release and close this issue if everything is fine.

Thanks

[1technophile]

Closing this, @BastiJoe feel free to come back to it if necessary

[AJolly]

Maybe I'm doing something wrong, but theengs doesn't seem to pick up my h5055.

[DigiH]

Which project are you using Theengs Decoder with?

Can you turn on, if not already showing, the undecoded advertising manufacturerdata you pick up from your H5055, and post it here, so that we can see why it might not be decoded - possibly due to some new firmware advertising format?

[AJolly]

The theengs Android app. If it helps I can confirm that home assistant decodes it just fine.

https://www.home-assistant.io/integrations/govee_ble

If you let me know a better way to get you logs I'd be happy to help.

On Wed, Oct 23, 2024, 6:29 AM DigiH @.***> wrote:

Which project are you using Theengs Decoder with?

Can you turn on, if not already showing, the advertising data you pick up from your H5055, and post it here, so that we can see why it might not be decoded - possibly due to some new firmware advertising format?

— Reply to this email directly, view it on GitHub https://github.com/theengs/decoder/issues/92#issuecomment-2431808725, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAWKZOGKWG4VSMIZ6KQREDZ46CB5AVCNFSM6AAAAABQOB2D4SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZRHAYDQNZSGU . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[DigiH]

It really depends if it is a Theengs Decoder issue, or possibly some issue with the H5055 decoder not working properly in the Theengs App.

Best if you could also try the Theengs Gateway HA Add-on, to see if it gets recognised fine there. This will also allow you to turn on the Publish Advanced and Advertising Data option in the Add-on configs for further investigation if it is also not recognised there. Just make sure to disable HA Discovery, if you're already using the H5055 with the HA Govee integration.

Then we'll know if the issue is on the Decoder or App side.

[1technophile]

@AJolly you can try this beta https://play.google.com/apps/testing/com.theengs.app it should fix your issue

[AJolly]

The beta (1.4.1) sort of works but the decoding is somewhat wrong.

1) in very frequently will switch from reading to considering probes to be unplugged. 2) it's claims probe two has data even when it is completely unplugged.

Sideq: what needs to be done to get BT home V2 data supported? https://bthome.io/

[AJolly]

I tried installing openmqttgateway and it has the same decoding errors.

[DigiH]

@AJolly

Could you set Advertisement and Advanced Data to true in OpenMQTTGateway, and then post some MQTT messages including the manufacturerdata when the probes are wrongly detected or a connected probe shows as unplugged?

[AJolly]

I think this is what you asked for: emqx@ha.local-trace_A4C1381CEA35_2024-11-04.log

[DigiH]

Thanks @AJolly, this is the kind of data required to investigate what you are seeing, apart from me not exactly knowing which messages are for what you consider the wrong values - I do take it it is the ones where probe 4 and 6 are showing with 43ºC/109.4ºF for probe 6 and 48ºC/49ºC for probe 4? So probe 4 and 6 have never actually be connected if I understand you correctly. You only ever had probes 1 and 2 connected, right?

I am getting the same results for the associated manufacturerdata here when testing with Decoder.

Unfortunately it looks as your model H5055 might be faulty, a newer revision or has some newer firmware, which seems to have some slightly different encoding. As the encoding BastiJoe deducted above in his linked repo and which we took over for the decoder, correctly decodes as probes 4 and 6 being connected for data taken from your log, like

1cea3500596b20ffffffffffff203100ffffffff0000 hex 6b = 01101011 binary 01101011 probes 3 and 4 data sent / 01101011 probes 1, 2, 4 and 6 connected. As with this particular data probe 3 has ffff, i.e. no data, but for probe 4 there is 3100, which decodes to 49ºC

1cea350059ab20ffffffffffff202b00ffffffff0000 hex ab = 10101011 binary 10101011 probes 5 and 6 data sent / 10101011 probes 1, 2, 4 and 6 connected. As with this particular data probe 5 has ffff, i.e. no data, but for probe 6 there is 2b00, which decodes to 43ºC

Even the messages showing probes 1 and 2, correctly for you I assume, have data like 1cea3500592b203400ffffffff203500ffffffff0000 with hex 2b = 00101011 still indicating that probes 4 and 6 are also connected on your H5055, even when temps for probes 1 and 2 are being broadcast. So every broadcast data indicates that probes 1, 2, 4 and 6 are connected.

Have you tried plugging the probes into port 4 and 6, just to see if there might be some possible short within these ports, with plugging and unplugging might loosen them?

And if you only have two probes for the H5055, could you plug them into ports 4 and 6 only, then see if you are still getting false readings for port 1 and 2, and then also post some sample messages as before?

And possibly also some messages with no probes connected at all - if the H5055 then still sends BLE broadcasts.

It is enough to just copy and paste 1 or 2 messages though, a whole complete log is not really necessary ;)

As so far everything looks fine from the decoder side, as the data definitely sems to indicate that probe 4 and 6 are also connected and sending temperatures - either through it being a faulty unit or a quite different encoding scheme.

@BastiJoe Have you possibly seen anything similar with a firmware update for your H5055?

[AJolly]

Sorry to be unclear: Previously, I only had probes 1/4 plugged in. Since then, I currently (and during the period of the logs) have had probes 1,2,4,6 plugged in continuously.
Home Assistant correctly decodes.

I was unable to catch the event where the decoder incorrectly decoded a ghost probe.

Right now the issue is the app recording that probes are disconnected, even though as you know the broadcast data shows the probes are still connected.

I suspect you're right about a different revision I previously had a different H5055, and the probes that came with were slightly different.

[DigiH]

So then all the messages in your log are correct, with probes 1,2,4 and 6 connected, and you haven't seen any incorrectly decoded ghost probes. Which makes me say that this is not a Decoder issue.

Right now the issue is the app recording that probes are disconnected, even though as you know the broadcast data shows the probes are still connected.

This then might really be an App issue, as the H5055 is an odd one out in only ever sending temperature data for two probes at a time (1&2, 3&4 and 5&6) whereas all the other BBQ thermometers included in Theengs decoder always send all, up to 6 as well, probes with every broadcast.

@1technophile - could this be the issue with the App, that when a broadcast is received and decoded to, let's say, probe 5&6, that the previously received probes 1&2/3&4 values are being wiped/reset too quickly due to the App assuming that no probes 1&2/3&4 being received means they have been disconnected?

Link to the H5055 test cases for clarification of the 1 or 2 probes only broadcasts/messages

https://github.com/theengs/decoder/blob/development/tests/BLE/test_ble.cpp#L27-L30

https://github.com/theengs/decoder/blob/development/tests/BLE/test_ble.cpp#L27-L30