deviceStopComm and deviceStartComm not getting called

Under what circumstances would deviceStopComm and deviceStartComm methods not be called as normal?

I am working on a plugin and am completely stumped by this.

When the plugin is reloaded, both deviceStopComm and deviceStartComm run as expected (for all devices). I also created a couple menu items to invoke self.prepareToSleep and self.wakeUp, and again the methods are called as expected.

However, if I disable/enable device communication in the UI, edit a device, or create a new device, neither method is called.

I really just don't get it.

Ok, so this is likely obvious to most, but maybe I can save another neophyte a few hours of frustration.

I had made other plugins that defined devices, but none of them had needed the deviceUpdated method. Likewise, I had a couple plugins that used deviceUpdated in conjunction with indigo.devices.subscribeToChanges, but did not define any devices of their own. My problem here is that both things are true.

Having both plugin-defined devices and a deviceUpdated method defined means that it is the responsibility of the plugin to stop and start comm with the device.

Now I need to find out what the default implementation of deviceUpdated actually does so I can replicate it. (I need to keep the method defined in the plugin to track other changed devices.)

This stuff is always so obvious after you figure it out...

Now I need to find out what the default implementation of deviceUpdated actually does so I can replicate it. (I need to keep the method defined in the plugin to track other changed devices.)

No, you just need to call the base class as part of your implementation:

Code: Select all

    def deviceUpdated(self, oldDevice, newDevice):
        indigo.PluginBase.deviceUpdated(self, oldDevice, newDevice)


[matt (support)]

Joe is correct. In general you should always call the parent class method notification callbacks, unless the callback is something only your plugin instance defines (like a ConfigUI control action). The validateDeviceConfigUI() and closedDeviceConfigUi() (and all the other variants: action, trigger, etc) don't have parent implementations that do anything (they just return) so they can be skipped.

Is there a page in the wiki that discusses the requirement of when to call deviceStartComm and deviceStopComm?

[matt (support)]

Besides being called in the obvious spots (when the plugin starts up, shuts down, a device is created/deleted, or the user enables/disable communication), the base implementation of deviceUpdated() checks to see if any pluginProps on the device have changed. If they have, then it calls didDeviceCommPropertyChange() to check to see if the property should cause a shutdown/restart to occur. By default all properties do since the base implementation cannot know what is a comm related property and what isn't. So a plugin can make it smarter and have less stop/start device cycles (calls) by explicitly defining it to only return True for properties that need to force the device to stop and restart itself, like this:

Code: Select all

   def didDeviceCommPropertyChange(self, origDev, newDev):
      if origDev.pluginProps.get('serialPort', None) != newDev.pluginProps.get('serialPort', None):
         return True
      return False

I'm not sure if that answers your question or not.

Thank you both.