[New Sensor]: Govee H5106 Air Quality Monitor

[phioschaos]

Sensor Description

Govee H5106 Air Quality Monitor

Additional information

I would like to have the Govee H5106 BLE air quality sensor supported.

I followed the instructions to get the BLE advertisements however I ran into an error which I posted. If this could be addressed, I would be happy to post the BLE advertisements from HA logs.
#1186

I did find that another project had figured out the data parsing:
theengs/decoder#257

Also, I will post the raw data I got from a BLE tracker app below.

Product Link:
https://us.govee.com/products/govee-wifi-air-quality-monitor

Product Description:
Model: H5106

Keep your home environment healthy with this smart air quality monitor. Accurately monitor the temperature, humidity, and PM2.5 levels in your home.

Multifunctional Air Quality Detector: Conveniently measure indoor air quality.
Fast & Accurate: Stay updated with 2s refresh speed.
Different Displays: Check the time and the PM2.5 display.
Connect with Govee Smart Home Appliances: Set target air quality.
Data Storage & Export: Remote monitoring via Bluetooth or Wi-Fi.

BLE advertisements

No response

[phioschaos]

[phioschaos]

Sorry, I didn't post the right link to the other project that had the parsing:
theengs/decoder#257

[Ernst79]

@DigiH I was working on this request, and I figured out temperature and humidity, based on your theengs decoder in PR theengs/decoder#257

E.g. humidity is in your decoder

      "hum":{
         "decoder":["value_from_hex_data", "manufacturerdata", 8, 8, false, false],
         "post_proc":["&", 2147483647, "%", 1000000, "/", 10000, ">", 0]
      },

Becomes the following in python

def decode_humi_h5106(packet_value: int) -> float:
    """Decode humidity values (to one decimal place)"""
    packet_value &= 0x7FFFFFFF
    return float((packet_value % 1000000) / 10000)

However, I don't understand how the PM2.5 works in your decoder

      ".cal":{
         "decoder":["value_from_hex_data", "manufacturerdata", 8, 8, false, false],
         "post_proc":["&", 2147483647, "/", 1000, ">", 0, "*", 1000]
      },
      "pm25":{
         "decoder":["value_from_hex_data", "manufacturerdata", 8, 8, false, false],
         "post_proc":["&", 2147483647, "-", ".cal"]

If I read this, I guess it says

def decode_pm_h5106(packet_value: int) -> float:
    """Decode pm values """
    packet_value &= 0x7FFFFFFF
    return float(packet_value - ((packet_value / 1000) * 1000))

But that is of course always 0.0. Can you explain me how this PM2.5 works?

[DigiH]

Hi @Ernst79

I have to admit, it took me quite a while to reverse engineer this one, with all properties being encoded in the same 4 octets ;) so I'll have to get my head around it again 😉

From a quick look again, the .cal "/", 1000, ">", 0, "*", 1000 was just some detour way to round (floor to be totally honest ;) some .0001 or .9999 results, so in Python you can likely discard/ignore it.

Let me know how this works for you without .cal, possibly trying some of our test cases, to see if you get the same results. If not I'll have to dive deeper into this monster again.

[Ernst79]

ah, got it.

In your second test, you have the following data. 010001010deeaa6f. the last 4 bytes are 0deeaa6f. After conversion to dec, this becomes 233745007, which reads as 23,3 °C, 74,5 % RH and 007 = 7 ug/m3 for PM2.5.

@DigiH I think you can get an extra decimal for humidity in the Theengs decoder. The result according to your tests is an integer (74), while it can be 74.5 if I'm not mistaken.

[Ernst79]

Support for the H5106 is added in 12.2.0.

[DigiH]

The result according to your tests is an integer (74), while it can be 74.5 if I'm not mistaken.

Correct, I think we went for the same floor as the actual device display seems to do, if I remember correctly, but could/should probably remove that for the published data.