[BUG] Tuya TS0041 TS0042 TS0043 - no battery #2227
Comments
The issue is not fixed in Z2M. and the code has been reverted and is not present in the current version: Actually the same issue is present in Z2M and not fixed: From the ZHA quirk point of view I would suggest to remove (in the replacement part) all the class TuyaSmartRemote0042TO(CustomDevice):
"""Tuya 2-button remote device with time on out cluster."""
signature = {
# SizePrefixedSimpleDescriptor(endpoint=1, profile=260, device_type=0, device_version=1, input_clusters=[0, 1, 6], output_clusters=[10, 25]))
# SizePrefixedSimpleDescriptor(endpoint=2, profile=260, device_type=0, device_version=1, input_clusters=[1, 6], output_clusters=[])
MODEL: "TS0042",
ENDPOINTS: {
1: {
PROFILE_ID: zha.PROFILE_ID,
DEVICE_TYPE: zha.DeviceType.ON_OFF_SWITCH,
INPUT_CLUSTERS: [
Basic.cluster_id,
PowerConfiguration.cluster_id,
OnOff.cluster_id,
],
OUTPUT_CLUSTERS: [Time.cluster_id, Ota.cluster_id],
},
2: {
PROFILE_ID: zha.PROFILE_ID,
DEVICE_TYPE: zha.DeviceType.ON_OFF_SWITCH,
INPUT_CLUSTERS: [
PowerConfiguration.cluster_id,
OnOff.cluster_id,
],
OUTPUT_CLUSTERS: [],
},
},
}
replacement = {
ENDPOINTS: {
1: {
PROFILE_ID: zha.PROFILE_ID,
DEVICE_TYPE: zha.DeviceType.REMOTE_CONTROL,
INPUT_CLUSTERS: [
Basic.cluster_id,
PowerConfiguration.cluster_id,
TuyaSmartRemoteOnOffCluster,
],
OUTPUT_CLUSTERS: [Time.cluster_id, Ota.cluster_id],
},
2: {
PROFILE_ID: zha.PROFILE_ID,
DEVICE_TYPE: zha.DeviceType.REMOTE_CONTROL,
INPUT_CLUSTERS: [
TuyaSmartRemoteOnOffCluster,
],
OUTPUT_CLUSTERS: [],
},
},
}
device_automation_triggers = {
(SHORT_PRESS, BUTTON_1): {ENDPOINT_ID: 1, COMMAND: SHORT_PRESS},
(LONG_PRESS, BUTTON_1): {ENDPOINT_ID: 1, COMMAND: LONG_PRESS},
(DOUBLE_PRESS, BUTTON_1): {ENDPOINT_ID: 1, COMMAND: DOUBLE_PRESS},
(SHORT_PRESS, BUTTON_2): {ENDPOINT_ID: 2, COMMAND: SHORT_PRESS},
(LONG_PRESS, BUTTON_2): {ENDPOINT_ID: 2, COMMAND: LONG_PRESS},
(DOUBLE_PRESS, BUTTON_2): {ENDPOINT_ID: 2, COMMAND: DOUBLE_PRESS},
} |
|
All TS004X quirks shall being converted to 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. |
|
@provinzio Are you using the quirk from #1746 or is the quirk from latest HA version? |
|
@javicalle I am currently using the quirk from the latest HA version |
Could you try with the custom quirk from #1746 (comment) You will need to remove and repair the device after enable the local quirk. |
|
tl;dr I implemented your propsed quirk, a battery level != 100% gets detected which looks promising. Everything else seems normal at first. I will wait for 1-3 days and check in again whether the battery level dropped accordingly and whether the buttons still work as expected I did the following steps in this order
But, the battery gets detected as 74% which is not 100%. It looks like the repairing did something. Perhaps I wasn't using the latest quirk after all and was stuck with an older quirk? Clicking the buttons of the switch does not fire an event, automations do not get triggered.
|
|
ZHA is only loading quirks then its starting so its not being loaded on the flay. Dont hurry we have lot of time until next HA is being released so better doing the test well ;-)) |
|
Ok I will do the following steps and check out whether the device functions normally
|
I realized, that the battery is at 100 % after doing this. So this is currently bad when looking at the battery information. I am out of time for today, I'll try to remove the quirk tomorrow and setup the latest HA quirk, which might have given me the correct battery info (see my post above). |
|
Quick update. The battery was updated after a while. So I am keeping the proposed quirk and check whether the battery issue (and perhaps also the missing clicks) are fixed with it. |
|
@javicalle Sorry, I was away for a couple days. I would be happy to test it and report back. I'm a little confused which is the latest quirk that needs testing. Any chance you could upload it as a text file? I have the TS0044 switch (4 buttons / 12 different actions). I just want to avoid editing the quirk myself and possibly introducing issues (I'm fairly new with Home Assistant). |
|
@cordvision ts0044_custom_removed_PowerConfiguration.py.txt I am currently testing
|
|
@provinzio which quirk are you testing? Is the My assumption was that the extra Also could be interesting to enable the debug logs and check the battery reports from your device. It is probably that device report itself the battery status over time but maybe also reports when any key is pressed, can you check? |
|
@javicalle yep Do you mean this file? If not please give me a hint where I can find the relevant file :) I find the The battery jumping is periodic and also through the night. I don't think that it interacts with any clicks or something else.
|
|
Zigbee is using 1-200 for battery % and 255 is not known so preposition is 0.5% |
|
I am stuck on this... I updated the quirk for all variants according to your suggestion. All show the same battery behavior. @javicalle looking for your guidance. Do you have an idea what we could check next? Is it worth to look at the debug logs? I am unfamiliar with that but could dig into it. |
|
I only having some TS004F devices but the 4 scene switch is very similar and different and is sending battery report from button 2 or 3 press (i dont remember with). Can you posting debug log from TS0044 then making pressing of all buttons and waiting 10 seconds between so we can see what the switch is doing (or not) with your updated quirk ? Then looking on your posted graf i think its normal battery readings. If you is getting high readings and can see its moving little up and down i think its all we can getting from the device then its how the device firmware is being done. |
|
Pitching in here... I have had ts0044_custom_removed_PowerConfiguration.py.txt installed now for a few days on a wall switch. Same sawtooth 40+20 min cycle pattern as you others. Here is a snippet from the logs from this night (TS0044 device identifier 0xEF55). Some observations in the logs:
|
|
Log ZHA TS00440xEF55 buttons.txt Timestamps (c:a):
|
|
The device is rejoining the network that shall not happening if all things is OK. And the device is sending one updated battery around 60 min and its OK but its have loosing the contact with the network (somthing is making it thinking that) and after the first rejoining and reporting next reporting is OK 60 min later and then next is start rejoining and sending battery report. |
|
flashed 4 LEDs = its rejoining the network :-(( |
|
I have neither TI or EZSP. It's Dresden. |
|
The wall switch device has a good connection to a IKEA TRADFRI bulb, 2m away from it (always on). I have 3 TS0044 units and they all behave the same way. One has the coordinator directly as parent. |
I uploaded the ts0044 quirk (I of course removed the .txt ending). After re-installing the device and re-starting HA, the custom quirk doesn't seam to have loaded. Under "Zigbee info" for the device, I see "Quirk: zhaquirks.tuya.ts0044.TuyaSmartRemote0044TO". I've used other custom quirks for this device before, and never had that issue. How do I ensure the custom quirk gets loaded? |
|
@provinzio Do you know if the sleep issue (first button pressed is ignored after a few hours of inactivity) is solved for the ts0044 with the quirk you posted? |
|
I cant testing it then my RaspBee is out of function for some time :-(( Is the switch that is having the coordinator as parent doing the strange blinking / rejoining as the other ones ? I think in the end we need sniffing how the system is setting u the switches in real. |
|
@cordvision You see if its loading the quirk in HA log then system is starting if you have debug logging enabled also what quirk the device is getting then the device is loaded of ZHA. |
|
@cordvision What coordinator is you using ? |
|
I'm using a conbee II. Previously and also for other devices, if I go to the device info tab and then click on "zigbee info", I would usually see the custom quirks name. In other words, I would expect to see this: Quirk: ts0044_custom_removed_PowerConfiguration.py However, I see this: Quirk: zhaquirks.tuya.ts0044.TuyaSmartRemote0044TO |
|
I haven't looked into the debug messages and thought that I should be able to see the updates in HA GUI |
|
I noticed something with my two switches in regards to battery percentage reporting... please see attached image:
|
|
The with dots is one updated / later version then the first was without. |
|
Aubess: IEEE: dc:8e:95:ff:fe:a0:5b:c1 What can you tell from those? |
IIRC that's true. HA don't considerer the value update until it changes. |
|
Both is using Silabs chips that good but i think the firmware is little different. |
|
Where do I find the info for the software/app version? (I’m fairly new at HA) |
|
Go to the device page -> three dots on the left -> Manage Zigbee device -> Clusters tab -> select Basic cluster in the first dropdown, select |
|
Its exactly the same for both switches: App Version 66 I made another interesting discovery: I got both switches to report battery percentage correctly. Here is what I did: |
|
Was you deleting the device from the device card before restring HA ? By the was tuya is normally using app version change for different builds of the firmware but is not 110% but likely your device is running the same firmware. The good thing is looks like the battery reporting is working OK on all your devices now :-))) |
|
So, which one will be the correct approach to that issue? |
|
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 Is that you is using and its working @cordvision ? |
|
@cordvision please, confirm the quirks version that you are using. This way we can point just to the validated ones if other users are getting problems with the update. |
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. |
@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 |
@MattWestb I am currently using these files. Please not, that I only edited the quirks I use, as I cannot test the others. |
|
Great and we dont have all devices so we cant testing all for sure. I saying Javicalle batch all quirks with the changes and making one PR !! :-)) |
|
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. |
|
Not really any new information, but I have a Zemismart button that matches So I'd also say that And you also wanted to add |
|
If @javicalle and i have the meaning that we need adding the Also all sniffs i have looking on from pairing devices with tuya ZVGW is doing it for all devices and Z2M is putting it on all new added tua devices. It can being that some device is changing behavior with the magic and need some patching but then they is working more normal after the fix and i think its the right way to going. |
The current way of always reading the 6 attributes when the class is initialized isn't great IMO. And you also mentioned that devices rejoin after those six attributes are read? It could only be called on For now, I'd only use |
|
Its not being sent on rejoining then the quirk is already loaded for the device the device must being one new joining for it being sent to the device (have sniffing it and its need being sent some milli seconds after the device is getting getting the network key or is not working. So if one user is baying one device and joining it ts getting the magic and never more if not deleting it in ZHA and waiting one minute and adding it new (if taking out the battery then is being retested its losing the magic saved in the chip). You do what you like and taking care of all TS04X devices also the TS004F. |
|
It seems that new versions for signatures that already have been quirked are needing the I will try to figure a new approach. Anyy advice or recomendation will be welcomed. |
|
This is where So if I do like that 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?). |
|
Would one of you be willing to apply the changes from #2288 as a custom quirk? Do note that to test this, you will have to download both the modified Tuya from zhaquirks.tuya import (to: from . (Then, restart HA, re-pair oder re-configure the device. Then see if the battery drain continues. All other changes regarding the remotes should be made in a future PR then. |
|
the buttons go up in action but there are systematically 2 actions which go up at the same time. Except that the automation sees only one, either the empty one or the other (1_single) when it sees the empty one then nothing happens. so you can press the button and see nothing happen. it's quite random. |
Describe the bug
The Battery value in Home Assistant is always at 100 %. Eventhough I use the switches for over a year now and already had to change the batteries.
To Reproduce
Using automatically discorvered quirks e.g.
zhaquirks.tuya.ts0042.TuyaSmartRemote0042TOExpected behavior
Correct battery value
Additional context
Related fixed issue from zigbee2mqtt Koenkk/zigbee2mqtt#6331
Related misbehavior of the buttons with the quirks #1746
The text was updated successfully, but these errors were encountered: