deviceStartComm and deviceStopComm Plugin Question

Hi all.

I'm running into a bit of a plugin design issue. In working on a Pioneer VSX-1021-K Receiver plugin, I'm not sure how best to perform initial connection status queries. As currently designed, the plugin stores a number of infrequently changed receiver parameters (such as display language, tuner preset names, and input source names) properties for the plugin device (i.e. in the data accessible in the pluginProps dictionary for a device). The method I created to query the receiver for this information is called from within the deviceStartComm method. The problem is that I get into a continuous loop when updating the device properties on the server because deviceStopComm and deviceStartComm are called each time the properties for a device are updated.

Is there a better place to put these initial data gathering method calls? Should I be storing those infrequently changed parameters as device states instead? I'm not familiar with multi-threading programming, so the less thread management (e.g. zero) that I have to do in this plugin, the better. I'm currently using the runConcurrentThread method to loop through a list of devices, calling the "connect" method I created to connect to the receiver associated with each Indigo device and reading data from their respective telnet connections each loop cycle. If I were to put the data gathering method calls within the runConcurrentThread method, what would be the best way to ensure such calls aren't executed more often than necessary?

Thanks for the help.

[jay (support)]

Doesn't seem like making them states is particularly useful. I think I'd continue to do it in deviceStartComm. To avoid the potential for a loop, you can implement this method:

Code: Select all

def didDeviceCommPropertyChange(self, origDev, newDev):
   # Return True if a plugin related property changed from
   # origDev to newDev. Examples would be serial port,
   # IP address, etc. By default we assume all properties
   # are comm related, but plugin can subclass to provide
   # more specific/optimized testing. The return val of
   # this method will effect when deviceStartComm() and
   # deviceStopComm() are called.
   if origDev.pluginProps != newDev.pluginProps:
      return True
   return False


The purpose of that method in the plugin_base.py file is to determine if deviceStopComm/deviceStartComm are called when a device's props are changed. As you can see from above, the default behavior is to return True if any of the props changed. However, you really just want a device to be restarted when a more specific subset of properties is changed. So, implement that method in your plugin.py file, have it only return True when the critical properties change, and False when those other parameters change.

Awesome! Thanks for the quick help Jay. I'll give that a try.

That worked great Jay! Thanks! Now on to developing more callable actions.