search

dresden-elektronik / deconz-rest-plugin

deCONZ REST-API plugin to control ZigBee devices
BSD 3-Clause "New" or "Revised" License
1.9k stars 498 forks source link

Fix the battery level reporting for Tuya TS2020 human presence sensor #7716

Open retrography opened 5 months ago

retrography commented 5 months ago

…sensor

retrography commented 5 months ago

This is split from #7633. Please heed the discussion over there.

retrography commented 5 months ago

@Smanar, I will need help with implementing this. It goes beyond my understanding of how the DDFs work.

SwoopX commented 5 months ago

Copying manups last feedback over here for easy reference:

The battery differences between firmware versions and devices introduce more complexity than I like. Perhaps we can add a small dynamic thing to figure this out without having to add multiple DDFs and check versions.

Something like a new non public item which tracks the maximum value ever reported. Pseudo code for state/battery and config/battery "parse" handler:

var m = R.item('config/max_battery_reported');
if (m.val < Attr.val) m.val = Attr.val;

if (m.val > 100) Item.val = Attr.val / 2;
else Item.val = Attr.val;

Here the config/max_battery_reported (default: 0) just tracks the maximum reported value, which is also stored in database if changed. And the actual battery value will then be adjusted accordingly.

This requires that the battery value for a 200 firmware is reporting at least once while charge is more than 50 % but that's not unrealistic.

As I see, Erik found a rather elegant solution on a small scale for the Tradfri shortcut button from Ikea. There, the application version determines which divisor is applied for the battery calculation.

I cannot even say if this would be necessary in this case here. I had a look at 1-2 device requests supposedly covered by this DDF and they all miss the relevant screenshot showing the relevant attribute vales 🤔 This all leaves a strange gut feeling.

Smanar commented 5 months ago

I have see the problem with this device ? You have different version with same manufacture name that need different compute ?

I have at least two versions of this sensor. _TZ3040_bb6xaihh (Application version 72) and _TZ3000_msl6wxk9 (Application version 70). Only one of my bb6xaihh sensors report version 1.0.8 in Phoscon. The others don't report anything. I am not sure from which cluster that attribute is read. For both these versions the battery reporting code works. At the very least it works better than always reporting 0!

So they have different Manufacture name ?

Only one of my bb6xaihh sensors report version 1.0.8 in Phoscon. The others don't report anything

Ha ? You have tuya device without attribute 0x0001 in cluster 0x0000 ? Or they are not in the "tuya" folder ? (The DDF use relative path)