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
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…
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.
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
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 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 ?
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.