Plugin shutdown on failure?

Reading theIndigo Plugin Developer's Guide v2.0 documentation it states:

Plugin Fatal: Errors that occur because of invalid XML or a failure inside the plugin initialization code (init method) are considered fatal. They will log an error and cause the Indigo Server to temporarily suspend the plugin – the plugin will remain enabled but won't be running. Once the errors are corrected, the plugin can be restarted by its Reload menu option. Because the plugin is still in the enabled state, it will also be restarted on the next Indigo Server restart.

Is there a way for a plugin to terminate itself if it concludes that it is unable to start or whilst running it has got a permanent error that can't be resolved without user intervention. i.e because a network is missing. The description above infers that it is only Indigo that can make the decision and close the plugin down?

A pertinent example is Netatmo which has been having seemingly major problems with its servers. The Netatmo plugin goes into a loop trying to reconnect every 10 seconds and fills up the log with error messages while it is unable to connect. The user (i.e. me in this case) disables the plugin and a number of hours later retries to see if Netatmo have sorted themselves out. It would be useful for a plugin to close itself down if it it is going into a seemingly permanent failure mode. btw this isn't a comment on the Netatmo plugin but just using it as an example.

In my case it is the Alexa-Hue Bridge - if it can't get access to the network then it can't work! In V3 of the plugin I have added in a network check and just put the plugin into a similar retry loop waiting for the network to become available. It would be good to be able to close the plugin down if say after a user specified amount of time (say 15 minutes) the network is not available.

What's the best way to do this, if indeed it is possible?

The way I decided to handle this type of situation with my Welcome Camera plugin (following last weekend's server debacle) is that after every three unsuccessful poll retries the time between polls is doubled, up to a maximum of one hour. I thought that was a reasonable compromise between cluttering up the Event Log and trying to keep the recovery automatic.

[matt (support)]

Yes, you can use:

Code: Select all

self.stopPlugin("had to stop the plugin because something bad happened!", isError=True)

However, if at all possible I'd encourage you to have the plugin continue to retry indefinitely if the error can be explained by a possible temporary failure (say a network switch is down, WiFi disconnected, etc). Note you can use an internal state and only log the error once to prevent the log from filling up.

For example, if there is a serial port error with the Z-Wave plugin (it is unplugged, etc.), Indigo will log the error once and then silently retry every N seconds to reconnect in the background. It will also disable all of the Z-Wave plugin devices (showing them in error state). Then if the connection is ever restored it it will automatically start working correctly without user action required.

[jay (support)]

I agree with Matt - a plugin should (silently or with very infrequent reports) attempt to reconnect to resources that may become available at a later date. WeatherSnoop, iTunes, Airfoil and many others I've built do this.

After all, you can continue to retry without logging every time.

OK - Thanks for the feedback - I will do silent retries.

[jay (support)]

I think in the Airfoil plugin it will periodically log (like every hour or so). The rachio plugin changes the device state to an error and logs a failure a couple of times then continues silently. Not sure which approach is better really.

Yes, you can use:

Code: Select all

self.stopPlugin("had to stop the plugin because something bad happened!", isError=True)

For the future, (as of version 7.x anyway), self.stopPlugin() can not be called from within __init__ and must be called in or after startup(). For example,

Code: Select all

    def startup(self):

        min_ver = 7
        ver     = self.versStrToTuple(indigo.server.version)
        if ver[0] < min_ver:
            self.stopPlugin(u"This plugin requires Indigo version {0} or above.".format(min_ver), isError=True)


[jay (support)]

For the future, (as of version 7.x anyway), self.stopPlugin() can not be called from within __init__ and must be called in or after startup().

Right - the __init__method doesn't actually "start" the plugin, it only sets up the Plugin object so that Indigo can "run" it.