Closed provinzio closed 1 year ago
Related fixed issue from zigbee2mqtt Koenkk/zigbee2mqtt#6331
The issue is not fixed in Z2M. The fix from your link generated other errors:
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 PowerConfiguration
clusters except from endpoint 1. IE: for the TuyaSmartRemote0042TO
quirk:
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 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.
@provinzio Are you using the quirk from #1746 or is the quirk from latest HA version? @cordvision Do you mind to test the proposed change from https://github.com/zigpy/zha-device-handlers/issues/2227#issuecomment-1446556216 and check the battery behavior?
@javicalle I am currently using the quirk from the latest HA version
@javicalle I am currently using the quirk from the latest HA version
Could you try with the custom quirk from https://github.com/zigpy/zha-device-handlers/issues/1746#issuecomment-1437442942
You will need to remove and repair the device after enable the local quirk.
Other user is reporting 'jumping' values after apply the quirk. For that behavior I suggest to remove the PowerConfiguration
(my previous comment).
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. Then the first paring was with the old quirk can you later deleting the remote and waiting one minute and pairing it new and testing how its working ?
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
Ok I will do the following steps and check out whether the device functions normally
1. Upload Quirk 2. Reload ZHA 3. Delete device 4. Wait 1 minute 5. Repair device
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 ts0043_custom_removed_PowerConfiguration
. Until now I don't think that I had missing clicks. The battery value is jumping between a value and 100%. Ideas?
@provinzio which quirk are you testing? Is the TuyaSmartRemote0043TO
from your previous comment?
Whitout logs it would be hard to know but it seems that device is reporting double the battery, once with 100% and other (maybe) with the good one.
My assumption was that the extra PowerConfiguration
were responsible of it, but the quirk have remove it so... no idea.
Could you attach the diagnosis file from your device with the quirk?
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 TuyaSmartRemote0043TO
from ts0043_custom_removed_PowerConfiguration.py.txt
Do you mean this file? If not please give me a hint where I can find the relevant file :) zha-1b4a270315098112f906ebf272ff388d-_TZ3000_gbm10jnj TS0043-4c9b7002357cc58c20cbf2c2afa52d07.json.txt
I find the battery_percentage_remaining
value interesting. It's at 140, eventhough the value in Home Assistant says 70 %.
The battery jumping is periodic and also through the night. I don't think that it interacts with any clicks or something else. The 100% value stays ~20 minutes. The "real" value stays for ~40 minutes. Its not exactly 20/40 min but kind of. Which makes a whole cycle of 100 % back to the "real" value ~60 min long. Looks fishy to me, but I have no idea why it does that.
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. Zigbee is recommending reading the battery then the radio is in stable idle state for not getting the reading stable and i think tuya have not reading that PM. If reading then the radio is active / not stable idle state you is getting higher if the transmission is going well / fast and if its need repeating / waiting the reading is being lower. So i think the reading is OK for the device and its better then Xiaomi that is showing 100% most of the time until they is dead.
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). Log ZHA TS0044 0xEF55.txt
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. What is your coordinator type TI or EZSP ? Is the device have the coordinator as it parent or is it having one good or bad router as parent ? Look on the network map after updating it so its current.
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 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.
ts0041_custom_removed_PowerConfiguration.py.txt ts0042_custom_removed_PowerConfiguration.py.txt ts0043_custom_removed_PowerConfiguration.py.txt ts0044_custom_removed_PowerConfiguration.py.txt
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 ? Also have updated the IKEA lights so they is not running on old bad firmware with routing problems?
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
You must looking in the log if its somthing that making the custom quirk is not being loaded or not matching (custom quirks is having higher priority then loading).
For both, what version is the CornBee is running ?
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). Log ZHA TS0044 0xEF55.txt
Some observations in the logs:
* There are two distinctively different sets of packets received from the client in the 40+20 min cycle. I put some blank lines around the interesting bits for readability * "last_seen" does not seem to be reset ever (?) * A restart of ZHA, or indeed the entire HA, does not affect the timing of the 40+20 min pattern. Suggesting it is in no way initiated or reset by HA?
After rejoinning, PowerConfiguration cluster is reporting 100% battery but some time after is reporting the 'correct' value. That reports come from the same endpoint, so no mixed endpoints/reports here:
2023-03-07 03:59:15.876 DEBUG (MainThread) [zigpy.zcl] [0xEF55:1:0x0001] Attribute report received: battery_percentage_remaining=200, battery_voltage=30
2023-03-07 04:19:07.270 DEBUG (MainThread) [zigpy.zcl] [0xEF55:1:0x0001] Attribute report received: battery_percentage_remaining=174, battery_voltage=29
2023-03-07 05:01:01.854 DEBUG (MainThread) [zigpy.zcl] [0xEF55:1:0x0001] Attribute report received: battery_percentage_remaining=200, battery_voltage=30
All these availability issues seems to be the cause with the initial 100% battery report.
I have access to an IKEA Dirigera hub and will check if temporarily connecting the IKEA bulb will trigger a new firmware update. (Although my ZHA has OTA enabled for ikea_provider but who knows...)
@cordvision there seems to be different versions of the quirk files floating in this thread. This one works for me has power configuration removed in Replacement, not in Signature. It will show as "Quirk: ts0044_custom_removed_PowerConfiguration.TuyaSmartRemote0044TONibo2" in HA GUI device information if loaded.
@javicalle The log looks OK then both % and V is changing and following each other OK. I think taking away the power config from EP 2 and higher is good if ZHA is configuring reporting of it on all endpoints that can being strange if the device cant handling it OK on not EP1 clusters.
@nibo2 If you is having IKEA OTA enabled in ZHA is working OK and i dont knowing if Dirigera is updating light then i have not seen it but its updating all controllers to 24.5 and we have not getting all fixed so not doing controllers that you have in ZHA then you is loosing some functionality of them.
The log looks OK then both % and V is changing and following each other OK.
Yes, but it must not report such diferent values over time. They don't come from diferents endpoints, it comes from one endpoint reporting diferent when rejoinning.
I think taking away the power config from EP 2 and higher is good if ZHA is configuring reporting of it on all endpoints that can being strange if the device cant handling it OK on not EP1 clusters.
I agree with that.
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?
@cordvision I made a mistake with the TS0044 file I uploaded and I removed it from my post now, sorry for that. Please us the file from https://github.com/zigpy/zha-device-handlers/issues/2227#issuecomment-1458077076
@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?
It's not solved for me, but... I am still unsure, whether every device of mine is correctly using the quirk. Especially because I haven't removed and repaired all of them. I only repaired most of them; I removed only one one switch before repairing.
My different devices have different battery behavior:
1x TS0041 (ts0041_custom_removed_PowerConfiguration.TuyaSmartRemote0041TOPlusB), 2x TS0042 (ts0042_custom_removed_PowerConfiguration.TuyaSmartRemote0042TO) and 2x TS0043 (ts0043_custom_removed_PowerConfiguration.TuyaSmartRemote0043TO) all had send their battery level 11 h ago (when I repaired them without removing them first) and nothing since then. Looks good to me for now. I have to observe it for a few weeks to see, if it drops accordingly.
1x TS0043 (ts0043_custom_removed_PowerConfiguration.TuyaSmartRemote0043TO) has the sawtooth pattern [this is the device I removed before repairing]
1x TS0043 (ts0043_custom_removed_PowerConfiguration.TuyaSmartRemote0043TO) is still having 100 % at all times
I don't visualy monitor all my devices, so I can't give a precise answer, but I see at least one of my TS0042 flashing on a regular basis. Sometimes it has a missing button click after that, sometimes it does not.
My experience with TS004F DMS is still having 100% battery after one year but not so mush used but with one C2034 instead one larger that shall being in it so if not having the rejoining problem the battery can reporting 100% very long time.
I installed the switches in November and already replaced every battery once. Some switches already have their second battery.
The switches require a lot of energy, unfortunately...
Definitely these is not a normal behavior. Device would have some kind of problem (maybe keeping rejoining) that exhaust the battery.
What is the difference when I add a quirk and
I have the assumption that when I do the first. I get the correct battery curve (or at least a constant value at something below 100%). And when I do the second I get the sawtooth pattern, which might have the correct battery value as it's lower values.
Then you is doing changes in the quirk the device is having the old configuration save and its being updated the new parts but old like bindings and reporting is nut updated = its still left and the test is not working OK then its using partly old saved settings in the device. So every time making changes delete the device and restart HA and adding the device new.
@javicalle de(F)conz have digging very deep and the tuya magic is good and deleting the power cluster on EP >1 also but some TS004X device dont like being bond and configured power reporting on any EP. So we need not doing bind and configure of power cluster on this device and the device also EP1 is not getting problems and rejoining all the time. Its looks that the device is reporting battery on key press and also with some hours interval with no binding and reporting of power cluster (as normal with normal tuya Zigbee devices they is not setting up any thing only the magic and they is reporting).
https://github.com/dresden-elektronik/deconz-rest-plugin/pull/6787
Edit: deCONZ have making one PR implanting tuya magic now :-))
I was thinking this option can working then its looks Xiaomi is using it and they dont making any reporting config or bindings of there devices. SKIP_CONFIGURATION: True,
My guess was that the device report is working fine but HA is polling the value (every 60 min or so IIRC) and that part I suspect that is not working and causes the connection drop.
Lets explore the SKIP_CONFIGURATION
path. I can try a version later.
It would be fine to apply to all the TS004X
quirks, isn't it?
I will test SKIP_CONFIGURATION asap.
But on the whole the basic function of the wall switches has really improved with the new quirk, only rarely getting the first-press-ignored now.
I think some TS004F (DMS) is needing it for initializing all "new" endpoints but i think the 41, 42, 43, 44 and 46 shall working OK then they is not having any strange EPs.
I can testing it with the TS004F DMS and ROC if its working OK.
I think i have seen some tuya quirks having it but i dont remember witch it was :-(
Initial results for SKIP_CONFIGURATION test:
Seems promising. Hopefully there will be a battery info packet sometime.
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.
Great test results! I have been running SKIP_CONFIGURATION on three TS0044 devices for 18+ hours. Looking at the logs:
ts0044_custom_removed_PowerConfiguration_SKIP_CONFIGURATION.py.txt
So far so good and the most importing is is the device have stopping rejoining now and then. If they is not rejoining (after likely firmware crash) it im 110% sure we have fixing the problem only that you also is getting battery reporting little now and then from the remotes.
I am currently also running the Skip configuration. Since then (15h) I haven't received any updated battery values.
I am currently unsure whether the battery reporting is working (besides the initial value). @nibo2 so you received updated battery values after ~1 day?
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
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.TuyaSmartRemote0042TO
Expected behavior Correct battery value
Additional context Related fixed issue from zigbee2mqtt https://github.com/Koenkk/zigbee2mqtt/issues/6331 Related misbehavior of the buttons with the quirks https://github.com/zigpy/zha-device-handlers/issues/1746