Plugin Error Reporting

I have been thinking about how to log errors for my plugin, and I thought this might be an idea for Indigo.

I would like a way to indicate that a device has an error, but without spamming the log every x minutes. It would be nice to have a window, similar to the log and variables windows, that is a table of persistent errors. A plugin and Indigo could submit an error associated with a device and get an error identifier that it can track. This would allow for the user to see a list of current/unresolved errors. Maybe the devices list could even have an indicator that a device has an unresolved error.

A plugin could then automatically resolve an error (when it has actually be resolved) based on the error identifier and/or the user can manually resolve an error. This might clean up logs since a plugin doesn't need to continually log errors and it reduces the chances of errors going unseen (without spamming the logs).

My initial thought would be that the errors could be displayed similar to how variables are displayed in a list in their own window. If a user doesn't need variables visible at all times then they don't need that window open. But if a device has some indication the there is an error, then a user would know to check the errors window.

I'm not sure just how long the feature request list is, so maybe this can be considered for Indigo 12

Interesting idea overall. Indigo 12 is probably about right.

Maybe the devices list could even have an indicator that a device has an unresolved error.

Are you aware you can set the device to be "in error" so that it goes red in the display UI already?

[url]https://wiki.indigodomo.com/doku.php?id=indigo_7.3_documentation:device_class&s[]=setErrorStateOnServer#device_base_class_instance_methods[/url]
setErrorStateOnServer("Some error") is the call.

It's then up to the developer whether they call self.ErrorLog() (or the new self.logger version thereof!!) to log to the main indigo log, or whether to just log to their private plugin logs.

Interesting idea overall. Indigo 12 is probably about right.

Maybe the devices list could even have an indicator that a device has an unresolved error.

Are you aware you can set the device to be "in error" so that it goes red in the display UI already?

[url]https://wiki.indigodomo.com/doku.php?id=indigo_7.3_documentation:device_class&s[]=setErrorStateOnServer#device_base_class_instance_methods[/url]
setErrorStateOnServer("Some error") is the call.

It's then up to the developer whether they call self.ErrorLog() (or the new self.logger version thereof!!) to log to the main indigo log, or whether to just log to their private plugin logs.

Thanks for the link, I was not aware that was an option!

[jay (support)]

There are two types of "errors" that most plugins need to deal with: runtime events (stream of consciousness, what the Event Log and the self.logger logging are designed for) and persistent errors that are tied directly to a device (mostly) such that user intervention is (or might be) necessary (which is what setErrorStateOnServer() is used for). The two are somewhat intertwined, but keeping the concepts discrete is probably the best way to think about it. The latter could undoubtedly use some additional work as it's relatively lightweight.

Some ways that other plugins handle persistent issues is to throttle the error reports written to the Event Log. Depending on the urgency, you can report relatively frequently for a short period of time, particularly if it's a problem that could resolve itself (network outages for instance). Then, throttle back the reporting while the problem persists. For instance, when the reflector can't connect to our hosts, it reports frequently a couple of times, then it throttles back reporting to once every 15 minutes.

We appreciate the feedback on ways to improve the persistent error reporting as we're always looking for ways to make it better.