Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

retrography
Copy link
Contributor

…sensor

@retrography
Copy link
Contributor Author

retrography commented Apr 20, 2024

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

@retrography
Copy link
Contributor Author

retrography commented Apr 23, 2024

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

@SwoopX
Copy link
Collaborator

SwoopX commented Apr 23, 2024

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
Copy link
Collaborator

Smanar commented Apr 24, 2024

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants