Battery level on Xiaomi/VegTrug","model":"MiFlora","model_id":"HHCCJCY01HHCC

HI, I have esp32dev-ble-cont v1.2.0 installed

for some reason I don’t receive battery data on a Xiaomi/VegTrug",“model”:“MiFlora”,“model_id”:"HHCCJCY01HHCC

I’ve checked with MQTTexplorer for a while but nothing yet.
I think it’s supposed to publish battery every 10 scans?

all I get are variations of this with all features except battery:

{“id”:“C4:7C:8D:6C:97:04”,“mac_type”:0,“name”:“Flower care”,“rssi”:-76,“brand”:“Xiaomi/VegTrug”,“model”:“MiFlora”,“model_id”:“HHCCJCY01HHCC”,“tempc”:23.1,“tempf”:73.58}

I have Tasmota BLE32 Installed on another device and it does receive battery data:


How should I troubleshoot this?

Is there a way to Trigger an active read of battery values (see Tasmota command below, which works)

MI32Battery Trigger an active read of battery values.
MI32Battery = request the driver read the battery from all sensors which have active battery read requirements.

Hi @123qweasd,

not having a HHCCJCY01HHCC myself I do not actually know if the battery status is also included in the freely broadcast advertising data, or of the battery status can only be retrieved by a connection.

Assuming that it uses the default battery service/characteristics combo a READ command with

{"ble_read_address":"C4:7C:8D:6C:97:04","mac_type":0,"ble_read_service":"180f","ble_read_char":"2a19","value_type":"HEX","ttl": 4,"immediate":true}

should have the battery status in the response.

Otherwise you could use an app like nRFConenct to see which other ervice/characteristic does include the battery information.

Also if you would install the esp32dev-ble-datatest binary you could see if some broadcasts do have undecoded parts of the then included servicedata which correspond with the above retrieved battery level in hex format.

If there is battery info available in the advertised servicedata we will include it in the HHCCJCY01HHCC decoder.

ADDENDUM: I just found information that the battery is not freely broadcast any longer with firmware version 3.2.1 and later.So a direct connection and READ would be the only way to get the battery level.

This makes sense as I have to use a similar pull command for Tasmota BLE
I can automate it for OMG, no issues.
however, once battery data is puilled from the device, for some reason OMG stops publishing everything else under this topic…

02/11/2023 2:06:16 PM
02/11/2023 2:06:14 PM(-2.58 seconds)
02/11/2023 2:06:00 PM(-14 seconds)
02/11/2023 2:00:35 PM(-5.4 minutes)
02/11/2023 2:00:30 PM(-5.05 seconds)
02/11/2023 2:00:17 PM(-13.32 seconds)
02/11/2023 1:59:23 PM(-54.51 seconds)
02/11/2023 1:59:11 PM(-11.29 seconds)
02/11/2023 1:59:00 PM(-11.71 seconds)
02/11/2023 1:58:52 PM(-7.27 seconds)
{“id”:“C4:7C:8D:6C:97:04”,“mac_type”:0,“name”:“Flower care”,“rssi”:-77,“brand”:“Xiaomi/VegTrug”,“model”:“MiFlora”,“model_id”:“HHCCJCY01HHCC”,“moi”:0}
02/11/2023 1:58:52 PM(-0.72 seconds)
02/11/2023 1:58:51 PM(-1.01 seconds)
02/11/2023 1:58:49 PM(-1.08 seconds)
02/11/2023 1:58:48 PM(-1.03 seconds)
{“id”:“C4:7C:8D:6C:97:04”,“mac_type”:0,“name”:“Flower care”,“rssi”:-73,“brand”:“Xiaomi/VegTrug”,“model”:“MiFlora”,“model_id”:“HHCCJCY01HHCC”,“moi”:0}
02/11/2023 1:58:47 PM(-1.31 seconds)
{“id”:“C4:7C:8D:6C:97:04”,“mac_type”:0,“name”:“Flower care”,“rssi”:-77,“brand”:“Xiaomi/VegTrug”,“model”:“MiFlora”,“model_id”:“HHCCJCY01HHCC”,“lux”:825}
02/11/2023 1:58:47 PM(-0 seconds)
{“id”:“C4:7C:8D:6C:97:04”,“mac_type”:0,“name”:“Flower care”,“rssi”:-78,“brand”:“Xiaomi/VegTrug”,“model”:“MiFlora”,“model_id”:“HHCCJCY01HHCC”,“lux”:825}
02/11/2023 1:58:47 PM(-0.01 seconds)
02/11/2023 1:58:15 PM(-31.68 seconds)
{“id”:“C4:7C:8D:6C:97:04”,“mac_type”:0,“name”:“Flower care”,“rssi”:-78,“brand”:“Xiaomi/VegTrug”,“model”:“MiFlora”,“model_id”:“HHCCJCY01HHCC”,“moi”:0}
02/11/2023 1:58:15 PM(-0.97 seconds)
{“id”:“C4:7C:8D:6C:97:04”,“mac_type”:0,“name”:“Flower care”,“rssi”:-73,“brand”:“Xiaomi/VegTrug”,“model”:“MiFlora”,“model_id”:“HHCCJCY01HHCC”,“moi”:0}
02/11/2023 1:58:11 PM(-3.17 seconds)
{“id”:“C4:7C:8D:6C:97:04”,“mac_type”:0,“name”:“Flower care”,“rssi”:-72,“brand”:“Xiaomi/VegTrug”,“model”:“MiFlora”,“model_id”:“HHCCJCY01HHCC”,“moi”:0}
02/11/2023 1:58:02 PM(-9.31 seconds)
02/11/2023 1:58:00 PM(-1.71 seconds)
{“id”:“C4:7C:8D:6C:97:04”,“mac_type”:0,“name”:“Flower care”,“rssi”:-77,“brand”:“Xiaomi/VegTrug”,“model”:“MiFlora”,“model_id”:“HHCCJCY01HHCC”,“lux”:814}
02/11/2023 1:57:55 PM(-5.35 seconds)

it comes back with “success”:false, but still with a sucessfull reply


A bit strange. Maybe try with the full 128-bit service and data uuids.

however, once battery data is pulled from the device, for some reason OMG stops publishing everything else under this topic…

I can only see individual moisture and lux data afterwards, but suspect that when the above response will be “success”:true - either with full 128-bit uuids and/or possibly an additional different battery service/char - the continued broadcast will be fine again as well.

Can you elaborate on how to do this?

The list is sorted with the newest on top, so nothing after my Battery calls on 2:01-2:06pm…
it’s been dead quiet since. nothing.

Still works on the Tasmota BLE boards

Can you elaborate on how to do this?

Best to have a look with some phone app like nRFConnect, BLE Scanner, BlueSee … to see what 128-bit service/char the device has and/or if it might actually be some other combination than the default battery level service.

I actually also just found out that OpenMQTTGateway is getting the battery status by connection regularly to HHCCJCY01HHCC, so it should actually show up in the interval set by

with the precondition of

being true.

So that should have been my initial response :wink:

Ok , bad timing with my last install I guess :wink:
will install 1.3.0 and report back, thx =)

Thanks, working now =)

Some addtional questions:

  • Are all feature settings from this page non-persistent? IE: do I have to set retain flags and/or resend commands on bridge restart?
    seems to be the case for white/black lists but not sure about the other options
  • Is there a way to poll the current state of all these features with some MQTT command?

  • I see that the “'activescan” feature disappeared from the docs (yesterday?), is it deprecated/replaced by “adaptivescan”? Also there seem to be acontradiction in the docs:

Thanks again!

For storing across restarts have a look further down on the page - no need to retain.

Is there a way to poll the current state of all these features with some MQTT command?

The top BTtoMQTT topic does have all the current information. You will also see it change when you apply any of the setting commands.

Correct, it is replaced by adaptivescan. The bottom part is still a remnant of a previous test implementation and needs to be corrected :wink: thanks for pointing it out.

Thanks for pointing this out; however if I understand correctly, I would still have to load the saved config on each restart, right?

Yes, I do see settings change when applied; I was reffering to a command that would ask the bridge to “publish” the current status of all settings; the equivalent of sending an empty “Setoption” command on the Tasmota platform, which returns current status.

So the correct statement is : false = passive scanning ? or continuous active scanning ?

BTW: any plans to add a frontend to OMG =) ?

Thanks again

Once saved the configuration will be auto-loaded on restart.

This info is also being updated regularly (120 second I think without looking), but as an immediate command with the same setting of some, or even a singular save command should have the same immediate republishing as a separately implemented one would have. Or am I misunderstanding you here?

The correct statement is

Setting Adaptive scanning to false will automatically put the gateway to continuous active scanning if it was previously true.

as you can see by interval and intervalacts changing to 100 ms immediately - and then being settable as required by individual needs.

Hope this helps clearing up some confusion.