Concurrent Thread Plugin level vs device level.

yeah.. was thinking the same thing - some kinda FIFO implementation to queue up all these Lightify Scene commands. I do like the way my core Plugin (Dimmer type extension) is working however, as it is pretty responsive to switch/keypad commands from my Insteon devices. Maybe I'll prioritize commands from my Insteon devices higher, and allow just these background 'Light Scene Executions' to lag if needed. Not sure if I'll try to handle send/recv independently though and I may just serialize them from a round-trip perspective.

thanks again for the tip.

Made some decent progress in terms of serializing access to the hub.. Quick summary:
- Each scene is executed in a different thread
- The 'scene threads' don't actually send msgs to the hub.. Only add commands to a queue
- Queue is processed via the main Plugin class - 'runConcurrentThread' method
- Lock object (for Plugin class) is used to ensure that only 1 command is executed at a time - either via Plugin Class 'runConcurrentThread' or Plugin class primary method for interactions from my Insteon devices - 'actionControlDevice'
- priority for the lock is given to 'actionControlDevice'.. so any queued up commands in 'runConcurrentThread' must wait for 'actionControlDevice' to finish.

Anyhow.. appreciate the help..

I do have 1 question as I am digging into this stuff deeper.. Can you confirm the behavior of a Plugin class and its own multi-threading behavior. I believe 'actionControlDevice' is a blocking call is that right? So basically commands/etc triggered from Insteon devices will be serialized and wait for prior executions of 'actionControlDevice' to complete. Is that right?

[jay (support)]

I do have 1 question as I am digging into this stuff deeper.. Can you confirm the behavior of a Plugin class and its own multi-threading behavior. I believe 'actionControlDevice' is a blocking call is that right? So basically commands/etc triggered from Insteon devices will be serialized and wait for prior executions of 'actionControlDevice' to complete. Is that right?

If I understand your question, yes. Each call to actionControlDevice (and, in fact every call to the plugin from the server) are serialized and wait for a return. This is why time.sleep() anywhere in the Plugin class is bad (unless it's in runConcurrentThread, in which case it should be self.sleep()).