====== 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.

  * <del>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. <color red>Note</color>: this change will cause any plugin or script that is using the device //''activeZone''// attribute to throw an error.</del> 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_release_notes:1.12|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). <color red>Note</color>: 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 <code>%%d:DEVICEID:stateId%%</code> //''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):

<code>
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
</code>

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