High(er) level scene use?

Insteon scenes are handy, but they won't work with Z-Wave (or any other interfaces we may want to add). If you manage to make Z-Wave scenes work, they won't work with Insteon devices. And many of us will end in a mixed world with multiple interfaces. The result will be some Insteon-specific PowerLinc scenes and some Z-Wave specific whatever-scenes and some other gizmo over to the side - not a terribly scalable mix.

Have you considered making the protocol scene support implicit in Indigo's operation? Let's say I write a humongous action group where I tell all my lights to turn off (except a few to 15% as night lights, and the fans off except a few, and arm the alarm system and stuff). I just did. How cool would it be for Indigo to hand this group to the Insteon interface to pull out all the actions it can bundle up and define as a PowerLinc group; for the Z-Wave interface to do likewise; and all other interface-like plugins getting a shot at pulling out "their" pieces as efficiently as possible? The user would just write action groups in Indigo, and all the heavy lifting and configuring would happen under the hood. And if none of the interfaces has anything to offer, the result is still an action group that works just fine (if slowly).

Okay, I can dream...

Meanwhile, are there any existing Python APIs for plugins to manage PowerLinc scenes?

(Strange how all this suddenly matters when you've got 80+ Insteon switches to manage in your house. )

Cheers
-- perry

[matt (support)]

Hi Perry,

We've definitely thought about it. But it was sort of like staring at the sun, so we had to turn our heads to keep our eyeballs from melting. Seriously though, although it might be possible to pull-off and we are all for abstracting away protocol details there are enough complexities (limited number of PowerLinc Group/Scenes, the time it takes to add/remove scenes, etc.) that I think it would be pretty difficult to implement. It would be great (and magical) though if it was in there.

Regarding the APIs, the only thing currently available is to send the scene ON / OFF commands (ex: indigo.insteon.sendSceneOn). Unofficially, and subject to breakage if you rely on the underlying data structures returned, you can do something like this to get the links:

Code: Select all

links = indigo.rawServerRequest("GetLinksForDevice", {"Name":"office desk lamp"})
indigo.server.log(str(links))

We've definitely thought about it. But it was sort of like staring at the sun, so we had to turn our heads to keep our eyeballs from melting. Seriously though, although it might be possible to pull-off and we are all for abstracting away protocol details there are enough complexities (limited number of PowerLinc Group/Scenes, the time it takes to add/remove scenes, etc.) that I think it would be pretty difficult to implement. It would be great (and magical) though if it was in there.

It's definitely an "interesting" problem. You might be able to kind of ease into it - add an "Optimize" button (or menu item) to action groups, which simply goes out to the interface plugins and asks them to allocate resources if they think it's worth it. Keep the original group around, which gives you a fairly straight-forward way to back out later. Face it - most of your users won't ever run out of 200+ PowerLinc scenes (if you don't waste them on trivial groups). If you ever get that complaint, you've got it made.

links = indigo.rawServerRequest("GetLinksForDevice", {"Name":"office desk lamp"})

Um... how would I use that to read (and possibly edit/create) PowerLinc scenes? (What "name" is the PowerLinc itself?)

Cheers
-- perry

[matt (support)]

links = indigo.rawServerRequest("GetLinksForDevice", {"Name":"office desk lamp"})

Um... how would I use that to read (and possibly edit/create) PowerLinc scenes? (What "name" is the PowerLinc itself?)

For the PowerLinc itself, use PowerLinc Interface.

To write the links back to Indigo you would use something like (untested):

Code: Select all

indigo.rawServerCommand("SaveChangedDeviceLinks", argsDict)

Where the argsDict has 2 keys: ChangedLinks (whose value is a list) and Name (whose value you probably want "PowerLinc Interface"). Here is an example I captured from the Indigo client after adding 2 links to PowerLinc Group #5. One was to an ApplianceLinc, the other to a LampLinc.

Code: Select all

     Name : PowerLinc Interface (string)
     ChangedLinks : (list)
          LinkChange : (dict)
               AddressStrUI : 01.1D.C3 (string)
               AddressValUI : 73155 (integer)
               Data1UI : 191 (integer)
               Data2UI : 30 (integer)
               Data3UI : 1 (integer)
               DeviceNameUI : Office LampLinc (string)
               GroupNumUI : 5 (integer)
               Persistent : true (bool)
               RuntimeID : 0 (integer)
               RuntimeID_bl : 0 (integer)
               Status : 3 (integer)
               Type2 : 2 (integer)
          LinkChange : (dict)
               AddressStrUI : 21.72.C0 (string)
               AddressValUI : 2192064 (integer)
               Data1UI : 255 (integer)
               Data2UI : 31 (integer)
               Data3UI : 1 (integer)
               DeviceNameUI : Office ApplianceLinc (string)
               GroupNumUI : 5 (integer)
               Persistent : true (bool)
               RuntimeID : 0 (integer)
               RuntimeID_bl : 0 (integer)
               Status : 3 (integer)
               Type2 : 2 (integer)

The status enum values are:

Code: Select all

   kInstnLinkStatus_InSync = 1,                     // currently in-sync
   kInstnLinkStatus_Edited,                     // user had edited   -- need to sync
   kInstnLinkStatus_New,                        // user just created -- need to sync
   kInstnLinkStatus_Deleted,                     // user just deleted -- need to sync

And Type2 is 1 for a link to a controller and 2 for a link to a responder. All links you would write into the PowerLinc would be 2.

I'm not positive, but you probably don't need to write these key/values (or the value isn't really used by the server when saving): AddressStrUI (AddressValUI is needed though), DeviceNameUI, RuntimeID, RuntimeID_bl.

All of the info above is subject to change without notice, of course. That said, we have no plans for any modifications nor have there been any changes in the above structures or API in a long time.

Great. Now I've got enough rope to hang myself and enough powder to blow myself up.

When I later ask Indigo to resync everything, will it wipe out everything I've done this way? Or how do I make Indigo make my changes persistent? (And when will I stop asking those questions?)

Cheers
-- perry

[matt (support)]

Great. Now I've got enough rope to hang myself and enough powder to blow myself up.

We are anxiously awaiting the results.

When I later ask Indigo to resync everything, will it wipe out everything I've done this way? Or how do I make Indigo make my changes persistent? (And when will I stop asking those questions?)

SaveChangedDeviceLinks is what is called when you close the link editor dialog (it is also called if you press the Sync button in the link editor, right before it requests the sync). So those link changes are written to the Indigo database and if the Status flag is marked as added, edited, or deleted will then be pushed to the devices upon next sync. So the ReSync is what you'll do to push the changes you have made out to the PowerLinc and other modules.