UpdateStateOnServer Limitations?

Matt and Jay,

I'm running into an issue, which is probably a design limitation...

But what's a reasonable number of UpdateStateOnServer calls per second? The plugin I am currently working on is a active polling device. It actively is monitoring the comm port, and the packets it receives (approx 300-500 per second), can either be a "good", "Bad", or "Empty" packet...

The current design keeps track of these counts in the device states... But I believe that this is overloading the Indigo server, since the Indigo GUI locked up, and didn't start responding until I manually killed the plugin. (And had jumped from 0 empty's to 30,000 empty's in the state list).

I can write it to batch the updates, but I wanted to make sure you were aware of this potential limitation.

Also, is there someway to "batch" state updates for multiple states, so that I can set multiple states, and then push the updates for all of the states to the server at once?

- Ben

[matt (support)]

You'll definitely want to cache the state locally in the plugin process, then only call updateStateOnServer if the state actually changed. That isn't a requirement if a plugin is only calling it once every few seconds, but if you are calling it multiple times a second then you'll want to do some value caching and comparing in the plugin itself.

There isn't a batch state update yet, but I do have it on my stuff-to-look-into list already. Even if you had that though, I think you should cache and compare the values locally in this case.

You'll definitely want to cache the state locally in the plugin process, then only call updateStateOnServer if the state actually changed. That isn't a requirement if a plugin is only calling it once every few seconds, but if you are calling it multiple times a second then you'll want to do some value caching and comparing in the plugin itself.

There isn't a batch state update yet, but I do have it on my stuff-to-look-into list already. Even if you had that though, I think you should cache and compare the values locally in this case.

Just to point out, for example, the Empty value changes each time. So strictly speaking, in theory 300-500 times a second, that value is updated.
I'll have to work around this, but I would suggest adding some guidance in the SDK / Wiki.

- Benjamin

[matt (support)]

Is the empty value list really useful for the end user?

Keep in mind device states should be used for storing information the user will want to trigger off of, use in conditionals, or inspect on Control Pages. I don't know the details of what the empty list is, but it sounds like it is too low-level to be useful for the end user -- especially given that it changes hundreds of times a second.

Is the empty value list really useful for the end user?

Keep in mind device states should be used for storing information the user will want to trigger off of, use in conditionals, or inspect on Control Pages. I don't know the details of what the empty list is, but it sounds like it is too low-level to be useful for the end user -- especially given that it changes hundreds of times a second.

It's not an empty value, it's the number of empty packets received. And yes it can be helpful for diagnostics purposes. What I have done is just created a update schedule that it's updated on. But, the use of this data is limited, but it is a easy way to help ensure that the communication is properly occurring, and that the end user can see that some data communication is occurring properly.

- Ben

[matt (support)]

That seems too low-level to be useful for the end user. For your debugging perhaps, but I suggest you make a state "communicationGood" then have your plugin have the smarts to determine a threshold based on empty packets that sets it to True or False. The user isn't likely to care or understand about "emptyPackets" but really wants to know is "communicationGood", thus your plugin should provide the smarts/heuristics for that instead.