Creating a control page programmatically by editing db

I am getting ready to create my multi-room AV controls and this is going to involve a huge number of buttons, variables, and a series of applescript commands for each button.

Since the buttons are all very similar in nature but each needs to be slightly edited, this would take forever to do with the control page editing GUI - but it's an easy task for a script.

So can I just edit my XML house database? It looks feasible but is there any other statefulness in Indigo that might cause it to freak out if I attempt this? Obviously I would work on a copy and re-load after making changes.

And as long as I'm asking the question, can I do this "live" over port 1176? Creation of variables is documented but not control page elements.

Also would I need to generate AppleScriptSCPT?

Ha, cool. I guessed "GetControlPageList" and I that works splendidly with my existing Indigo client library. I assume I can then use that structure to create a new control page using AddControlPageElem.

And the compiled Applescripts are not exposed here so I guess I don't need to deal with that.

To create a new minimal control page based on the structure I see in GetControlPageList, I tried the following:

Code: Select all

<Packet type="dict">
   <Type type="string">Command</Type>
   <Name type="string">AddControlPage</Name>
   <Data type="dict">
      <Category type="string">0</Category>
      <Name type="string">new_13561</Name>
      <ObjVers type="string">4</ObjVers>
      <PageElemList type="vector" />
      <Size type="string">300 360</Size>
   </Data>
</Packet>


This does not work - IllegalParameterError. But Indigo does recognize the command "AddControlPage". If you could give me an example that would be awesome!

Never mind I figured out what it was looking for:

Code: Select all

<Packet type="dict">
   <Type type="string">Command</Type>
   <Name type="string">AddControlPage</Name>
   <Data type="dict">
      <ControlPage type="dict">
         <Category type="string">0</Category>
         <Name type="string">empty copy</Name>
         <ObjVers type="string">4</ObjVers>
         <PageElemList type="vector"></PageElemList>
         <Size type="string">300 360</Size>
      </ControlPage>
   </Data>
</Packet>


[matt (support)]

Hi Sean,

Looks like you are making some progress.

I don't have access to the files right now to provide concrete examples, but everything you've reverse engineered looks correct to me. The compiled AppleScript binary chunk should be optional - you should be able to just include the text source (under a different object tag name, which I don't recall off the top of my head) and Indigo Server will compile it when needed.

OK good... the rest looks straightforward since I will just be copying and modifying structures from another page. It's nice that I can create the whole page as one object.

Is it possible that the process you are creating could be adapted to allow copy/paste of single/multiple buttons between control pages, or other actions?

Is it possible that the process you are creating could be adapted to allow copy/paste of single/multiple buttons between control pages, or other actions?

That's essentially what I'm doing. I haven't done any work on this since my previous comments but I've gotten as far as proving the concept. What I will do is use Indigo's WYSIWYG to create a template for a single instance - i.e. one room. Each room will have a power control, volume, and input selection.

Then I use my script to extract this template control page from Indigo, and then have it create a new control page which iterates the template several times. On each iteration I can have it modify some parameter, i.e. the name of the room and the corresponding zone ID to be controlled on the audio switchbox. Also of course the Y coordinates of the buttons will be incremented for each group.

At first I was thinking the the control page would contain applescripted actions for each button to send commands to the switchbox. However I realized it would be better to have the control page only affect variables, and then use triggers on those variables to issue the commands to the switchbox. This abstraction allows for any other indigo event (eg an Insteon command) to trigger audio controls simply by updating a variable.

Obviously, this entails a huge number of variables. For each room we have volume, power, and true/false for each input. But the creation of variables can also be scripted in the same way. So if I do 8 zones and 6 inputs I am looking at perhaps 80 control page elements and about the same number of variables.

It additionally occurred to me that even though the iPhone control is the most capable, it would still be nice to have hard buttons on the wall. It occurred to me that an Insteon keypad dimmer would work, and the dim state of the keypad could be linked to volume (obviously with no light connected).

What mechanism are you using for the "GetControlPageList" request? Is it a RESTful URL?
--thanks

It's a perl application which talks to the Indigo control port - that's the same protocol that is used by the Indigo client/server communication. http://www.seanadams.com/ha/automogator/

Check out the indigo_example.pl

I should add that all of this probably can also be done by editing Indigo's XML database file, which is what I was asking at the top of this thread. Although it's mostly cut/paste work, editing XML by hand can be tedious, but that might be an easier way to go if you're not down with perl. I already had developed the tools to talk to Indigo so this was a better approach - for one thing it does not require relaunching indigo to make changes.

Probably i don't fully understand what you're doing- why would this approach be better than just sending an AppleScript to the Vaux to set zone(s), source, volume? Without true feedback the variables would only represent the assigned state, not the actual state, or pseudofeedback. Once you were out of sync you'd need to reset and start over? Also, variables could set initial volume control but not ramp without a huge number of them.

The idea is to provide a "bottleneck" through variables, so that you can have multiple sources of control input while keeping a consistent view of the state of the box.

To get more specific suppose this scenario: we want to allow volume control in a room by multiple means:

1) clicking a control page button
or
2) adjusting the level of an insteon dimmer.
or
3) arming the alarm (turn everything off)
or
I could probably think of more... eg paging mode to make some announcement via text to speech

I _could_ attach separate applescript actions to each of those things which would send commands directly to the vaux. That would work except that the control page would not show the correct state for the audio controls unless you also updated those variables that are being indicated by the control page. So instead of having to update variables AND issue the vaux commands from every control, you would ONLY update the variables.

Then for each variable, have a triggered action which sends the commands to the vaux to synchronize it to whatever the variable has become.

Besides solving the state indication issue this is also simpler to set up and maintain, albeit perhaps at the expense of having to define more triggered actions than otherwise. You don't have to worry about the low-level switchbox functions when thinking about higher level control logic, and if, say, a change is made to the switchbox wiring you only have to update the commands in the one place.

Can't wait to see the implementation. Also, I guess you will handle volume by incrementing the variable and sending a + or - command to the box with each tap?
Using variables is a great idea for reflecting the state of a zone, etc. Wil you use a text box eg on off for a zone, or create bright/dark buttons for instance depending on the zone or source state?