Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prevent Tuya packets from being reprocessed by checking entire packet instead of seq only #8723

Merged
merged 2 commits into from
Feb 4, 2025

Conversation

jpbede
Copy link
Contributor

@jpbede jpbede commented Feb 3, 2025

Prevent duplicate Tuya packets from being reprocessed by comparing the entire packet instead of just referring to the seq.

There seem to be devices that repeatedly send their reports with the same sequence ID.

Koenkk/zigbee2mqtt#25605 should still be fixed, as far as I have seen, the packages were identical.

See Koenkk/zigbee2mqtt#26124 and probably Koenkk/zigbee2mqtt#26145, Koenkk/zigbee2mqtt#26148 also

@jpbede jpbede changed the title Prevent Tuya packets from being reprocessed by checking entire packet Prevent Tuya packets from being reprocessed by checking entire packet instead of seq only Feb 3, 2025
@Koenkk
Copy link
Owner

Koenkk commented Feb 4, 2025

Could you provide the debug log of when this happens? (with just seq in place).

There seem to be devices that repeatedly send their reports with the same sequence ID.

But since the seq is the same, those should be filtered already?

@jpbede
Copy link
Contributor Author

jpbede commented Feb 4, 2025

I probably wrote the PR description a bit misleading, sorry about that.

The issue is that there are devices that repeatedly send their reports with the same sequence ID, although data has changed. With the filter based on the seq in place, those reports get filtered leading to not to up to date sensors. When we now compare the whole data those reports wont get filtered.

[2025-02-03 19:50:39] debug: 	zh:controller: Received payload: clusterID=61184, address=52189, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=116, frame={"header":{"frameControl":{"frameType":1,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":false,"reservedBits":0},"transactionSequenceNumber":153,"commandIdentifier":6},"payload":{"seq":256,"dpValues":[{"dp":105,"datatype":2,"data":{"type":"Buffer","data":[0,0,1,241]}}]},"command":{"ID":6,"parameters":[{"name":"seq","type":33},{"name":"dpValues","type":1011}],"name":"activeStatusReport"}}

[2025-02-03 19:51:39] debug: 	zh:controller: Received payload: clusterID=61184, address=52189, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=116, frame={"header":{"frameControl":{"frameType":1,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":false,"reservedBits":0},"transactionSequenceNumber":156,"commandIdentifier":6},"payload":{"seq":256,"dpValues":[{"dp":105,"datatype":2,"data":{"type":"Buffer","data":[0,0,1,246]}}]},"command":{"ID":6,"parameters":[{"name":"seq","type":33},{"name":"dpValues","type":1011}],"name":"activeStatusReport"}}

@Koenkk
Copy link
Owner

Koenkk commented Feb 4, 2025

the transactionSequenceNumber seems to be different though, could you try with: if (utils.hasAlreadyProcessedMessage(msg, model)) return; ?

@Koenkk
Copy link
Owner

Koenkk commented Feb 4, 2025

Since quite some people are impacted I've updated it to use the transactionSequenceNumber now. Let me know if that is not correct.

@jpbede
Copy link
Contributor Author

jpbede commented Feb 4, 2025

Thanks, seems to work when bumping the zigbee-herdsman-converts manually and running pnpm run start!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants