deviceDeleted and deviceStopComm?

As I understand it, when a device is deleted, the following methods are invoked:

• deviceDeleted
• deviceStopComm

If the plugin has the method deviceDeleted it must either call deviceStopComm (if the plugin has the method) or do a super(Plugin, self).deviceDeleted(dev) at the end of the method.

Is there anyway in the deviceStopComm method to tell whether a device has been deleted or just disabled?

I realise that I can work this out but was wondering if there is a flag in the device (or somewhere) to indicate this?

Also at what point does the dev get actually deleted - is it after both of these methods end?

[matt (support)]

If the plugin has the method deviceDeleted it must either call deviceStopComm (if the plugin has the method) or do a super(Plugin, self).deviceDeleted(dev) at the end of the method.

Correct.

Is there anyway in the deviceStopComm method to tell whether a device has been deleted or just disabled?

Not in the base implementation, but you can add that functionality via your own implementation of deviceDeleted if you use an additional named argument (with default value) on your deviceStopComm implementation. In this case you wouldn't call the super() implementation, which I'm not sure I totally recommend because it is possible we could additional logic to the base implementation of deviceDeleted your implementation wouldn't have. Currently though it doesn't do much:

Code: Select all

   def deviceDeleted(self, dev):
      if dev.pluginId != self.pluginId:
         return      # device is not plugin based -- bail out

      if dev.configured and dev.enabled:
         self.deviceStopComm(dev)

Also at what point does the dev get actually deleted - is it after both of these methods end?

I think is probably indeterministic. While when the server initially starts broadcasting to the plugins the device is deleted it probably still exists in the database, it doesn't wait for the plugins to process the callback hooks to continue on with its logic (which will delete the device). So it might be possible that the device is still in indigo.devices dict, I wouldn't count on it. Probably by the time a plugin requested it from the Indigo Server it will be gone.

You may already know this, but you can see the base (super()) implementation of these methods in the file:

/Library/Application Support/Perceptive Automation/Indigo 7.x/IndigoPluginHost.app/Contents/Resources/PlugIns/plugin_base.py

I can't comment on the implementation details, but I will say that when I find myself asking similar questions I'm usually trying to do things the wrong way.

IOW, what exactly are you attempting to do that you think you need to know how this is working under the hood?

If you're trying to execute code in a plugin that will always get run when one of your devices is deleted, you can't. Because if the plugin is disabled, and then one of it's devices is deleted, your code will never get executed.

Thanks for the replies Matt and Joe.

It's my Roon plugin.

When a device is stopped (not deleted), I set the device state to disconnected and show an indigo.kStateImageSel.PowerOff image. As the deviceStopComm is being called when a device is deleted or just stopped, it was causing me issues doing this.

Using a named argument call as you suggest Matt, should solve the problem for me.

I need to know if a device is deleted while the plugin is running but as you note Joe, the plugin won't know about this if it isn't running. However this doesn't matter as when the plugin restarts it will "re-sync" all Indigo devices back with the actual Roon devices.

When a device is stopped (not deleted), I set the device state to disconnected and show an indigo.kStateImageSel.PowerOff image. As the deviceStopComm is being called when a device is deleted or just stopped, it was causing me issues doing this.

Seems to me it would be easier to set a try/except block around the code setting the state and image, and if it fails then ignore it.

[jay (support)]

Seems to me it would be easier to set a try/except block around the code setting the state and image, and if it fails then ignore it.

+1 (I think)...

It's a very Pythonic design pattern in instances like this: try to do what you want, catch the exception if it doesn't work, and if it doesn't really matter anyway just ignore the exception.

I actually went with a solution of storing the device.id in a plugin global dictionary (indigoDeviceBeingDeleted) in the deviceDeleted method.

Then in deviceStopComm, I check whether the device.id is in the dictionary, if it is I remove it from the dictionary and know the device is being deleted so I can avoid the standard (non-device deleted) processing, which is actually more than just setting a state and image.

I was then able to retain the super(Plugin, self).deviceDeleted(dev) at the end of the deviceDeleted method as suggested by Matt.