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 -

#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 ;)