API v1.11 Release Notes

This version of the API shipped with Indigo 6 beta 12 - check the API Version Chart to see what version of the API is available in which Indigo versions.

Changed the name of the sprinkler device attribute activeZone to activeZoneIndex to more correctly reflect what it is. The activeZone state is actually a 1-based index into your zone list (1 represents zone 1, 2 represents zone 2 - 0 represents no zone running). However, because there are three sprinkler device properties (zoneNames, zoneMaxDurations, and zoneScheduledDurations) that are 0-based Python arrays, we thought it would be more convenient to use the activeZoneIndex directly (dev.zoneName[dev.activeZoneIndex]). However, we needed to distinguish the activeZone state from the activeZoneIndex attribute to reduce confusion. Note: this change will cause any plugin or script that is using the device activeZone attribute to throw an error. IMPORTANT: Upon further completion of the sprinkler device object model and related actions it has become apparent that using both 0 and 1 based indices for sprinkler zones is quite confusing and unwieldy. Therefore, starting in API v.1.12 (Indigo 6.0.3) the activeZoneIndex attribute has been removed and activeZone restored. All sprinkler zone indices in attributes, states, and properties will be 1 based: zone 1 will be index 1, zone 2 will be index 2, and using an index value of 0 will represent all zones off.
Removed energy meter attributes (energyInputCount, energyInputs, accumEnergyTotals, accumEnergyBaseTimes, accumEnergyTimeDeltas) from the sensor device object, and the resetAccumEnergyTotals() method from the indigo.sensor commmand space. They no longer exist at the sensor device level, so scripts and plugins should call the newer methods on the base device object instead (see next item). Note: this change will cause any plugin or script that is using the attributes or method to throw an error.
Added energy meter attributes (energyCurLevel, energyAccumTotal, energyAccumBaseTime, energyAccumTimeDelta) to the base device object, and the reset method resetEnergyAccumTotal() to the indigo.device command space.
Added actionControlGeneral action callback, GeneralDeviceAction action class and indigo.kDeviceGeneralAction enumeration for handling generic device actions such as status requests, energy meter reading, energy usage resetting, beep request, etc. If the plugin does not define the actionControlGeneral callback, then device status request actions will continue to be dispatched to the device specific callbacks: actionControlDimmerRelay, actionControlSensor, actionControlSpeedControl, actionControlThermostat, actionControlIO, actionControlSprinkler.
Renamed indigo.kDeviceAction enumeration to indigo.kDimmerRelayAction. The previous enumeration still exists for backwards compatibility but should no longer be used.
Added the self.substituteDeviceState(inString, validateOnly=False) method to the plugin base class. It works basically like substituteVariable() except it substitutes the value of the specified device state. The markup is
```
%%d:DEVICEID:stateId%%
```
validateOnly is optional and False by default. If validateOnly is true it returns a tuple (also like the variable substitution) where the first element is a boolean representing whether it validates and if not it has a second element that's the error message.
Added the self.substitute(inString, validateOnly=True) method to the plugin base class. It first calls self.substituteVariable() and then calls self.substituteDeviceState() with the appropriate parameters (all three methods have exactly the same parameters with the same purpose). It also returns exactly the same format of values as these two methods depending on whether validateOnly is True or False. The ordering was carefully chosen such that the variable substitution could, in fact, add more device markup before the device substitution happens. So the user can even more dynamically generate content by inserting device markup into a variable value. However, only device markup will be honored in variable values - we don't recursively call variable markup on variable values.
Custom plugin devices will now have status icons selected for them based on the value of the status state (mostly string compares, but will also select if it's a boolean). Here is the logic in order (all comparisons are case insensitive, first match wins):

if status string is equal to "playing" show the play icon
if status string is equal to "paused" show the pause icon 
if status string is equal to "stopped" show the stop icon
if status string is equal to "on" show the device on icon
if status string is equal to "off" show the device off icon
if status string contains one of ["inactive", "disabled", "closed", "disconnected", "unavailable"] or if the state value is a boolean and false show a gray dot
if status string contains one of ["active", "enabled", "open", "connected", "available"] or if the state value is a boolean and true show a green dot
if status string contains "delay" show the timer on icon
if status string contains "tripped" or "faulted" show a red dot

If you indicate an error for your device it will get a red dot