zha-device-handlers
zha-device-handlers copied to clipboard
TS0041 TS0044 TS0042 - missing presses and LED flashing
Describe the bug TS0041 TS0044 TS0042
- sometimes does not react and run associated automation on button press, even thought LED flashes
- LED(s) flashing at some interval about once and hour or so even when no button is pressed
TS004F does not have that issue
To Reproduce have TS0041 TS0044 TS0042
Expected behavior react on press all the time and do not flash leds Lrandomly"
Screenshots If applicable, add screenshots to help explain your problem.
Device signature
{
"node_descriptor": "NodeDescriptor(logical_type=<LogicalType.EndDevice: 2>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress: 128>, manufacturer_code=4098, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264, maximum_outgoing_transfer_size=82, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=True, *is_full_function_device=False, *is_mains_powered=False, *is_receiver_on_when_idle=False, *is_router=False, *is_security_capable=False)",
"endpoints": {
"1": {
"profile_id": 260,
"device_type": "0x0006",
"in_clusters": [
"0x0000",
"0x0001",
"0x0006"
],
"out_clusters": [
"0x000a",
"0x0019"
]
},
"2": {
"profile_id": 260,
"device_type": "0x0006",
"in_clusters": [
"0x0001",
"0x0006"
],
"out_clusters": []
}
},
"manufacturer": "_TZ3000_dfgbtub0",
"model": "TS0042",
"class": "zhaquirks.tuya.ts0042.TuyaSmartRemote0042TO"
}
Diagnostic information
Paste the diagnostic information here.
Don't remove the extra line breaks outside the ``` marks.
Additional logs
Seems to be announce issue? Same behaviour with zigbee2mqtt. With tuya gateway it sometimes do not react on press, or rather reacts with huge delay, but never fleshes leds.
The TS004F is having problem with default response that must being sent in the wrong direction for EP 2-4 for getting the communication working 100% and its not fixed in ZHA and i think the other TS004X can having the same problem if not getting the DR not OK.
I dont have and TS004X devices only TS 004F that is working little different.
If you having the hardware for sniffing it shall being great if getting it sniffed so can see how it working with tuya ZBGW !!
I Havel no idea how to sniff ZigBee communication. Maybe sdr? Is there some guide somewhere? Maybe fixing this And the TS0222 _TYZB01_kvwjujy9 devices would be less pain then spelling And replacing with others that might or might not work :)
I liked tuya before, but since they started replacing esp chips with their own and do weird zigbee hacks and also since now we have inexpensive alternatives; tuya stuff does not make much sense, there are some exceptions, like the zigbee plugs or the T+RH sensors that take 2 aaa batteries, but that is pretty much it from the devices that do have alternatives, i guess they still have some unique devices.
Some info: https://github.com/zigpy/zigpy/wiki/Sniffing-Zigbee-traffic Also Z2M is having some and also deCONZ with sniffing firmware (EZSP is using the same firmware as the normal coordinator).
https://github.com/Koenkk/zigbee2mqtt/issues/8072 < linking this here as there are some wireshark caps. already
I think that the quirk is need being updated to sending tuya magic for the device working OK wot we have seen in the linked Z2M issue and sniff from the tuya ZBGW.
I'm having the same issue with those switches (I have two TS0044). After inactivity for several hours, the first button pressed is ignored. It is as if the device goes into a sleep mode and you have to press a button to wake it up. There seams to be a sulution available for Zigbee2MQTT (see here: https://community.home-assistant.io/t/tuya-ts0044-first-action-ignored/475940) I hope this can be resolved as this switch is very popular and affordable. It's very reliable besides the mentioned issue...
@javicalle Is it working putting EnchantedDevice
here
https://github.com/zigpy/zha-device-handlers/blob/8122e9283589f4fff585e4cf03892bf87587e345/zhaquirks/tuya/ts0044.py#L27
or must is being added in all device classes ?
And how to do it right ?
https://github.com/zigpy/zha-device-handlers/blob/8122e9283589f4fff585e4cf03892bf87587e345/zhaquirks/tuya/ts0044.py#L46
@javicalle Is it working putting
EnchantedDevice
herehttps://github.com/zigpy/zha-device-handlers/blob/8122e9283589f4fff585e4cf03892bf87587e345/zhaquirks/tuya/ts0044.py#L27
I bet that can be done adding in the parent class:
class Tuya4ButtonTriggers(EnchantedDevice):
"""Tuya 4-button remote device triggers."""
Maybe even we can define the CustomDevice
in the parent class and remove from the extended ones, but must be double checked to be sure.
class Tuya4ButtonTriggers(EnchantedDevice, CustomDevice):
"""Tuya 4-button remote device triggers."""
class TuyaSmartRemote0044TI(Tuya4ButtonTriggers):
"""Tuya 4-button remote device with time on in cluster."""
class TuyaSmartRemote0044TO(Tuya4ButtonTriggers):
"""Tuya 4-button remote device with time on out cluster."""
...
@cordvision can you testing this quirk for TS0044 ? You need configure local quirks and unzipping the quirk in the directory and restart HA. ts0044.zip Instruction https://github.com/zigpy/zha-device-handlers/discussions/693#discussioncomment-857274.
Then ZHA is started and stable deleting one of your remotes from the device card and waiting one minute and adding it new (resetting the remote).
The trick is the system is sending tuya magic only then the device is not known for the system so its must neing one new paring not updating one in the system known device.
Pleas testing and reporting back !!
@javicalle i finding the same but its needs very mush testing and we dont have enough device for doing it safely and it can be that we is needing it for some devices that is not liking getting the magic. I also thinking the most importing is getting all sleepers getting the magic and then adding it for router devices then its needed (we knowing that some routers is also needing it but very likely most or all sleepers is doing it).
@MattWestb Thank you... I'm testing it as we speak and I will report back....
@MattWestb I already have a custom quirk running successfully. After adding th ts0044 quirk, all my zigbee devices stopped running and I'm getting the following error:
Logger: homeassistant.config_entries Source: zha_quirks/ts0044.py:47 First occurred: 19:26:21 (1 occurrences) Last logged: 19:26:21
Error setting up entry ConBee II - /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2492391-if00, s/n: DE2492391 - dresden elektronik ingenieurtechnik GmbH - 1CF1:0030 for zha
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 382, in async_setup
result = await component.async_setup_entry(hass, self)
File "/usr/src/homeassistant/homeassistant/components/zha/init.py", line 100, in async_setup_entry
setup_quirks(config)
File "/usr/local/lib/python3.10/site-packages/zhaquirks/init.py", line 409, in setup
importer.find_module(modname).load_module(modname)
File "
After deleting the quirk and re-starting again... everything is back to normal with no errors.
Tuya4ButtonTriggers
now inherits EnchantedDevice
(which shouldn't be the case IMO) and that also inherits from CustomDevice
.
Yet TuyaSmartRemote0044TI
and all other quirks also inherit CustomDevice
again. This doesn't work.
Either CustomDevice
can be removed everywhere where Tuya4ButtonTriggers
is also used, or just remove EnchantedDevice
from Tuya4ButtonTriggers
again (they are device automation triggers and not a device after all).
Then, replcae CustomDevice
with EnchantedDevice
in all those quirks.
@TheJulianJES I have to be honest, I don't understand a word you said.... I don't even know where to start. I'm very much a beginner with home assistant (I can follow step by step instructions, that is how I installed another quirk for a motion sensor I got, but I don't understand at all what you were describing).
It was more directed towards MattWestb/javicalle, but here's a modified version that might work. You still need to remove + re-pair the Tuya devices. Let me know if this works or crashes again.
Try this: ts0044_custom.py.txt
(Remove the .txt
from the file name, so it just has .py
at the end.)
@TheJulianJES Thank you! I just uploaded it and re-added one of my switches. So far everything works as expected. I'll report back in a few days (I can't easily replicate the sleep issue as it sometimes takes 12+ hours of inactivity for the device to go to "sleep"). Fingers crosse :-)
Thanks Julian. Sorry for all the troubles. 😓
No worries, happy to help where I can
@TheJulianJES I just wanted to report back: Unfortunately it didn't fix the issue. In fact, it actually got worse. Not only was the first button press still ignored after some time of inactivity, but I had the switches stop responding entirely a few times.
On a side-note: I also noticed that the "battery level" reporting (on both of my switches) started jumping from 100% to 70% and back (see here: https://prnt.sc/E-u-KtouHNRQ). This coincided on both switches with the time I loaded the "custom quirk". The switches are both less than 3 weeks old and I did put new batteries in when I got them.
Any idea what the problem might be? Also, can somebody confirm that the switch indeed works properly with Zigbee2MQTT?
Just wanted to report back as promised: So far my battery values have not updated. They remain the same.... not sure if this reflects the actual amount of battery I have left.
Possibly related:
- https://github.com/zigpy/zha-device-handlers/issues/2227
- https://github.com/zigpy/zha-device-handlers/pull/2288
Hi, I'm curious if there is any solution for this issue since it's still happening for me and it's super anoying. I have quite a lot of these switches so replacing them all will be quite expensive. I have the same issue as evlo where the buttons are missing presses when the devices go to sleep after some time.
I have the following switches which all have the same problem.
TS0041
, TS0042
, TS0043
& TS0044
When I expand Zigbee info on the device it does say that there's a quirk.
Does this maybe mean that it's a known issue or does this mean there is some sort of patch available?
Device signature
```json { "node_descriptor": "NodeDescriptor(logical_type=Diagnostics
{
"home_assistant": {
"installation_type": "Home Assistant OS",
"version": "2023.8.4",
"dev": false,
"hassio": true,
"virtualenv": false,
"python_version": "3.11.4",
"docker": true,
"arch": "x86_64",
"timezone": "Europe/Amsterdam",
"os_name": "Linux",
"os_version": "6.1.45",
"supervisor": "2023.08.3",
"host_os": "Home Assistant OS 10.5",
"docker_version": "23.0.6",
"chassis": "embedded",
"run_as_root": true
},
"custom_components": {
"dwains_dashboard": {
"version": "3.4.3",
"requirements": []
},
"ui_lovelace_minimalist": {
"version": "v1.3.6",
"requirements": [
"aiofiles==0.8.0",
"aiogithubapi>=22.2.4"
]
},
"spotcast": {
"version": "v3.6.30",
"requirements": []
},
"browser_mod": {
"version": "2.3.0",
"requirements": []
},
"localtuya": {
"version": "5.2.1",
"requirements": []
},
"hacs": {
"version": "1.32.1",
"requirements": [
"aiogithubapi>=22.10.1"
]
}
},
"integration_manifest": {
"domain": "zha",
"name": "Zigbee Home Automation",
"after_dependencies": [
"onboarding",
"usb"
],
"codeowners": [
"@dmulcahey",
"@adminiuga",
"@puddly"
],
"config_flow": true,
"dependencies": [
"file_upload"
],
"documentation": "https://www.home-assistant.io/integrations/zha",
"iot_class": "local_polling",
"loggers": [
"aiosqlite",
"bellows",
"crccheck",
"pure_pcapy3",
"zhaquirks",
"zigpy",
"zigpy_deconz",
"zigpy_xbee",
"zigpy_zigate",
"zigpy_znp"
],
"requirements": [
"bellows==0.35.9",
"pyserial==3.5",
"pyserial-asyncio==0.6",
"zha-quirks==0.0.102",
"zigpy-deconz==0.21.0",
"zigpy==0.56.4",
"zigpy-xbee==0.18.1",
"zigpy-zigate==0.11.0",
"zigpy-znp==0.11.4"
],
"usb": [
{
"vid": "10C4",
"pid": "EA60",
"description": "*2652*",
"known_devices": [
"slae.sh cc2652rb stick"
]
},
{
"vid": "1A86",
"pid": "55D4",
"description": "*sonoff*plus*",
"known_devices": [
"sonoff zigbee dongle plus v2"
]
},
{
"vid": "10C4",
"pid": "EA60",
"description": "*sonoff*plus*",
"known_devices": [
"sonoff zigbee dongle plus"
]
},
{
"vid": "10C4",
"pid": "EA60",
"description": "*tubeszb*",
"known_devices": [
"TubesZB Coordinator"
]
},
{
"vid": "1A86",
"pid": "7523",
"description": "*tubeszb*",
"known_devices": [
"TubesZB Coordinator"
]
},
{
"vid": "1A86",
"pid": "7523",
"description": "*zigstar*",
"known_devices": [
"ZigStar Coordinators"
]
},
{
"vid": "1CF1",
"pid": "0030",
"description": "*conbee*",
"known_devices": [
"Conbee II"
]
},
{
"vid": "10C4",
"pid": "8A2A",
"description": "*zigbee*",
"known_devices": [
"Nortek HUSBZB-1"
]
},
{
"vid": "0403",
"pid": "6015",
"description": "*zigate*",
"known_devices": [
"ZiGate+"
]
},
{
"vid": "10C4",
"pid": "EA60",
"description": "*zigate*",
"known_devices": [
"ZiGate"
]
},
{
"vid": "10C4",
"pid": "8B34",
"description": "*bv 2010/10*",
"known_devices": [
"Bitron Video AV2010/10"
]
}
],
"zeroconf": [
{
"type": "_esphomelib._tcp.local.",
"name": "tube*"
},
{
"type": "_zigate-zigbee-gateway._tcp.local.",
"name": "*zigate*"
},
{
"type": "_zigstar_gw._tcp.local.",
"name": "*zigstar*"
},
{
"type": "_slzb-06._tcp.local.",
"name": "slzb-06*"
}
],
"is_built_in": true
},
"data": {
"ieee": "**REDACTED**",
"nwk": 26756,
"manufacturer": "_TZ3000_5e235jpa",
"model": "TS0042",
"name": "_TZ3000_5e235jpa TS0042",
"quirk_applied": true,
"quirk_class": "zhaquirks.tuya.ts0042.TuyaSmartRemote0042TO",
"manufacturer_code": 4098,
"power_source": "Battery or Unknown",
"lqi": 188,
"rssi": -53,
"last_seen": "2023-09-13T10:30:09",
"available": true,
"device_type": "EndDevice",
"signature": {
"node_descriptor": "NodeDescriptor(logical_type=<LogicalType.EndDevice: 2>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress: 128>, manufacturer_code=4098, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264, maximum_outgoing_transfer_size=82, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=True, *is_full_function_device=False, *is_mains_powered=False, *is_receiver_on_when_idle=False, *is_router=False, *is_security_capable=False)",
"endpoints": {
"1": {
"profile_id": "0x0104",
"device_type": "0x0006",
"input_clusters": [
"0x0000",
"0x0001",
"0x0006"
],
"output_clusters": [
"0x000a",
"0x0019"
]
},
"2": {
"profile_id": "0x0104",
"device_type": "0x0006",
"input_clusters": [
"0x0001",
"0x0006"
],
"output_clusters": []
}
},
"manufacturer": "_TZ3000_5e235jpa",
"model": "TS0042"
},
"active_coordinator": false,
"entities": [
{
"entity_id": "sensor.keuken_schakelaar_battery_2",
"name": "_TZ3000_5e235jpa TS0042"
},
{
"entity_id": "sensor.keuken_schakelaar_battery",
"name": "_TZ3000_5e235jpa TS0042"
}
],
"neighbors": [],
"routes": [],
"endpoint_names": [
{
"name": "REMOTE_CONTROL"
},
{
"name": "REMOTE_CONTROL"
}
],
"user_given_name": "keuken_schakelaar",
"device_reg_id": "c790a705ce61aec838d69aab41d4a7e9",
"area_id": "keuken",
"cluster_details": {
"1": {
"device_type": {
"name": "REMOTE_CONTROL",
"id": 6
},
"profile_id": 260,
"in_clusters": {
"0x0000": {
"endpoint_attribute": "basic",
"attributes": {
"0x0004": {
"attribute_name": "manufacturer",
"value": "_TZ3000_5e235jpa"
},
"0x0005": {
"attribute_name": "model",
"value": "TS0042"
}
},
"unsupported_attributes": {}
},
"0x0001": {
"endpoint_attribute": "power",
"attributes": {
"0x0021": {
"attribute_name": "battery_percentage_remaining",
"value": 200
},
"0x0020": {
"attribute_name": "battery_voltage",
"value": 30
}
},
"unsupported_attributes": {
"0x0031": {
"attribute_name": "battery_size"
},
"0x0033": {
"attribute_name": "battery_quantity"
}
}
},
"0x0006": {
"endpoint_attribute": "TS004X_cluster",
"attributes": {},
"unsupported_attributes": {}
}
},
"out_clusters": {
"0x000a": {
"endpoint_attribute": "time",
"attributes": {},
"unsupported_attributes": {}
},
"0x0019": {
"endpoint_attribute": "ota",
"attributes": {},
"unsupported_attributes": {}
}
}
},
"2": {
"device_type": {
"name": "REMOTE_CONTROL",
"id": 6
},
"profile_id": 260,
"in_clusters": {
"0x0001": {
"endpoint_attribute": "power",
"attributes": {},
"unsupported_attributes": {}
},
"0x0006": {
"endpoint_attribute": "TS004X_cluster",
"attributes": {},
"unsupported_attributes": {}
}
},
"out_clusters": {}
}
}
}
}
@Rojoss Pleas enabling debug loging for ZHA and zigpy and posting the log then its happening so the devs can looking if somthing going wrong. Also make sure running latest HA the some fixes is implanted for this devices that looks have 2 "working modes" 1=Deep sleeping and missing events or 2=Good responding but draining batteries.
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.