Devices

In the IOM, all devices are derived from a common Device base class. This base class provides for all the common properties of a device (including devices defined by Server plugins) and each subclass also inherits all the commands in the device command namespace (indigo.device.*) - there are a few exceptions that will be noted below. Check out the examples for each section to see how you use each device type.

Like other high-level objects in Indigo, there are rules for modifying devices. For Scripters and Plugin Developers:

• To create, duplicate, delete, and send commands to a device, use the appropriate command namespace as defined below
• To modify an device's definition get a copy of the device, make the necessary changes, then call myDevice.replaceOnServer()

For Plugin Developers:

• To update a plugin's props on a device on the server, call myDevice.replacePluginPropsOnServer(newPropsDict) rather than try to update them on the local device
• To change a device's state on the server, use myDevice.updateStateOnServer(key='keyName', value='Value')
• To change multiple device states on the server at one time, use myDevice.updateStatesOnServer(update_list) passing a dictionary that looks like this:

  # New code equivalent that is much more efficient:
  key_value_list = [
      {'key':'someKey1', 'value':True},
      {'key':'someKey2', 'value':456},
      {'key':'someKey3', 'value':789.123, 'uiValue':"789.12 lbs", 'decimalPlaces':2}
  ]
  dev.updateStatesOnServer(key_value_list)

Note: all API descriptions apply to all API versions unless otherwise specified.

The Device class is generally used as a base class - your script will use objects that are instances of one of it’s subclasses - we'll discuss each of the subclasses later in this section. First, a quick refresher on a fundamental aspect of devices: some devices can only be controlled (i.e. old-style ApplianceLincs, most X10 devices, etc.), called responders in Indigo terminology, other devices are only controllers (i.e. RemoteLincs, PalmPads, etc.), and some devices are both responders and controllers (i.e. KeypadLincs).

This terminology was really invented for INSTEON devices, but we think it applies to other technologies as well but perhaps in a slightly different way. In any event, controller devices can support a number of buttons and/or a number of groups from which commands are sent, all of which Indigo can use to trigger actions. From a technical and practical standpoint, they are in fact the same thing so a single number, indexed based on how the device supports them, is how this property should be used.

The base class supports getting the number of buttons or groups as a single property (buttonGroupCount) for the device. Use that count as a guide to what you can pass in the various trigger classes. For any device that doesn’t support local physical buttons or sending group commands and/or status commands, the number returned should be 0.

If you’re writing a plugin that defines devices, they will automatically inherit all of the following properties.

API v1.18+ only:

The following image selectors are available but do not yet have function-specific icons in Indigo Touch and Indigo client UI. Developers are encourage to use them for automatic future compatibility when the icons are added.

The following instance methods can be called on device objects. Most are restricted and can only be called from a plugin on a device that the plugin owns. See the Restricted column below for those that are restricted in this way.

Devices have properties - some are class properties, defined by the class itself. One of the biggest requests we've gotten in the past is some way to add arbitrary properties to a device - so that you could store your own data with the device in the database. And with plugin defined devices, we needed a place to store the properties that you need to operate the device. That's what the pluginProps and globalProps represent - the additional properties that are not defined by the class. globalProps is a dictionary of every additional property defined for the device - each plugin has it's own dictionary of props in here which are readable by anyone. pluginProps is a shortcut to get to your plugin's props and are only writable by your plugin once the plugin has been created - a script can create a device supplied by your plugin along with the necessary properties, which are passed in on the create() method. You should publish the properties necessary to make your device work so that scripters can create your devices.

We mentioned before that devices were read-only, and that's true, and that you'd need to use commands in a different command name space. That's mostly true. Here's one exception to that rule: to change a device's pluginProps (it must be “owned” by your plugin - that is, the pluginId must be set to your id), you use a method that's in the device's class: replacePluginPropsOnServer(). Here's an example:

dev=indigo.devices[123]
localPropsCopy = dev.pluginProps
localPropsCopy['pollInterval'] = 10
dev.replacePluginPropsOnServer(localPropsCopy)

You would use this technique if you wanted to just change some of the properties that are already defined. Because this method replaces ALL of the properties for your plugin in the device, you can just set them all in one call:

dev=indigo.devices[123]
dev.replacePluginPropsOnServer({'pollInterval':10,'checkForUpdates':True})

Note, though, that if you have a <ConfigUI> defined for the device, those properties are also stored here - so in order to make sure your device works correctly you must include those properties as well. If you need to update several properties in your props dict, you can use the update() method:

dev=indigo.devices[123]
localPropsCopy = dev.pluginProps
localPropsCopy.update({'pollInterval':10, 'checkForUpdates':True})
dev.replacePluginPropsOnServer(localPropsCopy)

The update() method will change the properties specified, and add the property if it doesn't exist. Now, you might be wondering - why do the extra localPropsCopy = dev.pluginProps rather than just modify the props in place:

dev=indigo.devices[123]
dev.pluginProps.update({'pollInterval':10, 'checkForUpdates':True})
dev.replacePluginPropsOnServer(dev.pluginProps)

Because the dev object is read-only - when you reference dev.pluginProps, it returns a copy rather than returning a reference to the read-only object. So, in effect, you'd be modifying a copy. But, because you aren't saving a reference to that copy, it goes away since the next time you reference dev.pluginProps another copy is made.

If you need to just dump all the properties for a device, you can just:

dev=indigo.devices[123]
dev.replacePluginPropsOnServer(None)

That will completely remove your properties from the device.

If you are a Developer and your plugin defines custom devices, then those devices will also need to define a collection of states. For instance, let's look at the states defined in a custom device's Devices.xml:

<States>
    <State id="playStatus">
        <ValueType>
            <List>
                <Option value="playing">Playing</Option>
                <Option value="paused">Paused</Option>
                <Option value="stopped">Stopped</Option>
                <Option value="unavailable">Unavailable</Option>
            </List>
        </ValueType>
        <TriggerLabel>Player Status Changed</TriggerLabel>
        <TriggerLabelPrefix>Player Status is</TriggerLabelPrefix>
        <ControlPageLabel>Current Player Status</ControlPageLabel>
        <ControlPageLabelPrefix>Player Status is</ControlPageLabelPrefix>
    </State>
    <State id="sep1">
        <ValueType>Separator</ValueType>
    </State>
    <State id="playlist">
        <ValueType>String</ValueType>
        <TriggerLabel>Current Playlist Name</TriggerLabel>
        <ControlPageLabel>Current Playlist Name</ControlPageLabel>
    </State>
    <State id="album">
        <ValueType>String</ValueType>
        <TriggerLabel>Current Album</TriggerLabel>
        <ControlPageLabel>Current Album</ControlPageLabel>
    </State>
    <State id="artist">
        <ValueType>String</ValueType>
        <TriggerLabel>Current Artist</TriggerLabel>
        <ControlPageLabel>Current Artist</ControlPageLabel>
    </State>
    <State id="track">
        <ValueType>String</ValueType>
        <TriggerLabel>Current Track</TriggerLabel>
        <ControlPageLabel>Current Track</ControlPageLabel>
    </State>
    <State id="volume">
        <ValueType>Integer</ValueType>
        <TriggerLabel>Current Volume</TriggerLabel>
        <ControlPageLabel>Current Volume</ControlPageLabel>
    </State>
    <State id="shuffle">
        <ValueType boolType="YesNo">Boolean</ValueType>
        <TriggerLabel>Shuffling</TriggerLabel>
        <ControlPageLabel>Shuffling</ControlPageLabel>
    </State>
</States>
<UiDisplayStateId>playStatus</UiDisplayStateId>

You'll recall from the Custom Device Type section of the developers guide, these define the states that are used in various places in the UI and by other objects (triggers, control pages, etc). So, the question is now that the server understands the structure of your devices' states, how do you change them?

It's actually pretty simple. When your plugin detects a change in one of the states, you just call the updateStateOnServer('id', value='value') method. Here are some examples for setting the state based on the above state definitions:

# assume that someMusicServer represents a device with the above states
# to update the volume state
someMusicServer.updateStateOnServer('volume', value=50)

# to update the track name
someMusicServer.updateStateOnServer('track', value='Cluster One')

# to update the album name
someMusicServer.updateStateOnServer('album', value='The Division Bell')

# to update the artist name
someMusicServer.updateStateOnServer('artist', value='Pink Floyd')

# to update the playStatus
someMusicServer.updateStateOnServer('playStatus', value='playing')

# to update the playStatus
someMusicServer.updateStateOnServer('shuffle', value=True)

Note - for states that have a <ValueType> of Number, you pass an integer or float; for states that are Boolean, you pass Python True or False; all others pass a string.

It's just that simple. This will cause any triggers on the server that are set on your device's states to be fired. It will update any visible control pages. It will show the state that's defined in the <UiDisplayStateId> element in the Mac device table's State column.

The updateStateOnServer method has 3 optional parameters: decimalPlaces (integer), triggerEvents (boolean), and uiValue (string, API v1.6+ only).

When updating floating point state values use the decimalPlaces parameter to specify the number of fractional digits to store and display. For example:

someThermmostateDevice.updateStateOnServer('mainTemp' value=76.1234, decimalPlaces=2)

instructs the Indigo Server to store and display the value as 76.12.

The triggerEvents parameter can be set to False (defaults to True) to have the Indigo Server update the state but ignore any Device State Changed triggers that should be processed as a result of the state change.

And the optional uiValue parameter is used to set UI only display string of the value which is not used in triggers or conditional logic. This is useful for adding units, percent signs, etc:

dev.updateStateOnServer('sensorValue', 72.3, uiValue=u'72.3 °F')

Turns off all devices for all protocols unless a direct parameter is specified. The direct parameter, if specified, will determine which devices will be turned off. In the context of this command, devices are defined as all dimmable (light) and relay (appliance) devices and does not include other device types that may have an on/off state. This command doesn’t work for plugin defined devices regardless of type.

indigo.device.allOff()

indigo.device.allOff(indigo.kAllDeviceSel.HouseCodeA)

indigo.device.allOff(indigo.kAllDeviceSel.Insteon)

API v1.11+ only: Requests that the device make an audible beep or buzz. Only supported by some hardware.

indigo.device.beep(123)

Create a device. You can create devices that are defined by your plugin, in other plugins, and X10 devices ( you can't currently add INSTEON devices because they need to perform some action to actually make the device function). You use this method to create ALL device types - it will return a device of the correct class to you based on the arguments. It can be considered the “device” factory method.

This method returns a copy of the newly created device.

indigo.device.create(protocol=indigo.kProtocol.Plugin,
    address='F8',
    name='Device Name Here', 
    description='Description Here', 
    pluginId='com.mycompany.pluginId',
    deviceTypeId='myDeviceTypeId',
    props={'propA':'value', 'propB':'value'},
    folder=1234)

Parameters
Parameter	Required	Type	Description
address	No	string	the address of the X10 device - plugins must set an address property in their property dictionary
description	No	string	the description of the device
deviceTypeId	Yes	string	the id of the device type – defined by the plugin or one of the defined X10 devices link here
name	Yes	string	the name of the device
pluginId	No	string	the plugin ID - defaults to your plugin's id if in a Server Plugin
props	No	dictionary	this is the properties for the device - they will be inserted in to the pluginId's property space as supplied above. If you are creating a device of a type defined in a different plugin, it's that plugin's id and properties.
protocol	Yes	kProtocol	the protocol for the device (indigo.kProtocol.Plugin or indigo.kProtocol.X10)
folder	No	integer	id or instance of the folder in which to put the newly created device

Delete the specified device regardless of it’s type.

indigo.device.delete(123)

Duplicate the specified device regardless of the type. This method returns a copy of the new device.

indigo.device.duplicate(123, duplicateName='New Name')

Enable/Disable the specified device regardless of the type.

indigo.device.enable(123, value=True) #enable
indigo.device.enable(123, value=False) #disable

API v1.14+ only: Return an indigo.List with all device IDs in a device group.

groupList = indigo.device.getGroupList(123)

getGroupList() is useful to get the main/root device of a device group. Some properties, such as batteryLevel, only exist on the main/root device. In this example we log the batteryLevel for a module given any devices that belong to its group:

groupList = indigo.device.getGroupList(devIdOrInstance)
rootDevice = indigo.devices[groupList[0]]
indigo.server.log('battery level is: ' + str(rootDevice.batteryLevel))

Return an indigo.Dict with all the dependencies on this device.

depDict = indigo.device.getDependencies(123)

The dictionary will look something like this:

>>> print indigo.device.getDependencies(91776575)
Data : (dict)
     actionGroups : (list)
          Data : (dict)
               ID : 1280166770 (integer)
               Name : Set var to device state (string)
     controlPages : (list)
     devices : (list)
     schedules : (list)
     triggers : (list)
          Data : (dict)
               ID : 106487666 (integer)
               Name : Thermostat condition test (string)
     variables : (list)

So, the dictionary will have 5 top-level keys: “actionGroups”, “controlPages”, “devices”, “schedules”, “triggers”, and “variables”. Each one of those keys will return a list object. Inside that list object will be multiple dicts, one for each dependency (or an empty list if there are none). Each dependency dictionary has two keys: “ID” which is the unique id and “Name” which is the name of the object.

Use this command to move the device to a different folder.

indigo.device.moveToFolder(123, value=987)

API v1.16+ only: Sends the Z-Wave or INSTEON module a ping command and measures the round trip ACK time. Returns a dict containing the Success and TimeDelta (milliseconds) result.

result = indigo.device.ping(123, suppressLogging=True)
if result["Success"]:
    indigo.server.log("%.3f seconds ping for %s" % (result["TimeDelta"]/1000.0, dev.name))
else:
    indigo.server.log("ping failed for %s" % (dev.name), isError=True)

This command will remove delayed actions for the specified device.

indigo.device.removeDelayedActions(123)

API v1.11+ only: Resets the energyAccumTotal and energyAccumTimeDelta values and changes the energyAccumBaseTime to the server's current datetime.

indigo.device.resetEnergyAccumTotal(123)

Use this command to set the remote display flag for the folder.

indigo.device.displayInRemoteUI(123, value=True)

This tells IndigoServer to send a status request command to the specified device and refresh it’s status.

indigo.device.statusRequest(123)

indigo.device.statusRequest(123, suppressLogging=True)

This tells IndigoServer to toggle a device from on to off or vice versa depending on it’s current state. This command only works for device types that can be turned on and off.

indigo.device.toggle(123)

indigo.device.toggle(123, delay=10, duration=300)

This tells IndigoServer to turn off a device. This command only works for device types that can be turned on and off.

indigo.device.turnOff(123)

indigo.device.turnOff(123, delay=10, duration=300)

This tells IndigoServer to turn on a device. This command only works for device types that can be turned on and off.

indigo.device.turnOn(123)

indigo.device.turnOn(123, delay=10, duration=300)

API v2.0+ only: This tells IndigoServer to unlock a device. This command only works for relay device types that have pluginProps[“IsLockSubType”] set to True.

indigo.device.unlock(123)

indigo.device.unlockOff(123, delay=10, duration=300)

API v2.0+ only: This tells IndigoServer to lock a device. This command only works for relay device types that have the property pluginProps[“IsLockSubType”] set to True.

indigo.device.lock(123)

indigo.device.lock(123, delay=10, duration=300)

# Creating a device
myDevice = indigo.device.create(protocol=indigo.kProtocol.X10,
    name="Office Lamp",
    description="X10 Lamp module",
    address="F7",
    deviceTypeId="LampLinc Plus Plug-In Dimmer")

# Getting a device
myDevice = indigo.devices[123]

|

-- Getting a device
set myDevice to device "Office Lamp"

# Logging a message if it’s an X10 device
if (myDevice.protocol == indigo.kProtocol.X10):
    indigo.server.log("device is an X10 device")   

# Logging a message if it’s showing in Indigo Touch
if (myDevice.remoteDisplay):
    indigo.server.log("device is showing in Indigo Touch")

# Setting the folder ID that the device is in
indigo.device.setFolder(myDevice, 987)

# Turning off all devices (dimmer and relay)
indigo.device.allOff()

# Turning off all devices in X10 house code A
indigo.device.allOff(indigo.kAllDeviceSel.HouseCodeA)

# Turning off all INSTEON devices
indigo.device.allOff(indigo.kAllDeviceSel.Insteon)

|

-- Turning off all devices (dimmer and relay)
all off

|

Dimmer devices are dimmable light modules. They can be turned on and off and their brightness may be set. Your script may manipulate any dimmer device. You may specify that devices defined by your plugin are of this type. The standard dimmer UI in the various clients will be presented to users attempting to control your device.

These are the states provided by this device type and accessible through the dev.states dictionary. They are read-only, but if you're a plugin developer you can use the updateStateOnServer() class method to update the value for devices owned by your plugin.

Turns off all lights for all protocols unless a direct parameter is specified. The direct parameter, if specified, will determine which lights will be turned off. Lights are defined as all dimmable devices. This command doesn’t work for plugin defined devices regardless of type.

indigo.dimmer.allLightsOff()

indigo.dimmer.allLightsOff(indigo.kAllDeviceSel.HouseCodeA)

indigo.dimmer.allLightsOff(indigo.kAllDeviceSel.Insteon)

Turns on all lights for all protocols unless a direct parameter is specified. The direct parameter, if specified, will determine which lights will be turned on. Lights are defined as all dimmable devices. This command doesn’t work for plugin defined devices regardless of type.

indigo.dimmer.allLightsOn()

indigo.dimmer.allLightsOn(indigo.kAllDeviceSel.HouseCodeA)

indigo.dimmer.allLightsOn(indigo.kAllDeviceSel.Insteon)

Changes the brightness of the specified light relative to the current brightness.

indigo.dimmer.brighten('Office Lamp')

indigo.dimmer.brighten(123)

indigo.dimmer.brighten('Office Lamp', by=50, delay=4)

Dim the brightness of the specified light by some amount relative to the current brightness.

indigo.dimmer.dim('Office Lamp')

indigo.dimmer.dim(123)

indigo.dimmer.dim('Office Lamp', by=50, delay=4)

Changes the brightness of the specified light to a specific value.

indigo.dimmer.setBrightness(123, value=75)

indigo.dimmer.setBrightness(123, value=75, delay=360)

Turns on/off the specified LED. Useful for KeypadLinc (and similar) devices. Note: you can't use this method to control the LED of the button(s) that control the direct load - use Turn ON/Turn OFF for those.

indigo.dimmer.setLedState(123, index=0, value=True)

indigo.dimmer.setLedState(123, index=0, value=True, suppressLogging=True)

indigo.dimmer.setLedState(123, index=0, value=True, updateStatesOnly=True)

Use the Turn On, Turn Off, and Toggle methods to turn on/off a dimmer device.

Here are examples of device properties:

# Getting a device
myDevice = indigo.devices[123]

# Set a device’s brightness to 75 if it’s currently
# less than that, but only if it’s turned on
myDevice = indigo.devices[123]
if ((myDevice.brightness < 75) and 
    (myDevice.onState)):
	indigo.dimmer.setBrightness(myDevice, 75)

# Brighten a light by 25% after 10 minutes
indigo.dimmer.brighten(123, by=25, delay=600)

# Logging a message if it’s showing in Indigo Touch
myDevice = indigo.devices[123] 
if (myDevice.remoteDisplay):
	indigo.server.log("device is showing in Indigo Touch")

# Getting the folder ID that the device is in
myDevice = indigo.devices[123]
myDevice.folderId
# OR
indigo.devices[123].folderId # see comments below

You might look at the second example above, and wonder why we didn’t do something like this:

# Set a device’s brightness to 75 if it’s currently
# less than that, but only if it’s turned on
myDevice = indigo.devices[123] 
if ((indigo.devices[123].brightness < 75) and 
    (indigo.devices[123].onState)):
	indigo.dimmer.setBrightness(indigo.devices[123], 75)

That code works correctly, but is very inefficient. The Python to C++ bridge will cause a copy of the object to be made every time indigo.devices[123] is used since the devices list is a C++ object, but the object returned from it using the id subscript is bridged to a Python object, and all bridged objects are copies. So, the code directly above will create 3 copies of the device object - very inefficient. The code in the example above gets a single copy of the object and uses that in all the rest of the code. A good rule of thumb is to get an explicit copy of an object if you need to use it more than once.

I/O devices have a wide variety of capabilities that we’ve tried to boil down to some specifics. The I/O devices that Indigo supports generally have some combination of three types of inputs: analog, binary, and sensor. They may also support some number of binary outputs.

All outputs are modified using commands below.

These are the states provided by this device type and accessible through the dev.states dictionary. They are read-only.

Set the state of the specified binary output.

indigo.iodevice.setBinaryOutput(123, index=2, value=True)

Some sensor devices, like motion sensors, are treated differently in Indigo. They don’t generally maintain state - so there’s no concept of a sensor being on/off: in the case of a motion sensor, detecting motion and not detecting motion.

They generally send a command of some type when they detect some condition and send another command when they stop detecting it. However, dealing with them in Indigo as if they maintain state is much more useful in many cases. So, Indigo will attempt to maintain a virtual state for each motion sensor if configured that way. Currently, the following devices fall under this category:

• X10 Motion Sensors
• the Wireless INSTEON Motion / Occupancy Sensor (2420M) from SmartLabs
• the TriggerLinc from SmartLabs
• the SynchroLinc from SmartLabs

Set the sensor onState property. Normally this is unnecessary since Indigo will maintain it for you so this method is provided mainly for testing and error recovery.

indigo.sensor.setOnState(123, value=True)

– none –

Relay devices are very simple devices, often times called appliance modules. They can be turned on and off only. Your script may manipulate any relay device. Your plugin may specify devices that are of this type and the standard relay UI in the various clients will be presented to users when controlling it.

These are the states provided by this device type and accessible through the dev.states dictionary. They are read-only, but if you're a plugin developer you can use the updateStateOnServer() class method to update the value for devices owned by your plugin.

Use the Turn On, Turn Off, and Toggle methods in the indigo.device.* namespace to turn on/off a relay device.

Turns on/off the specified LED. Useful for KeypadLinc (and similar) devices. Note: you can't use this method to control the LED of the button(s) that control the direct load - use Turn ON/Turn OFF for those.

indigo.relay.setLedState(123, index=0, value=True)

indigo.relay.setLedState(123, index=0, value=True, suppressLogging=True)

indigo.relay.setLedState(123, index=0, value=True, updateStatesOnly=True)

# Toggle the device
indigo.device.toggle(123)

Speed control devices are generally controllers for motors of some type. The first implementation was for the INSTEON FanLinc, which is a ceiling fan motor controller. This device type provides two different methods of setting the speed of the motor: by level, which ranges from 0 (off) to 100 (full on), and by index. With a device like a FanLinc, for instance, you can't set an arbitrary speed - you can only set it to some number of fixed speeds and this is what index is for. The FanLinc will in fact respond to setting the level, but we normalize the level to the appropriate speed. Other speed control devices may not choose to do so.

These are the states provided by this device type and accessible through the dev.states dictionary. They are read-only, but if you're a plugin developer you can use the updateStateOnServer() class method to update the value for devices owned by your plugin.

Decreases the speed index.

indigo.speedcontrol.decreaseSpeedIndex(123)

indigo.speedcontrol.decreaseSpeedIndex(123, by=2)

indigo.speedcontrol.decreaseSpeedIndex(123, delay=10)

Increases the speed index.

indigo.speedcontrol.increaseSpeedIndex(123)

indigo.speedcontrol.increaseSpeedIndex(123, by=2)

indigo.speedcontrol.increaseSpeedIndex(123, delay=10)

Sets the speed index to the specified value.

indigo.speedcontrol.setSpeedIndex(123, value=2)

indigo.speedcontrol.increaseSpeedIndex(123, value=2, delay=10)

Sets the speed index to the specified value.

indigo.speedcontrol.setSpeedLevel(123, value=50)

indigo.speedcontrol.setSpeedLevel(123, value=75, delay=10)

Sprinkler devices generally have some number of sprinkler zones.

These are the states provided by this device type and accessible through the dev.states dictionary. They are read-only.

Set the sprinkler to the next zone, and turn off if it’s the last defined zone.

indigo.sprinkler.nextZone(123)

Pause the current sprinkler schedule but keep it active so it can be resumed.

indigo.sprinkler.pause(123)

Set the sprinkler to the previous zone, and turn off if it’s the first defined zone.

indigo.sprinkler.previousZone(123)

Resume the current sprinkler schedule.

indigo.sprinkler.resume(123)

Run a sprinkler schedule.

indigo.sprinkler.run(123, schedule=[10,15,8, 0, 0, 0, 0, 0])

Stop the current sprinkler schedule and clear it.

indigo.sprinkler.stop(123)

API v1.12+ only: Turn on a specific zone.

indigo.sprinkler.setActiveZone(123, index=2)

# run schedule
indigo.sprinkler.run(123, 
    schedule=[10,15,8, 0, 0, 0, 0, 0])

Thermostats have a wide variety of capabilities that we’ve tried to boil down to some specifics. They can have multiple temperature and humidity sensors, they generally have a fan mode, an HVAC mode (heating, cooling, etc) and associated setpoints. Note: some thermostats don’t support getting the equipment state values: coolIsOn, fanIsOn, heatIsOn, dehumidifierIsOn, and humidifierIsOn. For those thermostats those properties will always be False.

These are the states provided by this device type and accessible through the dev.states dictionary. They are read-only, but if you're a plugin developer you can use the updateStateOnServer() class method to update most of these states for devices owned by your plugin (exceptions are noted below).

Decrease the cool setpoint by a delta value.

indigo.thermostat.decreaseCoolSetpoint(123, delta=5)

Decrease the heat setpoint by a delta value.

indigo.thermostat.decreaseHeatSetpoint(123, delta=5)

Increase the cool setpoint by a delta value.

indigo.thermostat.increaseCoolSetpoint(123, delta=5)

Increase the heat setpoint by a delta value.

indigo.thermostat.increaseHeatSetpoint(123, delta=5)

Set the cool setpoint to an absolute temperature.

indigo.thermostat.setCoolSetpoint(123, value=78)

Adjust the fan mode.

indigo.thermostat.setFanMode(123, value=indigo.kFanMode.AlwaysOn)

Set the heat setpoint to an absolute temperature.

indigo.thermostat.setHeatSetpoint(123, value=78)

Adjust the HVAC mode.

indigo.thermostat.setHvacMode(123, value=indigo.kHvacMode.HeatCool)

# increase the cool setpoint by 5 degrees
indigo.thermostat.decreaseCoolSetpoint(123, delta=5)


# set the thermostat mode to auto
indigo.thermostat.setHvacMode(123, 
    value=indigo.kHvacMode.HeatCool)

# set the heat setpoint to 78
indigo.thermostat.setHeatSetpoint(123, value=78)