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

EZSP: Removed the queue for sending commands to devices #727

Merged
merged 2 commits into from
Jun 26, 2023

Conversation

kirovilya
Copy link
Contributor

This allows to send multiple commands without waiting for a response from the device.
Useful when the signal from the device to the coordinator is bad.

This allows you to send multiple commands without waiting for a response from the device.
@Koenkk Koenkk merged commit 95c8795 into Koenkk:master Jun 26, 2023
1 check passed
@Koenkk
Copy link
Owner

Koenkk commented Jun 26, 2023

Thanks!

@matt-oakes
Copy link

Hi @kirovilya @Koenkk,

I can see that other adapters such as Z-Stack have this queue on the sendZclFrameToEndpoint method too. Is there a reason why it can't be removed for those adapters as well as EZSP?

FYI, Thanks for the great library!

@Koenkk
Copy link
Owner

Koenkk commented Oct 6, 2023

@matt-oakes for z-stack it is needed to not ddos the coordinator.

@matt-oakes
Copy link

Thanks for the reply! Is there not also a queue inside znp which should mean that only one message at a time is sent?

return this.queue.execute<ZpiObject>(async (): Promise<ZpiObject> => {
Is there a need for two queues?

I beleive EZSP also has this queue when it comes to actually sending commands

return this.queue.execute<EZSPFrameData>(async (): Promise<EZSPFrameData> => {

This makes sense to me as you want to serial port to be used serially, but I'm not not sure what the "outer" queue in z-stack is doing.

@kirovilya
Copy link
Contributor Author

For ezsp, I removed the queue when sending a command to a device, so as not to wait for the successful completion of the previous command for the same device.
The need was that sometimes delivering a command to the device and confirming delivery can take a long time (up to 10 seconds or more) and in case of a bad signal, it will not even reach the device. And at this time the user’s device “freezes” and does not react at all, but after a timeout, all his sent commands will come out with a timeout error.
If you remove the waiting queue, then all commands will be sent (some of them will reach the device) and only those commands that did not receive a response due to a timeout will be returned with an error. This way we keep the device available in case of communication problems.

@matt-oakes
Copy link

Understood. Does this mean that Z-Stack would also benefit from having the same change made?

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.

None yet

3 participants