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

[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]

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

[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 <#92 (comment)>, 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