In the release version of v5.0.0 we have a couple of plugin API changes. If your plugin defines either method getDeviceStateList or getDeviceDisplayStateId, then note that the argument list will be changing and your plugin will need to be modified.

The old method signatures were:

Code: Select all

def getDeviceStateList(self, typeId, devId):
    ...

def getDeviceDisplayStateId(self, typeId, devId):
    ...


The new method signature removes the typeId and devId arguments and instead passes a full indigo.Device instance object. This is useful for plugins that want full access to the device's properties to dynamically calculate the state list (or display state ID). For compatibility with the new version you can change your method definition and add the following 2 lines to set the previous argument values.

Code: Select all

def getDeviceStateList(self, dev):
    typeId = dev.deviceTypeId
    devId = dev.id
    ...

def getDeviceDisplayStateId(self, dev):
    typeId = dev.deviceTypeId
    devId = dev.id
    ...


Note that we do our best to not make these types of incompatible API changes, but since Indigo is still in beta and I believe there are only a couple of plugins that might be effected we opted not to try to maintain the old method signature in this case.

I'm creating a plugin for the Elk M1 and I'd like to have each zone included as a state for the device (organizationally it seems neater than having each zone as a separate device). I have defined the getDeviceStatusList in my plugin to dynamically populate the statesList. My device.xml includes only 2 states ("connected" and "alarmStatus"). My method queries the Elk for its active zones and their user defined names. I then take the default states list (generated from the device xml) and then add the states for the zones that the Elk says it has. This allows me to dynamically create the states list (including the actual number of states based on the number of zones reported by the Elk, and defines the [Key] for each of those states to be the user defined name of the zone as reported by the Elk). My method successfully creates a new states list (at least it appears from my debug log to be identical in format to the xml generated list). The difference between the default xml generated states list and my newly created one is that I've dynamically added the states for each zone. getDeviceStatusList then returns this new states list. However, Indigo does not seem to recognize my newly added states. I'm wondering if the actual number of states is fixed by the device.xml, so that when I dynamically add more states Indigo doesn't know to look for them?

Did you delete and recreate the device since you changed it? Device states are only adjustable at create time - in other words, when you create the device the states are created based on the reply from that method and remain fixed for the lifetime of the device. Having truly dynamic states is much more complicated because of all the places where states are used (triggers, conditions, actions, control pages, etc.)

If the zone names are adjustable then I would highly recommend not using the zone name as the state key since states aren't dynamic.

BTW, someone else is already working on an Elk plugin - you might just want to coordinate your efforts.

Thanks for the quick reply!

I'll have to think more about how I want to structure the data. I would really like to be able to use the ability of the Elk to report on which zones are active and their names to automate the setup. But I see the difficulties that introduces.

Thanks for the heads up on the other development on the Elk. Ultimately, I absolutely want to coordinate with anyone else who's interests are common. However, I currently feel like a fish out of water. I'm trying to wrap my brain around all the functionality Indigo offers, as well as how to code in python. At this point, I think I'd be more of a hindrance than a help to someone else who's already up to speed, but I hope to change that in the near future.

Actually a while back I added a new method that a plugin can call to force a refresh of the device state list (and display state ID).

Ah, another one that needs documenting...

I have it documented on my ToDo list of things that need to be documented.