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

[DigiH]

Hi Basti,

I've only been adding decoder information for a while now, but happy to help along in getting your Govee H5055 included.

Can someone help me create a pull request for the decoder project in C?

For adding a decoder using the broadcast manufacturerdata and servicedata no C is required, but have a look at the decoder contribution information here

https://theengs.github.io/decoder/participate/adding-decoders.html

From your very informative details give in your python example it seems that quite a lot of information can be deducted with the currently available decoder implementations, apart from the information embedded in the binary conversion bits. As this is however also required for some other planned decoders - haver a look at this started discussion -

https://github.com/theengs/decoder/discussions/90

it will probably be on the table in the future.

For now however it would be interesting to get the information which is already possible to start building up the decoder. So for example for the battery data the relevant section of the decoder would be

…
      "batt":{
         "decoder":["value_from_hex_data", "manufacturerdata", 8, 2, false]
      },
…

From the example this seems to be 46 hex => 70 %.

For sensor A Max Threshold

…
      "sensor_a_high":{
         "decoder":["value_from_hex_data", "manufacturerdata", 22, 4, true, false]
      },
…

which would result in your stated 300º C as well.

The same would be added to the decoder for the rest of the broadcast information.

I hope this makes it clearer on how a decoder for the Govee H5055 can be implemented.

Happy to help along the way.

BTW, do you get any uuid info in your MQTT data when you set

'-DpubBLEServiceUUID=true'

in your build flags?

[DigiH]

@BastiJoe actually looking at this more closely I don't think that the binary conversion is necessary to get the sensor bits. Let me write something up for you to test …

[BastiJoe]

@DigiH Thank you very much for your support and your quick response. I will have a closer look at the "adding decoders" section the next days and i will check for the UUID Info. This looks very promising to me.

[DigiH]

@BastiJoe so with my thinking that since the binary conversion bits are not available to check yet, their information is already encoded in the hex indexes.

I also think there was a small error in your image showing the sensor connected info. Instead of using 8-11 with the endianness reversed - as this would also include the battery index 8-9 - just using index 10-11 should be enough to get the connected sensor/probes data. Correct me if I'm wrong there, as you have the actual device and I'm just deducting from your provided data :)

As expected though, this multiple OR evaluation, instead of a nice short clean binary conversion bit checking, does make things very bloated and unsightly ;)

I tried to keep it as short as possible, as I already had to increase the maximum doc sizes for the tests to succeed, so instead of also reporting sensors/probes "disconnected" the sensors/probes are only reported in the published JSON if they are "connected"

It would be great if you could try this out with your actual H5055 by changing the line

decoder = https://github.com/theengs/decoder.git#v0.2.1

to

decoder = https://github.com/DigiH/decoder#Govee-H5055

in platformio.ini

You should then see something similar to the provided test case I included

"{"brand":"Govee","model":"Bluetooth BBQ Thermometer","model_id":"H5055","probe1":"connected","probe2":"connected","probe4":"connected","probe5":"connected","tempc1":23,"tempf1":73.4,"tempc2":115,"tempf2":239,"batt":70}"

working for all three probe pair reports with tempc1/tempc2, tempc3/tempc4 and tempc5/tempc6 reported separately, while the connected probes states are reported in every report.

Adding the Min and Max Thresholds would be additionally needed if this works so far ;)

[1technophile]

Thanks @DigiH , I have a question regarding the decoder, could we use the condition to detect the connected state of a probe as a condition to detect the corresponding temperature:

      "tempc1":{
        "condition":["manufacturerdata", 10, "0", "|", "manufacturerdata", 10, "1", "|", "manufacturerdata", 10, "2", "|", "manufacturerdata", 10, "3","|","manufacturerdata", 11, "1", "|", "manufacturerdata", 11, "3", "|", "manufacturerdata", 11, "5", "|", "manufacturerdata", 11, "7", "|", "manufacturerdata", 11, "9", "|", "manufacturerdata", 11, "b", "|", "manufacturerdata", 11, "d", "|", "manufacturerdata", 11, "f"],
        "decoder":["value_from_hex_data", "manufacturerdata", 14, 4, true, false]
      },

So that we can remove the probeX ?

[DigiH]

Hi @1technophile , I'm afraid not, they really all need to be evaluated separately - nicely shown on @BastiJoe's image groove_2.png - as the binary bits 3 and 4 of the first quadruplet indicate which 2 of the 6 probes have their temperatures included in the message, whereas the remaining bits 1 and 2, and all 4 bits of the second quadruplet indicate the six probes' connection statuses.

The number of property cases themselves cannot really be reduced, but once shorter direct binary bit evaluations are possible each property condition can be shortened to a single entry where there are now the many OR cases.

[DigiH]

@1technophile I've also just been looking at some of the other similar BBQ thermometer test cases. I don't know if the Inkbird 6XS and the SOLIS 6 don't or do supply information about which probes are connected or not, but from the expected tests results I take it that all the probes reporting 6552.6 ºC are the probes not connected. Similarly ignoring the probes' connection state here would report 65535 ºC for these probes, which is still actually does, but without the clear connection state for ignoring these probes' temperatures.

Maybe we can somehow implement these default high 'probe not connected - no real temperature reported' states for all such devices, as currently a NOT check for "ffff"/"f6ff" for example is not possible.

[1technophile]

Maybe we can somehow implement these default high 'probe not connected - no real temperature reported' states for all such devices, as currently a NOT check for "ffff"/"f6ff" for example is not possible.

You are right @DigiH , a NOT would simplify those decoders, we would not need to check for the probe status and decode the temperature value only when there is a probe connected.

[DigiH]

@1technophile The same NOT I would have also liked with the MiBand activity heart rate implementation ;) I think it's one of the more desirable new condition options to have in the future.

For the Inkbirds and the SOLIS this would work with one NOT condition to publish the probe temperature or not, i.e. showing which probes are connected and reporting valid temperatures.

For this Govee H5055 however it still needs the existing multiple OR conditions (or a single binary bit wise condition in the future) together with the NOT. Once there is a single binary bitwise possibility it wouldn't be a problem to AND combine the two, but currently with the multiple OR I'm not sure if the nested conditions possibilities were also implemented by @h2zero for the property conditions, and if it would then work with a new NOT.

This is all because the H5055 only reports 2 probe temperatures per MQTT message, with 3 messages alternating to get all the 6 probes' temperatures. So the extra 'which 2 temps am I getting' check will always be necessary.

[BastiJoe]

Hi @DigiH

I also think there was a small error in your image showing the sensor connected info. Instead of using 8-11 with the endianness reversed - as this would also include the battery index 8-9 - just using index 10-11 should be enough to get the connected sensor/probes data. Correct me if I'm wrong there, as you have the actual device and I'm just deducting from your provided data :)

Yes that is true, I corrected the image.

I am not using platformio yet, i am still using arduino ide but i included your branch in the theengs lib manually and it works great. Thank you so much.

[DigiH]

Great, thanks for the feedback @BastiJoe :)

As you can probably tell from our conversation here, and me stating that I had to increase a JSON doc max value to be able to incorporate this decoder, although it is working fine, unfortunately it is also very bloated.

I'm not sure if I'd want to submit it for merging into the main decoder project like this, or if @1technophile and @h2zero would actually want it in there in the current state, especially after I still need to add the missing Min and Max Thresholds, which will add another 12 properties, currently all with the same 4 OR conditions as the already existing temp properties. But then it will be quite complete.

Did I just hear both 1technophile h2zero cry out a loud NO in unison … :)

Seriously, I don't currently feel comfortable merging the decoder like this either.

I think he best solution for the time being is to make the H5055 decoder available to you, and anyone else who wants to use it, by including my branch into your/their build. As I will keep optimising it and also keep fetching and merging the upstream from theengs/decoder it will also always be up to date.

@1technophile @h2zero what do you think about this proposal?

[1technophile]

@DigiH what about pushing it just with the temperatures for the moment, and it can be enriched when we add the necessary functions into the decoder logic?

[DigiH]

@1technophile sounds like a plan. @BastiJoe how do you feel about using it like this, if only the temperatures are reported but the probes' connected state and the Min and Max Threshold temperatures were excluded until they can be incorporated back in with less messy code?

I will create a separate branch to only have the temps, the original Govee-H5055 branch will still have everything and can then be optimised once new condition functionality is available.

[BastiJoe]

I totally agree with you, thats a lot of conditions. Is it possible to isolate these two bits that indicates which probes the message contains? If yes we could try to condense the the conditionsa bit. Probably the connection states are not quite important. Also the thresholds can be omitted. With the two bits seperated i am thinking of some decoder like: a = {0,1,2} (these two bits) X = 2a + 1 Y= 2a + 2

tempcX = 20°C tempcY = 24°C

  "tempcX":{
    "condition":[],
    "decoder":["value_from_hex_data", "manufacturerdata", 14, 4, true, false]
  },
  "tempcY":{
    "condition":[],
    "decoder":["value_from_hex_data", "manufacturerdata", 28, 4, true, false]
  },

With this we could use the same "formula" for each message and can avoid all these conditions.

[DigiH]

Is it possible to isolate these two bits that indicates which probes the message contains?

Only with the current 4 OR hex digit conditions, not by direct binary bit evaluation - yet.

I just created the temps/battery only branch at

https://github.com/DigiH/decoder#H5055-tempsonly

@BastiJoe could you please confirm the 2 AA batteries info I added to the new H5055 doc? I couldn't find an online manual quickly and never totally trust the info at Amazon or other shops ;)

[BastiJoe]

2 AA Batteries is correct.

[1technophile]

@BastiJoe could you give us more examples of manufacturerdata with 4 and 6 probes connected. The goal is to have more coverage for the unit tests.

[DigiH]

@1technophile in @BastiJoe's image above you can see the alternating temp1/temp2, temp3/temp4 and temp5/temp6 messages, only containing either of of the pairs.

I'm already adding the addtional 2 test cases, just need to manuall to the farenheit conversion, or let the tests fail to tell me ;)

DONE - the only thing now is that unconnected probes will only be reported as 65535 ºC, so those need to be registred as disconnected in openHAB @BastiJoe

Added a test case 'no temperature reported - unconnected' as well, so we can track this to later to bnot show any reported temps at all.

[BastiJoe]

cf040400453f060f00ffff2c01060f00ffff2c010000 6 Probes connected cf04040046ad06ffffffff2c01061300ffff2c010000 Probes 1,3,4,6 connected cf0404004625061300ffff2c0106ffffffff2c010000 Probes 1,3,6 connected cf0404004521061400ffff2c0106ffffffff2c010000 Probes 1,6 connected

[DigiH]

Oh, I've just looked at your revised image image @BastiJoe and I see you added info about the last two MAC address bytes at the beginning of the manufacturer data. Since I've implemented to sue the first 2 bytes this won't do :( I assumed them to be the manufacturer ID, but doesn't seem to adhere to that.

Did you ever get around to implementing

'-DpubBLEServiceUUID=true'

as this is for a platformio build I'm not sure how/if this is possible Arduino IDE. As there also isn't any 'name' reported we somehow need to identify the device, for all MAC addresses ;)

[1technophile]

Did you ever get around to implementing '-DpubBLEServiceUUID=true' as this is for a platformio build I'm not sure how/if this is possible Arduino IDE. As there also isn't any 'name' reported we

With arduino IDE you can set this to true

[DigiH]

With arduino IDE you can set this to true

Forest, trees … ;) thanks @1technophile

Just looking at all the other Govee devices, and they all seem to report their "name" and use the leading 2 bytes from the manufacturer data, but different ones, so Govee really doesn't seem to stick to a set manufacturer ID. Wondering if the 04 in @BastiJoe's case might just be a coincidence.

[DigiH]

But then again "cf04" is registered to DOM Sicherheitstechnik GmbH & Co. KG, and Govee really shouldn't use that, so 04 really seems to be from the MAC address, so we'll need to find another reliable way for identification.

[BastiJoe]

I set '-DpubBLEServiceUUID=true' but i do not get further data from the govee:

home/OpenMQTTGateway/BTtoMQTT/A4C138CF0404 {"id":"A4:C1:38:CF:04:04","mac_type":0,"manufacturerdata":"cf040400456106ffffffff2c0106ffffffff2c010000","rssi":-56,"brand":"Govee","model":"Bluetooth BBQ Thermometer","model_id":"H5055","tempc3":65535,"tempf3":117995,"tempc4":65535,"tempf4":117995,"batt":69}

It might be a coincidence, but i realized that even the first byte "CF" ist part of the mac adress CF:04:04.

[DigiH]

I set '-DpubBLEServiceUUID=true' but i do not get further data from the govee:

Ok, so no further info there, thanks.

It might be a coincidence, but i realized that even the first byte "CF" ist part of the mac adress CF:04:04.

Ouch :( at least we caught it with your revised image :) and no name reported either. Am really wondering now what we'll do for a proper model condition.

cf040400456106ffffffff2c0106ffffffff2c010000

Bold are the only manufacturerdata bytes left that we don't really know about now.

[1technophile]

@BastiJoe could you download nRF Connect, do a scan and paste here a screenshot of what you see for your sensor?

This could enable to see any missing information that could be used to identify this sensor properly.

[BastiJoe]

[DigiH]

I'm at a loss to be honest.

Unless we tightly check for 44 length & the two "06" bytes before each temperature block & "0000" at the end?!?

Any other ideas?

[BastiJoe]

Maybe govee separates their different devices by Mac address and we could use the starting 4 bytes to identify. A4:C1:38:CF We would need another device to see if it is a match. Do you guys already have a bbq thermometer? I could recommend one 😆

[DigiH]

A4:C1:38 is registered to Telink Semiconductor (Taipei) Co. Ltd., so probably the bluetooth component Govee uses in the H5055, but very likely also in other companies products, also not yet addressable by the model condition.

Do you guys already have a bbq thermometer? I could recommend one 😆

LOL, is it actually still on sale. I couldn't find any information about it on govee's website?

[1technophile]

@BastiJoe did you try to update the firmware so as to verify that we have the last version. The advertisement may have been corrected.

@DigiH maybe a coincidence that cf04 is part of the mac address too

[DigiH]

@DigiH maybe a coincidence that cf04 is part of the mac address too

Yes, I thought that as well, but it's a totally different company ID - DOM Sicherheitstechnik GmbH & Co. KG - which makes tech security systems and doesn't seem to have the remotest link to Govee's consumer product, and with the next byte matching the MAC address as well I really think that's what is is - the first 3 bytes of the MAC address are clear as it's the company ID of the used bluetooth component, then the last 3 bytes are the first 3 of the manufacturerdata. Even nRF Connect gets confused and think it's DOM Sicherheitstechnik, only because of @BastiJoe unique device's MAC address :)

[1technophile]

I see also that a serviceUUID is present 5550, this is not visible on OMG messages published here but may be visible sometime, if you let the scan run for several minutes @BastiJoe do you see this value appearing?

[DigiH]

I see also that a serviceUUID is present 5550, this is not visible on OMG messages published here but may be visible sometime, if you let the scan run for several minutes @BastiJoe do you see this value appearing?

I saw that too, but didn't know that it might take a few minutes to also show up in OMG, assuming that we didn't get the serviceUUID as @BastiJoe mentioned earlier.

Also the iBeacon part confuses me a bit …

[DigiH]

Oh, hold on …

iBeacon part major: 20565 in decimal => in hex = 5055 - H5055?!? ;) might be getting somewhere

But how do we get the iBeacon part into the manufacturerdata decoder condition part?

[DigiH]

I've changed the model condition to

"condition":["manufacturerdata", "=", 44, "index", 12, "06", "&", "manufacturerdata", "index", 26, "06", "&", "manufacturerdata", "index", 40, "0000"],

for testing purposes. All test run fine, so it does seem unique enough to not catch any other cases so far. Not really a very clear H5055 definition, but maybe clear enough for the time being?!?

[1technophile]

Cool, let's see if @BastiJoe catch some uuid, if not we can go with this.

[BastiJoe]

Hey guys, i collected 1h of messages. I can only identify slight differences in the manufacturerdata (in the first message, the 0000 at the end is cut off after the first digit.

Mar 14 09:17:39 home/OpenMQTTGateway/BTtoMQTT/A4C138CF0404 {"id":"A4:C1:38:CF:04:04","mac_type":0,"manufacturerdata":"cf040400466006ffffffff2c0106ffffffff2c010","rssi":-75,"brand":"Govee","model":"Bluetooth BBQ Thermometer","model_id":"H5055","tempc3":65535,"tempf3":117995,"tempc4":65535,"tempf4":117995,"batt":70}

Mar 14 09:18:46 home/OpenMQTTGateway/BTtoMQTT/A4C138CF0404 {"id":"A4:C1:38:CF:04:04","mac_type":0,"manufacturerdata":"cf04040046a006ffffffff2c01061600ffff2c010000","rssi":-76,"brand":"Govee","model":"Bluetooth BBQ Thermometer","model_id":"H5055","tempc5":65535,"tempf5":117995,"tempc6":22,"tempf6":71.6,"batt":70}

[DigiH]

Thanks @BastiJoe, the singular cut-off of the trailing "0000" seems to be an odd one out fluke, did it only occur very sporadically?

In that case I still think we can generally take it for the model condition, only missing occasional decoding if something like this happens.

If you could actually use the new decoder at

https://github.com/DigiH/decoder#H5055-tempsonly

and keep

#ifndef pubBLEManufacturerData
#  define pubBLEManufacturerData true // define true if you want to publish the manufacturer's data (sometimes contains characters that aren't valid with receiving client)
#endif

to see if you keep getting messages with temperatures for all six probes. If some are missing the manufacturerdata will show us the cause and the model condition might need adjusting.

Many thanks

[BastiJoe]

Unfortunately the cut off occurs quite usually....

[DigiH]

Thanks for that confirmation! I changed the model condition to

"condition":["manufacturerdata", ">=", 41, "index", 12, "06", "&", "manufacturerdata", "index", 26, "06", "&", "manufacturerdata", "index", 40, "0"],

to account for this. All tests still running fine.

[BastiJoe]

Hi @DigiH This condition is still dropping the cut off messages. Is this on purpose?

Does the length condition have to be reduced to 40? "condition":["manufacturerdata", ">=", 40, "index", 12, "06", "&", "manufacturerdata", "index", 26, "06", "&", "manufacturerdata", "index", 40, "0"],

Or maybe the cut off messages do not occur anymore. Not sure.

[DigiH]

This condition is still dropping the cut off messages. Is this on purpose?

Hi @BastiJoe I'm not quite sure what you mean by dropping the cut off messages?

">=", 41 should be fine as it includes the equal =, otherwise > 40 would be needed. And the two tests with the shorter manufacturerdata

"cf040400467f065600ffff2c01069100ffff2c010" "cf040400468f06ffffffff2c0106ffffffff2c010"

I included in the test runs also resolve fine.

Please elaborate what you meant with dropping the messages.

P.S.: In the last screenshot you sent you didn't use the latest revision of the

https://github.com/DigiH/decoder#H5055-tempsonly

branch, right, otherwise the cut-off messages wouldn't have resolved in the temperatures showing. Maybe that is what your're seeing?!?

[BastiJoe]

Ah ok, so now the cut off messages are being dropped (not resolving the temperatures) right? Thats what i am seeing. But i was not sure if tat was on purpose as we are loosing resolution.

[DigiH]

No, they should both resolve the temperatures right now, for the full "0000" and just the "0" at the end of the manufacturerdata.

I assume your second to last screenshot was actually done with the model condition still being

"condition":["manufacturerdata", "index", 0, "cf04"],

as the shorter "0" wouldn't have resolved the temperatures otherwise.

Now with the amended model condition the temperatures are/should also resolve for the shorter single "0" manufacturerdata as with the "0000". When and why the cut-off version occurs however still seems to be a mystery and you might have to wait a while again before they appear.

To get the latest decoder revision you need to rebuild in the Arduino IDE, preferably with clearing any previous builds' library caches to guarantee the latest version is being used for the build.

But don't worry about the cleaning first too much, just my pedantry ;) it should work fine just with rebuilding.

[BastiJoe]

Hi @DigiH I was using the latest repo with this conditions: "condition":["manufacturerdata", ">=", 41, "index", 12, "06", "&", "manufacturerdata", "index", 26, "06", "&", "manufacturerdata", "index", 40, "0"],

[DigiH]

@BastiJoe great, but the fact that you didn't see any shorter "0" only manufacturerdata was not due to any new condition. It cannot actually affect the manufacturerdata which the H5055 sends ;) or suppress/drop these manufacturerdata messages if your publishing option pubUnknownBLEManufacturerData still set to true. They would have still appeared in your topic subscription, just with the manufacturerdata on its own without any decoding.

I'm sure if you monitor the messages for a while again they will reappear. Maybe you can even see a pattern there or it really is just a quirk with the H5055.

If you do see the single "0" cases again and the model and temperatures are decoded fine please let us know to confirm the latest decoder is also working for both "0000" and "0" with the actual device.

[1technophile]

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:

[DigiH]

Hi @1technophile very true. I didn't even get back to this image recently with the definite identification problem.

That the uuid is showing up there though and we don't catch it is something to look into.

Could it actually be a problem because of the simultaneous iBeacon protocol the H5055 sends out, which I think is for finding the device in the Govee app, showing it's model number in the major for pairing it as an H5055 to the app?!?

This then somehow 'swallowing' the serviceUUID for further evaluation/publishing.

Really just a very wild guess ;)

[DigiH]

@BastiJoe would you mind rebuilding again with the latest

https://github.com/DigiH/decoder#H5055-tempsonly

Again, just the wild guess from above, I put the H5055 decoder before the iBeacon decoding evaluation, to see if you see any differences in the published messages.

Thanks