better manageability: status checks and status reports

the basic indigo app device view provides some useful stuff including basic controls: on/off, brightness (if applicable), etc.. ) and some basic status info including "last update". some devices provide "send status update" button, which is great and super useful when it is provided.

indigo for me serves as the "glue" or controlling logic from a complex set of connecting parts and pieces - hardware and software. as such, managing and maintaining it largely demands being able to tell when these parts are "up" and connected vs. when they are not. here are a few enhancements i'd like to see in this regard:

more consistent "send status request" support for z-wave devices. works well for always-awake insteon devices. it exists for some of my always-awake z-wave devices, but not all of them.

support "send status request" or "ping" across more (plugin) devices. i suggest it would be great if the indigo plugin API fostered some consistency here both for devices like "hubs" as well as for the actual downstream devices, when possible. example of plugins i use that would benefit hugely from this: hue, lutron, harmony, sonos, roomba, .... if a hub drops offline due to network issue, tripped circuit breaker, accidentally getting uplugged, etc. i want to be able to detect this and easily distinguish it from a case where a particular downstream switch/device is not working.

display result of "send status request" directly in the core Indigo interface. so i can hit "send status request" and see if a device is responding w/o having to bring up the log window. suggestion: turn the "last update" field green/red after an active status request to indicate success/failure respectively - that way, i have one field i can look at to get the best available info on whether or not a device is "alive", whether or not it supports active status requests (e.g. for battery-powered sensors). it would be great if there were something like a "last-comm-attempt-failed" field or similar for devices, better still if it were a full-fledged field that could be shown/sorted in list view.

better support of "last update". . i suggest that any time Indigo has communicated with a device, that this field be updated. i have z-wave devices, for example. that show "last update" date of >4yrs ago (presumably when device was first added to Indigo). no "send status request" button is provided, but i can force communication by hitting "define and sync" which succeeds (based on logs) yet "last update" field still shows the same (old) date. the net result is that i can't trust "last update" to be able to quickly show me devices that have lost communication with indigo, died, or whatever.

discourage bogus default values of "last update". i realize there inevitably will be some plugins that don't properly support "last update" field in useful way. i propose that in those cases, use of bogus values be discouraged and perhaps that the default value for the field should be "empty" instead of some bogus date. currently, for example, i have many devices (including z-wave) where last update is 2000-01-01 00:00:00. for some of these (e.g. the z-wave devices) i can force updates that will correct the problem (though i shouldn't have to). for the others, looks like i'm stuck looking at those bogus values in perpetuity.

[jay (support)]

Thanks for the feedback.

1) Can you tell us which exact Z-Wave devices aren't doing status requests correctly? It's a standard Z-Wave feature so I'm surprised it doesn't work.
2) Plugins can implement status requests already. Contact the developer of the plugin to recommend that addition.
3) Given the diverse ways that status requests are replied to it's often not clear when a status request is replied to: it can look like a standard status update so we can't tell the difference between a response for status and a status update broadcast.
4) Again, can you send us the specific Z-Wave devices that don't show an update? Usually when you see that it means that the device never actually reports anything back to Indigo. This happens when it's a control-only device that doesn't actually maintain state.
5) We'll look into this, but TBH it's not really a high priority given that a the date you specify can be interpreted as nothing.