One-stop linking a KeypadLinc button to a plugin device

[jay (support)]

Correct - you won't see any change because there wasn't one. You can, of course, subscribe to incoming INSTEON commands and watch for button presses that way. It's not documented well but there's a very simple Example INSTEON/X10 Listener plugin in the SDK that illustrates it's use. The cmd parameter to the insteonCommandReceived method illustrated in the example is a dict:

Code: Select all

ackValue : 0
address : 22.F7.44
cmdBytes : [17, 0]
cmdFunc : on
cmdScene : 3
cmdSuccess : True
cmdValue : 0
replyBytes : []

cmdScene is the button #.

[kw123]

I did the interface ... change, seems to work: device sends only one "off" messages and no message to the device to set it back to "off" is needed.
One side effect is that every time a button gets press it blinks 3 times - for about 2 seconds- then goes to off status. .. is this a "feature"?
Not a big deal, but is this the way it should be?

thx

Karl

[jay (support)]

Yep - that's feedback to let you know you pressed the button.

[hamw]

Would a general solution include "One" of the Holy Grails of home automation: multiple events/single trigger?

[Perry The Cynic]

You can, of course, subscribe to incoming INSTEON commands and watch for button presses that way.

Well, I've got that more-or-less working. Questions:

Do I need to worry about cmdSuccess in incoming INSTEON commands being False, and if so, what am I supposed to do about it - ignore it? Yell at the user?

Is there something problematic about calling indigo.server.turnOn from inside an insteonCommandReceived handler? When I do, I get frequent "send failed (no acknowledgment)" errors. Adding a one-second delay solves the problem, but of course isn't nice for responsiveness. (And it really needs to be almost a full second; delaying by 0.3 seconds doesn't seem good enough.)

Is there any way my plugin can find out that a turnOn/turnOff command has failed, so it can retry it? (Short of issuing a state query, at least, or filtering the event log for errors.)

Cheers
-- perry

[Dewster35]

Would a general solution include "One" of the Holy Grails of home automation: multiple events/single trigger?

The switchboard plugin already does this to some degree with certain devices. Not a KPL solution by any means, but a similar idea.

[jay (support)]

Do I need to worry about cmdSuccess in incoming INSTEON commands being False, and if so, what am I supposed to do about it - ignore it? Yell at the user?

Pretty sure you can just ignore it. If you were to receive a failure I'm not sure you could do anything about it anyway.

Is there something problematic about calling indigo.server.turnOn from inside an insteonCommandReceived handler? When I do, I get frequent "send failed (no acknowledgment)" errors. Adding a one-second delay solves the problem, but of course isn't nice for responsiveness. (And it really needs to be almost a full second; delaying by 0.3 seconds doesn't seem good enough.)

So, yeah, it's sometimes going to be a problem because it's likely that the INSTEON cleanup messages from the command are still floating around - the delay gives them a chance to complete. A delay is your only option or you'll get collisions.

Is there any way my plugin can find out that a turnOn/turnOff command has failed, so it can retry it? (Short of issuing a state query, at least, or filtering the event log for errors.)

There is no direct way to see if the last command to a device completed successfully on INSTEON devices yet - but it's something we want to get in at some point (not before Indigo 6 GM though).

Until then, I suppose you could subscribe to device updates - then issue the command and add it to a queue internal to your plugin and wait for a device update. If you don't get one within a couple of seconds then assume it failed and try again.

[Perry The Cynic]

So, yeah, it's sometimes going to be a problem because it's likely that the INSTEON cleanup messages from the command are still floating around - the delay gives them a chance to complete. A delay is your only option or you'll get collisions.

Interesting. I was assuming that Indigo would queue INSTEON commands to avoid collisions on its own. Not true? There's no collision procedure on your side?

Cheers
-- perry

[jay (support)]

We do that - when the PowerLinc reports no activity then we send whatever is next in the queue. The problem happens after that - when the PowerLinc puts the command on the line at the same time the other device puts it's cleanup message on the line you get a collision. INSTEON's lower-level implementation doesn't handle collisions well at all and we're doing about as much as we can to deal with it.