I’ve just measure the old battery voltage => 3V.
But I have a cheap multimeter which is not very accurate. So it probably doesn’t mean much.
Also, I’m no expert but it seems to me that measuring the voltage of a battery “alone” doesn’t give any real information about its condition.
I will continue to monitor it but at this time, the sensor work great. No ghost event.
Switched the battery of one sensor few minutes ago, leaving one untouched. Until then:
Will monitor the sensor for the next couple of hours/maybe 1 to 2 days.
Old battery: 3.00 V
New battery: 3.25 V
So not really a dead battery.
It is indeed a strange case, so far I haven’t managed to re-create the issue in my local test setups. But also using a fresh battery.
I wonder if the sensitivity may also relate to temperature change due the time of year, but have no clue how the sensor works internally.
One thing to also keep in mind is that changing the battery actually does a full device power-cycle/reboot. So beyond the voltage that might also help to bring a device into a valid state. Aka “have you tried to turn in off and on again”.
For my sensor nothing has changed, even with a 0.25 V more fresh battery. Swapped battery, without repairing/soft repairing. Only a few hours of silence between 21:22 and 07:58 last night.
Sensitivity reported as 0 in Phoscon API. Can I trust that value? Another theory is the sensitivity is way too sensitive and actually higher than shown. Just a random guess, based on the sensitivity trouble from Aqara vibration sensor resets sensitivity.
The values currently used when configuring the sensitivity are the same the official Aqara hub is using. These where obtained by sniffing the traffic of the hub and sensor https://github.com/dresden-elektronik/deconz-rest-plugin/pull/7208
See Discord, upon sniffing the Aqara app / Hub M2, it appears that the Xiaomi vibration sensor uses Zigbee values 1: High, 2: Medium, 3: Low.
The device seems to accept and report back any value, even higher then 21. This was carried over from the C++ code when the sensor was supported initially, but, apparently, never verified.
Note they are inverted to what the deCONZ REST-API has as we map 0 = low, 1 = medium, 2 = high.
The actual currently on device value can also be seen in the deCONZ GUI Cluster Info Panel on the Basic Cluster, the attribute is 0xFF0D. The attribute is queried once per hour and updated if different to the API configuration.
Here in my case the API is configured as { sensitivity: 0 } hence the attribute is 3.
Completely fine and stable (constantly at 0, checked several times the last days):
So how to proceed. 2 out of 3 sensors still with massive phantom trigger events since deCONZ 2.29.5. Running latest 2.30.2 and still nothing improved.
Can you try like hiteule to catch the ASDU from logs ?
To see if the issue is from the device (hardware or setting) or from deconz core ?
14:09:08:916 APS-DATA.indication srcAddr: 0xFC40, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0101, lqi: 255, rssi: -67
14:09:08:918 asdu: 18080a5500210100
If you can instruct on how to do and it does not take several hours, I can try.
Aside from logs: how can hardware behavior change with a software update.
In the add-on configuration the logging can be enabled in the configuration.yaml
The add-on configuration.yml needs to enable logging for info and aps
device: >-
/dev/serial/by-id/...<your-device>
dbg_info: 1
dbg_aps: 2
The add-on Logs tab should then show respective output.
Or to only enable the logs for a session you can open the deCONZ GUI via VNC of add-on and enable them in:
Help → Debug view
These are also shown in the add-on Log tab and can be copied from there.
