zha-device-handlers: [BUG] Tuya TS0041 TS0042 TS0043 - no battery

Great test results! I have been running SKIP_CONFIGURATION on three TS0044 devices for 18+ hours. Looking at the logs:

• 2 out of 3 devices sent battery percentage and voltage info on startup
• All 3 sent have sent 1 battery percentage and voltage packet each since startup. This would indicate that the devices are indeed updating once a day or so. Which is perfect
• No lost connection. Which means no need to rejoin network
• No bogus 100% battery packets
• Not even one first-press-ignored when using the devices (although there hasn’t been very much use)

ts0044_custom_removed_PowerConfiguration_SKIP_CONFIGURATION.py.txt

Great and we dont have all devices so we cant testing all for sure. But all TS004X and some other devices is working the same way so shall being no braking changes for all devices. The magic Z2M is using on all new tuya device and the not binding the power is done on the TS004X remotes and looks working OK for all. And sniffs i have seen and doing is tuya normally not setting up binding and reporting then adding devices.

I saying Javicalle batch all quirks with the changes and making one PR !! 😃)

They do NOT however show as updated in the HA GUI. Probably because there is no change in value.

IIRC that’s true. HA don’t considerer the value update until it changes.

In my case, my 3 devices are reporting battery about once every 4 hours. They do NOT however show as updated in the HA GUI. Probably because there is no change in value. So that’s fine. Logs:

2023-03-09 01:28:15.572 DEBUG (MainThread) [zigpy.zcl] [0x38F0:1:0x0001] Attribute report received: battery_percentage_remaining=172, battery_voltage=29 2023-03-09 01:36:02.299 DEBUG (MainThread) [zigpy.zcl] [0xFC43:1:0x0001] Attribute report received: battery_percentage_remaining=150, battery_voltage=28 2023-03-09 02:03:15.743 DEBUG (MainThread) [zigpy.zcl] [0x3106:1:0x0001] Attribute report received: battery_percentage_remaining=154, battery_voltage=28 2023-03-09 05:25:36.660 DEBUG (MainThread) [zigpy.zcl] [0x38F0:1:0x0001] Attribute report received: battery_percentage_remaining=172, battery_voltage=29 2023-03-09 05:33:28.748 DEBUG (MainThread) [zigpy.zcl] [0xFC43:1:0x0001] Attribute report received: battery_percentage_remaining=150, battery_voltage=28 2023-03-09 06:01:00.218 DEBUG (MainThread) [zigpy.zcl] [0x3106:1:0x0001] Attribute report received: battery_percentage_remaining=154, battery_voltage=28 2023-03-09 09:22:52.531 DEBUG (MainThread) [zigpy.zcl] [0x38F0:1:0x0001] Attribute report received: battery_percentage_remaining=172, battery_voltage=29 2023-03-09 09:31:05.316 DEBUG (MainThread) [zigpy.zcl] [0xFC43:1:0x0001] Attribute report received: battery_percentage_remaining=150, battery_voltage=28 2023-03-09 09:58:39.322 DEBUG (MainThread) [zigpy.zcl] [0x3106:1:0x0001] Attribute report received: battery_percentage_remaining=154, battery_voltage=28

What i was reading its the switches only reporting battery some time a day or then button is being pressed (i think its depends of the firmware version). Importing is that you is getting updates in some days do there is not not daying without reporting the level is low. Keep observing and look if you is getting rejoining devices or not.

Initial results for SKIP_CONFIGURATION test:

• Sets initial battery percent and voltage on startup. Seems ok. In my case 86%, 2.9V
• No losing connection and rejoining network so far (for 3 hours +)
• But also no more battery info packet since start
• No battery info along with buttons pressed

Seems promising. Hopefully there will be a battery info packet sometime.

This is where async_configure is called (join + reconfiguration): zha/core/channels/base.py (Restart HA should only call async_initialize, but not async_configure)

So if SKIP_CONFIGURATION is enabled, no binding and no reporting will be set up. There’s no perfect way to do this atm, but we could leave SKIP_CONFIGURATION disabled and then just override bind() and configureReporting() for required clusters: see example from LocalDataCluster

I do like that EnchantedDevice is just a quick replacement for CustomDevice. Since it somewhat doesn’t matter from which bind() method we make these calls, I think we could use a replacement for any cluster (that’s registered as a channel in ZHA and allows binding (Basic cluster is blocked for binding atm)). We should probably pull this out into its own issue though (EDIT, see: https://github.com/zigpy/zha-device-handlers/issues/2271)

To get back on topic, I would like to try if we can do a similar thing with these Tuya remotes to prevent the battery drain. Maybe we can just have a “NoReportPowerConfiguration” cluster that prevents binding and reporting (and that’ll be enough to prevent battery drain?).

Hopefully the battery values will not change for another week or so. Otherwise the battery will never last 2 years as advertised 😃

Anyway, the logs show battery % and V still being sent happily every 4 hours.

In my case, my 3 devices are reporting battery about once every 4 hours. They do NOT however show as updated in the HA GUI. Probably because there is no change in value. So that’s fine. Logs:

2023-03-09 01:28:15.572 DEBUG (MainThread) [zigpy.zcl] [0x38F0:1:0x0001] Attribute report received: battery_percentage_remaining=172, battery_voltage=29 2023-03-09 01:36:02.299 DEBUG (MainThread) [zigpy.zcl] [0xFC43:1:0x0001] Attribute report received: battery_percentage_remaining=150, battery_voltage=28 2023-03-09 02:03:15.743 DEBUG (MainThread) [zigpy.zcl] [0x3106:1:0x0001] Attribute report received: battery_percentage_remaining=154, battery_voltage=28 2023-03-09 05:25:36.660 DEBUG (MainThread) [zigpy.zcl] [0x38F0:1:0x0001] Attribute report received: battery_percentage_remaining=172, battery_voltage=29 2023-03-09 05:33:28.748 DEBUG (MainThread) [zigpy.zcl] [0xFC43:1:0x0001] Attribute report received: battery_percentage_remaining=150, battery_voltage=28 2023-03-09 06:01:00.218 DEBUG (MainThread) [zigpy.zcl] [0x3106:1:0x0001] Attribute report received: battery_percentage_remaining=154, battery_voltage=28 2023-03-09 09:22:52.531 DEBUG (MainThread) [zigpy.zcl] [0x38F0:1:0x0001] Attribute report received: battery_percentage_remaining=172, battery_voltage=29 2023-03-09 09:31:05.316 DEBUG (MainThread) [zigpy.zcl] [0xFC43:1:0x0001] Attribute report received: battery_percentage_remaining=150, battery_voltage=28 2023-03-09 09:58:39.322 DEBUG (MainThread) [zigpy.zcl] [0x3106:1:0x0001] Attribute report received: battery_percentage_remaining=154, battery_voltage=28

@cordvision nibo2 reported, that the battery reports aren’t visualized in HA but only come up in the debug logs when the value doesn’t change

Great test results! I have been running SKIP_CONFIGURATION on three TS0044 devices for 18+ hours. Looking at the logs:

• 2 out of 3 devices sent battery percentage and voltage info on startup
• All 3 sent have sent 1 battery percentage and voltage packet each since startup. This would indicate that the devices are indeed updating once a day or so. Which is perfect
• No lost connection. Which means no need to rejoin network
• No bogus 100% battery packets
• Not even one first-press-ignored when using the devices (although there hasn’t been very much use)

ts0044_custom_removed_PowerConfiguration_SKIP_CONFIGURATION.py.txt

I’m using the quirk from this post. The battery percentage looks fine now, but I noticed that it hasn’t updated in 17 hours. I have to see if it updates only when there is an actual change in battery level (which might take some time).

@MattWestb Yes, I deleted the device from HA (but I did it without the switch being activated while doing so), I then restarted HA… and just waited until the device added itself again.

I think TS004F is not needed and if i taking care or it then i have 2 of the problem devices (Dimmer switch and rotating knob and the first need extra config from ZHA).

So TS0041, 42, 43, 44 and 46 (the last is pity new and but i think is very like the 44 version) getting tuya magic, SKIP_CONFIGURATION and deleting power cluster that is on not EP1.

Is that you is using and its working @cordvision ?

Go to the device page -> three dots on the left -> Manage Zigbee device -> Clusters tab -> select Basic cluster in the first dropdown, select sw_build_id in the second dropdown, click “Read Attribute” and press a button on the remote to wake it up. Then read app_version (also on the Basic cluster)

I noticed something with my two switches in regards to battery percentage reporting… please see attached image:

I have neither TI or EZSP. It’s Dresden.

@javicalle I am currently using the quirk from the latest HA version

All TS004X quirks shall being converted to EnchantedDevice for not getting problems with new versions of them and all is remotes like TS004F that is converted.

Likely the magic can fixing this issue 2.

The TS004F we is using the OnOff on out cluster and that is making little problems with defaultresponse that need being sent in reversed direction that ZHA cant doing but i think its not the problem here.