Skip to content

Conversation

@Debenben
Copy link
Contributor

@Debenben Debenben commented Jan 9, 2022

During a couple of different tests, I came across the following problem, here illustrated in a reproducible way for motor rotation:

const motorA = await hub.waitForDeviceAtPort("A"); motorA.requestUpdate(); // requestUpdate for default mode 0x00 motorA.on("rotate", () => { // motorA._mode is changed to 0x02 console.log("recieved rotate"); }); // update for mode 0x00 arrives, parsing as mode 0x02 throws ERR_OUT_OF_RANGE 

For my TechnicMediumHub this change is working perfectly and fixes the problem. I would recommend to test it with some different hub before merging though.

I am not happy about device._mode now having a setter function even though it is still labelled as readonly property, and also the names of the new function in general, but could not come up with better ones so far.

@nathankellenicki
Copy link
Owner

Thanks for this. I need to do a bit more testing with this so I'll do some this week with different hub types. I recognise the original issue though, good find.

device._mode is used to interpret incoming port value messages. When changing the mode on a hub, the recieved port values are for the old mode until the port input format message with the new mode has arrived.
@Debenben
Copy link
Contributor Author

@nathankellenicki Did you encounter any issues with this? For me this change works well and was sufficient to solve all issues.

If you are unsure, one could add a mechanism with a timeout to request the mode again if no response is recieved and additionally ignore messages that do not have the expected size.

@nathankellenicki
Copy link
Owner

18 months later and merged. :D Thanks again!

@nathankellenicki nathankellenicki merged commit ba1348e into nathankellenicki:master Dec 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

2 participants