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

Break socket recv() out into its own function #153

Merged
merged 2 commits into from
Jul 6, 2022

Conversation

uzlonewolf
Copy link
Collaborator

This PR:

  1. Moves self.socket.recv() into its own function
  2. Makes the recv() only read the header and payload of a single message
  3. Parses the message into the TuyaMessage() named tuple
  4. Moves the retcode into its own set of variables as it is not actually part of the header
  5. Spits out log.debug() messages if the header, footer, or CRC are wrong
  6. Misc other debugging message tweaks

Closes #152

…()) raise an exception instead of returning None when not enough data was received
@jasonacox jasonacox merged commit c4484f2 into jasonacox:master Jul 6, 2022
@jasonacox
Copy link
Owner

Nice! Thanks @uzlonewolf - This is a very clean / elegant approach and I'm trying to remember why we/I didn't address this already. I remember having it in my TODO list to address the multi-palyload condition.

On the second bit, I understand and appreciate the exception approach. I can see that as a breaking change for some users. I want to run through some tests to see how serious that would be before decide on version increment, etc.

Thank you!

@uzlonewolf
Copy link
Collaborator Author

uzlonewolf commented Jul 6, 2022

It shouldn't be a breaking change as it's only called from within the try/except block in _send_receive() - the except Exception as err: line will catch it and retry if there are any retries remaining.

Though now that I think about it, that retry may be a breaking change - previously, decode errors were caught a bit further down and resulted in a json error being returned instead of a retry. To restore this behavior we would just need to throw a specific exception and have a catch for it.

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.

Multiple received packets results in none getting decoded
2 participants