Two observations (Issues?)

[berkinet]

I have noticed two plugin oddities lately and was wondering if theses were issues to be addressed or "normal":

1) When a plugin needs to update multiple device states, as in:

• indigoDevice.updateStateOnServer(key='state1', value='foo')
  indigoDevice.updateStateOnServer(key='state2', value='bar')

The two updates are done sequentially. This has the, apparent, side-effect of causing Indigo to send out two calls to deviceUpdated() for plugins that implement indigo.devices.subscribeToChanges(). In the first update state1 has the new value and state2 its old value, then in the second update both states have their new value.

The problem, at least in the Group-Trigger plugin, is that this requires extra processing to determine which states have changed (compare oldDev to newDev). No big deal, but, it would be nice, for a variety of reasons, to be able to do atomic state updates like:

• indigoDevice.updateStateOnServer(key='state1', value='foo';key=state2, value='bar')

2) In PluginConfig.xml the field id showDebugInfo seems to have at least one magical quality. The defaultValue seems to be locked to false. In the case of the Master-Sprinkler plugin, I wanted to give users a range of logging detail: None, Normal, Verbose & Debug. So, I used a menu. But, since the value for this field id cannot be set, I could not set the default to None, The pulldown always shows --No Selection.

I worked around the issue by changing the field name, and I am not sure it is even a bug... But, was this intended?

[jay (support)]

1) Works as designed. A possible feature request would be to make an updateStatesOnServer() call that accepts a dictionary of state ids to update. However:

The problem, at least in the Group-Trigger plugin, is that this requires extra processing to determine which states have changed (compare oldDev to newDev).

That's going to be the case regardless - if you need to know what changed you're going to have to compare all the fields. Just say'n...

2) There is nothing special about "showDebugInfo" in any dialog. The iTunes plugin (and probably others) use that field as a checkbox that later sets self.debug so that self.debugLog() works properly. But you should be able to use it any way you want just like any other plugin config field. Not sure what you mean by "locked to false".

[berkinet]

1) Works as designed. A possible feature request would be to make an updateStatesOnServer() call that accepts a dictionary of state ids to update. However:

The problem, at least in the Group-Trigger plugin, is that this requires extra processing to determine which states have changed (compare oldDev to newDev).

That's going to be the case regardless - if you need to know what changed you're going to have to compare all the fields. Just say'n...

Ahh, but, If I only care about the new value, and I received one update message with all new values, then I wouldn't have to look at the old values. But, right now for alarm zones when the zone changes to "faul" I get two updates, the first has the old value, "clear" and the second indicates the new value "fault".

2) ...Not sure what you mean by "locked to false".

Try setting the defaultValue of a checkbox with id of "showDebugInfo" to true. It is ignored. Likewise, in this code, the defaultValue is not evaluated:

Code: Select all

	<Field id="
" type="menu" defaultValue="0">
		<Label>Logging level</Label>
		<List>
			<Option value="0">None</Option>
			<Option value="1">Normal</Option>
			<Option value="2">Verbose</Option>
			<Option value="3">Debug</Option>
		</List>
	</Field>

But, if I change showDebugInfo to showDebugInfo1, it works.

[berkinet]

BTW: This:

Code: Select all

	<Field id="showDebugInfo1" type="menu" defaultValue="0">
		<Label>Logging level</Label>
		<List>
			<Option value="0">None</Option>
			<Option value="1">Normal</Option>
			<Option value="2">Verbose</Option>
			<Option value="3">Debug</Option>
		</List>
	</Field>

plus this:

Code: Select all

logLevel = pluginPrefs.get("showDebugInfo1")
		if logLevel == "0":
			self.logLevel = 0
			self.debug = False
		elif logLevel == "1":
			self.logLevel = 1
			self.debug = False
		elif logLevel == "2":
			self.logLevel = 2
			self.debug = False
		elif logLevel == "3":
			self.logLevel = 3
			self.debug = True

lets me do things like this:

Code: Select all

if self.logLevel > 0: indigo.server.log(u"Meta Triggers Plugin Initialized")

[berkinet]

...this requires extra processing to determine which states have changed (compare oldDev to newDev).

That's going to be the case regardless - if you need to know what changed you're going to have to compare all the fields. Just say'n...

Checking to assure that a state change has occurred avoids the original problem, but would create a severe limitation. The plugin would only respond to state changes, not every update. This might be significant if someone wanted to update a timer on each On, say from a motion detector.

[jay (support)]

Try setting the defaultValue of a checkbox with id of "showDebugInfo" to true. It is ignored.

Worked for me. I suspect you have an old value stored in the showDebugInfo field of the plugins properties - so default value isn't evaluated and it's pulling the value from the properties file. Same for your other example. Remember - plugin prefs are stored in:

Code: Select all

/Library/Application Support/Perceptive Automation/Indigo 5/Preferences/Plugins/*

[jay (support)]

Ahh, but, If I only care about the new value, and I received one update message with all new values, then I wouldn't have to look at the old values. But, right now for alarm zones when the zone changes to "faul" I get two updates, the first has the old value, "clear" and the second indicates the new value "fault".

Correct me if I'm wrong: what you're trying to say is that your plugin expects state changes to come in sets - so when one state changes to "faul" then some other state should have changed as well (like the zone that actually faulted or something). In that scenario I can see how it's extra work. Not sure it's an extremely common case, but it would be nice to be able to just send one state update with multiple changes.

If that's not what you meant, then you've totally confused both of us...

[matt (support)]

Checking to assure that a state change has occurred avoids the original problem, but would create a severe limitation. The plugin would only respond to state changes, not every update. This might be significant if someone wanted to update a timer on each On, say from a motion detector.

The devicedUpdated() hook will only be called if the device actually has a change (state or other). Its purpose it to notify the plugin of a change in the device, not to notify the plugin that an incoming command (in your example motion sensor ON) was received.

Calling updateStateOnServer() will never guarantee that your plugin's deviceUpdated() is called -- it will only be called if the device state (or other property) actually changes. In your example, if your plugin needs to know when incoming consecutive ON commands are received (ex: ON -> ON -> ON), then it will have to subscribe to the lower-level X10 / INSTEON hooks to receive those messages. If your plugin just needs to know when a motion sensor transitions from OFF to ON, or ON to OFF, then using the deviceUpdated() hook is sufficient.

[berkinet]

...The devicedUpdated() hook will only be called if the device actually has a change (state or other). Its purpose it to notify the plugin of a change in the device, not to notify the plugin that an incoming command (in your example motion sensor ON) was received.

That is what I thought. But, in practice I get updates for everything. Here are origDev and newDev for an INSTEON switch:

Code: Select all

origDev:
address : 0E.1D.4E
brightness : 100
buttonGroupCount : 1
description : Load Control is defective
deviceTypeId : 
enabled : True
errorState : 
folderId : 1578274891
globalProps : MetaProps : (dict)
id : 1732819158
lastChanged : 2011-12-23 14:38:56
ledStates : []
model : ToggleLinc V2 Dimmer
name : Library Sconces (Link)
onState : True
pluginId : 
pluginProps : com.berkinet.grouptrigger : (dict)
protocol : Insteon
remoteDisplay : True
states : States : (dict)
     brightnessLevel : 100 (integer)
     onOffState : on (on/off bool)
supportsAllLightsOnOff : True
supportsAllOff : True
supportsStatusRequest : True
version : 53

newDev: 
address : 0E.1D.4E
brightness : 100
buttonGroupCount : 1
description : Load Control is defective
deviceTypeId : 
enabled : True
errorState : 
folderId : 1578274891
globalProps : MetaProps : (dict)
id : 1732819158
lastChanged : 2011-12-23 14:38:57
ledStates : []
model : ToggleLinc V2 Dimmer
name : Library Sconces (Link)
onState : True
pluginId : 
pluginProps : com.berkinet.grouptrigger : (dict)
protocol : Insteon
remoteDisplay : True
states : States : (dict)
     brightnessLevel : 100 (integer)
     onOffState : on (on/off bool)
supportsAllLightsOnOff : True
supportsAllOff : True
supportsStatusRequest : True
version : 53

I compared the two using diff and they vary only on the timestamp. To be clear, I am NOT complaining about this behavior, in fact, I like it. But, as I read your post, that behavior is not guaranteed. So, I'll just say, if what I am seeing is a bug, I'd see it as a feature

The problem comes when multiple states are changed at once (well, in quick succession). For each change Indigo sends out an update. If the state I am interested in changes last, I will get 1 or more messages with the old value before the new value arrives. Or, conversely, if the state I want is updated first, I get 1 or more additional messages with that same state.

The problem, was that I want to see multiple unchanged messages from devices, like light switches, but not from other (mostly custom) devices. I have solved the problem by looking to see if the device has a non-null pluginId.


And, to answer Jay's question about changes coming in sets, Yes, that is the (really not big) issue.

[berkinet]

...I suspect you have an old value stored in the showDebugInfo field of the plugins properties - so default value isn't evaluated and it's pulling the value from the properties file.

That was it. all is now well.

[matt (support)]

That is what I thought. But, in practice I get updates for everything. Here are origDev and newDev for an INSTEON switch...

Yeah, apparently it isn't quite optimized yet. Maybe you shouldn't have told us. It shouldn't be bumping the time stamp or calling the hook in that case since no state or property is changing.

The problem comes when multiple states are changed at once (well, in quick succession). For each change Indigo sends out an update. If the state I am interested in changes last, I will get 1 or more messages with the old value before the new value arrives. Or, conversely, if the state I want is updated first, I get 1 or more additional messages with that same state.

Right, that is because there isn't yet a way to atomically update multiple states at once. As Jay mentioned though, this is a good idea so we'll make sure it goes on the request list.