refactor Tuya decoding cluster 0xef00#1982
Open
pipiche38 wants to merge 2 commits into
Open
Conversation
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes the decoding of the Tuya 0xEF00 (TS0601) manufacturer-specific cluster
in
tuyaReadRawAPS, and addsunit-test coverage for the function.
Background
The 0xEF00 cluster delivers device datapoints (DPs) through several commands. In
both reference projects, commands
0x01(dataResponse),0x02(dataReport),0x05(activeStatusReport) and0x06(activeStatusReportAlt) share the samebody layout:
status (uint8)+transid (uint8)followed by a list ofdatapoints, each encoded as
dp (uint8)+datatype (uint8)+len (uint16)+data.The previous implementation handled only
0x01/0x02properly.Problems fixed
0x05activeStatusReportUNMANAGED, datapoints dropped0x01/0x020x06activeStatusReportAlt0x02mis-read as0x00, datapoints corrupted (e.g. Excellux NTCHT01)tuya_default_responseforwards the code (logical byte order, matchingModules/tools_fcf.py)Changes
Modules/tuya.py0x01/0x02/0x05/0x06into one datapoint-parsing loop, bounded byidx + 8 <= len(MsgPayload)to tolerate truncated trailing fragments.FCF & 0x04), extract the manufacturer code in logical/big-endian order, and strip it from the payload before parsing.tuya_default_response()now accepts and forwardsmanuf_codetozcl_raw_default_response(..., manufcode=...).tests/Modules/test_tuya.py(new) — 24 tests covering command demux, single/multi datapoint parsing for0x01/0x02/0x05/0x06, manufacturer-specific frames, MCU version (0x11), time sync (0x24), gateway status (0x25), no-op commands, and the UNMANAGED fallthrough.Testing
python -m py_compile Modules/tuya.py✅pytest tests/Modules/test_tuya.py→ 24 passed ✅pytest tests/→ 1187 passed ✅flake8 ... --select=E9,F63,F7,F82→ 0 ✅Compatibility
No persistent data-format or configuration changes. Behaviour for
0x01/0x02is unchanged;
0x05/0x06and manufacturer-specific frames are now decodedcorrectly rather than dropped or corrupted. Backward compatible with stable8.