Feature request : HHCC Flora Care Senosr Pink version Tuya

“product_id”: “8yublynv”,
“product_name”: “HC010-2”,
“status”: [
{
“code”: “humidity”,
“value”: 0
},
{
“code”: “temp_current”,
“value”: 0
},
{
“code”: “bright_value”,
“value”: 0
},
{
“code”: “temp_unit_convert”,
“value”: “c”
},
{
“code”: “battery_percentage”,
“value”: 0
}
],

{
“result”: {
“category”: “zwjcy”,
“functions”: [
{
“code”: “temp_unit_convert”,
“dp_id”: 9,
“type”: “Enum”,
“values”: “{"range":["c","f"]}”
}
],
“status”: [
{
“code”: “humidity”,
“dp_id”: 3,
“type”: “Integer”,
“values”: “{"unit":"%","min":0,"max":100,"scale":0,"step":1}”
},
{
“code”: “temp_current”,
“dp_id”: 5,
“type”: “Integer”,
“values”: “{"unit":"℃","min":0,"max":1000,"scale":1,"step":1}”
},
{
“code”: “bright_value”,
“dp_id”: 6,
“type”: “Integer”,
“values”: “{"unit":"LUX","min":0,"max":200000,"scale":0,"step":1}”
},
{
“code”: “temp_unit_convert”,
“dp_id”: 9,
“type”: “Enum”,
“values”: “{"range":["c","f"]}”
},
{
“code”: “battery_percentage”,
“dp_id”: 15,
“type”: “Integer”,
“values”: “{"unit":"%","min":0,"max":210,"scale":0,"step":1}”
}
]
},
“success”: true,
“t”: 1678864399069,
“tid”: “dcc9cbddc30011edb979b682f9637fbb”
}

{
“id”: “DC:23:4D:E4:16:0A”,
“mac_type”: 1,
“adv_type”: 0,
“name”: “TY”,
“manufacturerdata”: “d007000001006f5ecc3a6802e9fa9a6a9b2285b3ecec”,
“rssi”: -45,
“distance”: 0.06662,
“servicedata”: “490000085fea200dd60e56c3”,
“servicedatauuid”: “0xfd50”
}


homeassistant bluetooth sees sensor but openmqtt dont

@mortenx

Does the above OMG MQTT message sample correspond with the HA reading at the same time, or were they taken at different times?

I.e. was the temperature at the MQTT sample time 23.4 °C by any chance, not 13.9 °C?

different time yes, i saw later that HA was automaticliy connected with sensor

Could you post some MQTT date along with the HA data at the same time, so that we can verify the decoding?

is it possible to see somewhere sensor raw bluetooth data in homeassistant ?

Not that I am aware. Generally by using MQTT Explorer and monitoring your MQTT broker.

this seems to be same packet although mqtt sees packets every minute but HA records ~every 5 minutes or so… and some data could be from different packet

The decoder is ready for testing and I’ll create an OpenMQTTGateway test version for you to try sometime tomorrow.

Hi @mortenx,

The test build 38d98c is avaialble for web upload at

until it gets overwritten again by the nightly development builds just after midnight UTC.

Let us know how it is working for you.

installed 38d98c , I don’t see anything being different

The test version was overwritten bu the nightly buidl. A new test version is running and should be available in about half an hour under the same link - the build SHA at the top of the page should then say 38d98c again, or did you install that version?

Build 38d98c is available again.

Firmware: 38d98c
installed

When and how did you install the test firmware?

And what do you now see when monitoring with MQTT Explorer?

installed 2. apr. in web browser

This is one of the (currently) non-decodable messages though, with a leading 490000, different from the sample message you sent above, with the servicedata being 18 characters long, of which there should also be broadcast from your Mi Flora, and should be decoded fine.

So when you monitor for a bit in MQTT Explorer, and expand and view the history of the device, do you see them?

{
“id”: “DC:23:4D:E4:16:0A”,
“mac_type”: 1,
“adv_type”: 0,
“name”: “TY”,
“manufacturerdata”: “d007000001006f5ecc3a6802e9fa9a6a9b2285b3ecec”,
“rssi”: -50,
“servicedata”: “490000085fea200dd60e56c3”,
“servicedatauuid”: “0xfd50”
}

{
“id”: “DC:23:4D:E4:16:0A”,
“mac_type”: 1,
“adv_type”: 0,
“name”: “TY”,
“manufacturerdata”: “d007000001006f5ecc3a6802e9fa9a6a9b2285b3ecec”,
“rssi”: -50,
“servicedata”: “490000085fea200dd60e56c3”,
“servicedatauuid”: “0xfd50”
}

{
“id”: “DC:23:4D:E4:16:0A”,
“mac_type”: 1,
“adv_type”: 0,
“name”: “TY”,
“manufacturerdata”: “d007000001006f5ecc3a6802e9fa9a6a9b2285b3ecec”,
“rssi”: -61,
“servicedata”: “490000085fea200dd60e56c3”,
“servicedatauuid”: “0xfd50”
}

{
“id”: “DC:23:4D:E4:16:0A”,
“mac_type”: 1,
“adv_type”: 0,
“name”: “TY”,
“manufacturerdata”: “d007000001006f5ecc3a6802e9fa9a6a9b2285b3ecec”,
“rssi”: -61,
“servicedata”: “6000d2000224640000”,
“servicedatauuid”: “0xfd50”
}

{
“id”: “DC:23:4D:E4:16:0A”,
“mac_type”: 1,
“adv_type”: 0,
“name”: “TY”,
“manufacturerdata”: “d007000001006f5ecc3a6802e9fa9a6a9b2285b3ecec”,
“rssi”: -63,
“servicedata”: “6000d2000224640000”,
“servicedatauuid”: “0xfd50”
}

{
“id”: “DC:23:4D:E4:16:0A”,
“mac_type”: 1,
“adv_type”: 0,
“name”: “TY”,
“manufacturerdata”: “d007000001006f5ecc3a6802e9fa9a6a9b2285b3ecec”,
“rssi”: -58,
“servicedata”: “490000085fea200dd60e56c3”,
“servicedatauuid”: “0xfd50”
}

{
“id”: “DC:23:4D:E4:16:0A”,
“mac_type”: 1,
“adv_type”: 0,
“name”: “TY”,
“manufacturerdata”: “d007000001006f5ecc3a6802e9fa9a6a9b2285b3ecec”,
“rssi”: -62,
“servicedata”: “6000d2000224640000”,
“servicedatauuid”: “0xfd50”
}

{
“id”: “DC:23:4D:E4:16:0A”,
“mac_type”: 1,
“adv_type”: 0,
“name”: “TY”,
“manufacturerdata”: “d007000001006f5ecc3a6802e9fa9a6a9b2285b3ecec”,
“rssi”: -61,
“servicedata”: “490000085fea200dd60e56c3”,
“servicedatauuid”: “0xfd50”
}

{
“id”: “DC:23:4D:E4:16:0A”,
“mac_type”: 1,
“adv_type”: 0,
“name”: “TY”,
“manufacturerdata”: “d007000001006f5ecc3a6802e9fa9a6a9b2285b3ecec”,
“rssi”: -57,
“servicedata”: “490000085fea200dd60e56c3”,
“servicedatauuid”: “0xfd50”
}

{
“id”: “DC:23:4D:E4:16:0A”,
“mac_type”: 1,
“adv_type”: 0,
“name”: “TY”,
“manufacturerdata”: “d007000001006f5ecc3a6802e9fa9a6a9b2285b3ecec”,
“rssi”: -59,
“servicedata”: “6000d2000224640000”,
“servicedatauuid”: “0xfd50”
}

{
“id”: “DC:23:4D:E4:16:0A”,
“mac_type”: 1,
“adv_type”: 0,
“name”: “TY”,
“manufacturerdata”: “d007000001006f5ecc3a6802e9fa9a6a9b2285b3ecec”,
“rssi”: -64,
“servicedata”: “6000d2000224640000”,
“servicedatauuid”: “0xfd50”
}

Great, thanks for the detailed message listing. This should have actually been decoded as

{“brand”:“Xiaomi/VegTrug”,“model”:“MiFlora”,“model_id”:“HHCCJCY10”,“type”:“PLANT”,“tempc”:21,“tempf”:69.8,“moi”:96,“lux”:548,“fer”:0,“batt”:100}

and it does so in the test runs. So I’ll have to see if there was a typo in referring to the test decoder for the test build or something.

New test build running - available in about one hour … with SHA d462fa

Available now at

@mortenx if you could post some messages again as above with this test version. If the correct 18 character long servicdata messages are still not decoded we’ll have to see what is causing the issue, as the decoder works fine in the test runs with some of your previously supplied data.

1 Like