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

[Montreal666]

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:

home/OMG_ESP32_BLE_C/BTtoMQTT/C47C8D6C9704
{“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:

“Flora6c9704”:{“mac”:“c47c8d6c9704”,“Temperature”:23.2,“Illuminance”:733,“Moisture”:0,“Fertility”:0,“Firmware”:“3.3.1”,“Battery”:100,“RSSI”:-77},“TempUnit”:“C”}

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.

[DigiH]

Hi @Montreal666,

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.

[Montreal666]

@DigiH

{"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}

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
{“model”:“HHCCJCY01HHCC”,“id”:“C4:7C:8D:6C:97:04”,“batt”:100}
02/11/2023 2:06:14 PM(-2.58 seconds)
{“id”:“C4:7C:8D:6C:97:04”,“service”:“0x180f”,“characteristic”:“0x2a19”,“success”:false}
02/11/2023 2:06:00 PM(-14 seconds)
{“model”:“HHCCJCY01HHCC”,“id”:“C4:7C:8D:6C:97:04”,“batt”:100}
02/11/2023 2:00:35 PM(-5.4 minutes)
{“id”:“C4:7C:8D:6C:97:04”,“service”:“0x180f”,“characteristic”:“0x2a19”,“success”:false}
02/11/2023 2:00:30 PM(-5.05 seconds)
{“model”:“HHCCJCY01HHCC”,“id”:“C4:7C:8D:6C:97:04”,“batt”:100}
02/11/2023 2:00:17 PM(-13.32 seconds)
{“model”:“HHCCJCY01HHCC”,“id”:“C4:7C:8D:6C:97:04”,“batt”:100}
02/11/2023 1:59:23 PM(-54.51 seconds)
{“id”:“C4:7C:8D:6C:97:04”,“service”:“0x180f”,“characteristic”:“0x2a19”,“success”:false}
02/11/2023 1:59:11 PM(-11.29 seconds)
{“model”:“HHCCJCY01HHCC”,“id”:“C4:7C:8D:6C:97:04”,“batt”:100}
02/11/2023 1:59:00 PM(-11.71 seconds)
{“model”:“HHCCJCY01HHCC”,“id”:“C4:7C:8D:6C:97:04”,“batt”:100}
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)
{“id”:“C4:7C:8D:6C:97:04”,“mac_type”:0,“rssi”:-79,“brand”:“Xiaomi/VegTrug”,“model”:“MiFlora”,“model_id”:“HHCCJCY01HHCC”,“moi”:0}
02/11/2023 1:58:51 PM(-1.01 seconds)
{“id”:“C4:7C:8D:6C:97:04”,“mac_type”:0,“rssi”:-73,“brand”:“Xiaomi/VegTrug”,“model”:“MiFlora”,“model_id”:“HHCCJCY01HHCC”,“moi”:0}
02/11/2023 1:58:49 PM(-1.08 seconds)
{“id”:“C4:7C:8D:6C:97:04”,“mac_type”:0,“rssi”:-78,“brand”:“Xiaomi/VegTrug”,“model”:“MiFlora”,“model_id”:“HHCCJCY01HHCC”,“moi”:0}
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)
{“id”:“C4:7C:8D:6C:97:04”,“mac_type”:0,“rssi”:-73,“brand”:“Xiaomi/VegTrug”,“model”:“MiFlora”,“model_id”:“HHCCJCY01HHCC”,“lux”:825}
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)
{“id”:“C4:7C:8D:6C:97:04”,“mac_type”:0,“rssi”:-77,“brand”:“Xiaomi/VegTrug”,“model”:“MiFlora”,“model_id”:“HHCCJCY01HHCC”,“lux”:814}
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)
{“id”:“C4:7C:8D:6C:97:04”,“mac_type”:0,“rssi”:-73,“brand”:“Xiaomi/VegTrug”,“model”:“MiFlora”,“model_id”:“HHCCJCY01HHCC”,“tempc”:24.1,“tempf”:75.38}

[DigiH]

@Montreal666

{“id”:“C4:7C:8D:6C:97:04”,“service”:“0x180f”,“characteristic”:“0x2a19”,“success”:false}

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

{“model”:“HHCCJCY01HHCC”,“id”:“C4:7C:8D:6C:97:04”,“batt”:100}

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.

[Montreal666]

@DigiH

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

Can you elaborate on how to do this?

@DigiH

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.

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

[DigiH]

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

BLE ESP32 gateway | OpenMQTTGateway v1.7.0

with the precondition of

BLE ESP32 gateway | OpenMQTTGateway v1.7.0

being true.

So that should have been my initial response

[Montreal666]

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

[Montreal666]

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

BLE gateway | OpenMQTTGateway v1.4.0

• 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!

[DigiH]

@Montreal666

Are all feature settings from this page non-persistent? IE: do I have to set retain flags and/or resend commands on bridge restart?

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

BLE ESP32 gateway | OpenMQTTGateway v1.7.0

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.

@Montreal666

I see that the “'activescan” feature disappeared from the docs (yesterday?), is it deprecated/replaced by “adaptivescan”?

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

[Montreal666]

@DigiH

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

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

@DigiH

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

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.

@DigiH

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

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

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

Thanks again

[DigiH]

@Montreal666

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

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

@Montreal666

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.

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.