Phype
commented
3 months ago While the robot is running and the local connection kept active, the robot seems to send async messages to the open channel when changing status (ex. cleaning -> go for charging), which remain in the socket queue. On next sendrecv(), which appears to expect an empty socket queue, an exception is raised if the received response can't be converted rightly (ex. "power mode can't be 4") because there's no message flag checking implemented. Ever observed this with your robots
If I remember correctly, the connection was actually closed by the robot on RX9 after sending a command, but I'm not sure anymore.
Wondering there needs to be a message dispatcher with callbacks - ever planned async status notifications?
As described in #24, I suspect that the support for doing anything other than linking the robot to a cloud account via the local socket interface was removed with a firmware update on RX9, as the official app doesn't make use of that feature anymore.
So from my point of view (who only has RX9 and RX9.2), local mode is dead. If you want to revive it for RX8, i'm happy to invite you to go ahead and raise a PR. But I won't be able to test it, so don't expect much support except general guidance.
Using the local variant for controlling two RX8 robots - so far it works, but there are some observations I wanted to share:
While the robot is running and the local connection kept active, the robot seems to send async messages to the open channel when changing status (ex. cleaning -> go for charging), which remain in the socket queue. On next sendrecv(), which appears to expect an empty socket queue, an exception is raised if the received response can't be converted rightly (ex. "power mode can't be 4") because there's no message flag checking implemented. Ever observed this with your robots? Wondering there needs to be a message dispatcher with callbacks - ever planned async status notifications?