-
Notifications
You must be signed in to change notification settings - Fork 29
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
You may want to consider exponential backoff for the calls to the plm #32
Comments
I'm in the middle of implementing the same kind of slider. I have an idea on how to fix this problem. On each queue entry you have an You would only use this feature in a call when you only care about the last If necessary I'll make a PR for this at the same time I implement the code On Sun, Apr 26, 2015 at 8:41 PM, iDVB notifications@github.com wrote:
|
I like the idea of the canceling pending actions over just blocking. I use the queuing to make sure all the commands get executed. For example if I make a single call to several devices, I want to make sure all devices get the update. For my UI, I don't send the next call to the same device until I've received a response (i.e. I throttle manually). Instead of creating a new "uniqueId" we could just us the device ID. insteon.cancelPending(deviceId); // cancel all queued commands for a device
light.cancelPending(); // cancel all queued for the light device object You could also call the |
For this to work you'd have to be sure a device can only have one command The name uniqueId kind of sucks, but I haven't been able to think of
This is still needed of course. On Mon, Apr 27, 2015 at 4:20 AM, Brandon Goode notifications@github.com
|
Another option is to have the cancel compare the current pending raw command and look for matches to cancel. Then you could customize it a the type Class. insteon.cancelPending(regex); // cancel all queued commands that match the regex
light.cancelPending(); // cancel all queued for the light device object
io.cancelPending(port); // cancel all queued messages for the io device with port as command2 |
Do you mean to write a custom cancelPending method for each device type? On Mon, Apr 27, 2015 at 4:23 PM, Brandon Goode notifications@github.com
|
But it's your package and your call (no pun intended). On Mon, Apr 27, 2015 at 4:25 PM, Mark Hahn mark@hahnca.com wrote:
|
I just pushed an update that has a cancelPending that cancels commands based on matching the raw Insteon command. This does not have to be the final solution, just my option. Please feel encouraged to call me out if you would like to see something different. @mark-hahn - Please continue to debate on this and future issues. - It makes for better code (and more enjoyable coding). |
No problem. I love to argue. :-) Speaking of arguing ... Having to deal with a raw insteon commands kind of sucks. Only the low I would like to offer again to code the queue-tagging option as a PR. Implementing your scheme to have each device implement a method to cancel On Mon, Apr 27, 2015 at 6:58 PM, Brandon Goode notifications@github.com
|
I'm not opposed to it. I think we could even support both options. Please create a PR with the tagging (even if it's only a start). I'm a visual person, so need to see some example code before I really get it. |
When thinking through the implementation and usage I realized what you have implemented is all that is needed. After looking at your code I saw that your current device methods use the device id, not the regex (except for IO). So my complaint about higher levels needing to know the hex isn't really valid. The code for IO also looks fine. I didn't realize you had implemented so much. Sorry for the unnecessary arguing. I was in love with my algorithm instead of just thinking things through. |
Sorry, I'm a bit late to the party on this one but here are my two cents. It sounds like you're planning to use a I think if you cancelPending of all until the last request,....then this module will have IMHO a similar flaw to many other HomeAutomation software, which is they take the easy way out and wait for the user to stop scrubbing the bar before they send out the level. |
What you are saying would be true if you used the cancelPending call in a You call cancelPending immediately before each call to set a value. Then On Tue, Apr 28, 2015 at 9:13 AM, iDVB notifications@github.com wrote:
|
Fair enough. Looking forward to test it out. Maybe if you have a suggestion/example of how to properly use it too? Thanks for your efforts here. |
Just place the cancelPending call before every fast-changing call. You can
One could argue that this should just be built-in in the core insteon Light On Tue, Apr 28, 2015 at 10:25 AM, iDVB notifications@github.com wrote:
|
It appears the cancelPending() method just returns true/false. Following the format of the other methods.... would it not be a good idea to have it also return a promise? |
The cancelPending method is synchronous and therefore the overhead of a promise isn't needed. At least that was my logic. |
The PLM hardware and Insteon infra is pretty slow, but people's expectations for UI are very high.
Consider a UI where the user can use a 0-100 slider bar to control their light.level() in realtime. Not just wait till the user stops dragging and releases.... but control the levels as the scrub the bar.
I've simulated this with my UI and
home-controller
and I think it's choking on the calls rather then handling them. It seems it just tries to have them all queued up regardless of how many.The text was updated successfully, but these errors were encountered: