zha-device-handlers icon indicating copy to clipboard operation
zha-device-handlers copied to clipboard

Add TS0502B support

Open rubdos opened this issue 2 years ago • 6 comments

Proposed change

Adds support for some Tuya TS0502B models.

Additional information

Fixes #2637

Checklist

  • [ ] The changes are tested and work correctly
  • [x] pre-commit checks pass / the code has been formatted using Black
  • [ ] Tests have been added to verify that the new code works

rubdos avatar Oct 10 '23 11:10 rubdos

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 86.90%. Comparing base (ddb102c) to head (f297c2e). Report is 115 commits behind head on dev.

Additional details and impacted files
@@            Coverage Diff             @@
##              dev    #2639      +/-   ##
==========================================
+ Coverage   86.89%   86.90%   +0.01%     
==========================================
  Files         282      283       +1     
  Lines        8628     8638      +10     
==========================================
+ Hits         7497     7507      +10     
  Misses       1131     1131              

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

codecov[bot] avatar Oct 25 '23 06:10 codecov[bot]

Done in the location you pointed at; should that be changed in the signature itself too?

I still have the reconnecting/flapping behaviour, and the light still recognised as RGB in Home Assistant. I was basing myself of a similar Lidl model (lidl/cct.py), but that provides a custom LidlCCTColorCluster; should I do something alike?

image

image

(Is niet meer beschikbaar -> Is not available anymore; "is vervalled" -> "has expired")

rubdos avatar Oct 25 '23 06:10 rubdos

still recognised as RGB in Home Assistant

My bad, I was running a different version of the quirk on my Home Assistant, which still had the Color cluster exposed in the replacements.

rubdos avatar Oct 25 '23 22:10 rubdos

Looks like I might be having an issue related to the Tuya device needing enchantment

2023-10-26 19:00:17.859 DEBUG (MainThread) [zigpy.appdb] Error handling '_save_attribute' event with (a4:c1:38:c1:28:2d:a6:52, 1, 0, 4, '_TZ3210_xwqng7ol', datetime.datetime(2023, 10, 26, 17, 0, 17, 844077, tzinfo=datetime.timezone.utc)) params: FOREIGN KEY constraint failed
2023-10-26 19:00:17.860 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'306021a9602a15b58b944a04aa5592099d4e2797d0d85bd95beb4b48c4bf9ba6edcdddedb0b0e6db9ec0698d79a07e'
2023-10-26 19:00:17.864 DEBUG (MainThread) [zigpy.appdb] Error handling '_save_attribute' event with (a4:c1:38:c1:28:2d:a6:52, 1, 0, 5, 'TS0502B', datetime.datetime(2023, 10, 26, 17, 0, 17, 844101, tzinfo=datetime.timezone.utc)) params: FOREIGN KEY constraint failed

I am rather lost in Zigbee and the debugging skills required, especially since this device would be part of an already very busy network... I've attached a debug log. The device has IEEE MAC a4:c1:38:c1:28:2d:a6:52. ha-pair-log-3.log

If you could guide me a bit in how I can debug this, or in what is still going wrong, that would be really appreciated :-)

rubdos avatar Oct 26 '23 17:10 rubdos

Error handling '_save_attribute' event with is somewhat normal when the device isn't paired completely yet, as not all information is in the database, so the attribute updates also won't save yet.

What are the actual issues with the device? It still leaves the network after joining?

TheJulianJES avatar Nov 01 '23 00:11 TheJulianJES

There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. Thank you for your contributions.

github-actions[bot] avatar Apr 29 '24 01:04 github-actions[bot]