Need help: linking control page to remote process via XML

I have a continuously running perl script which maintains TCP connections to a terminal server, in turn connecting to various RS232/RS485 devices around the house (A/V equipment, thermostats, spa, alarm panel, etc). This script also keeps a connection to Indigo via the XML port, which provides a very nice event feed in both directions.

Although some bits of automation logic are handled directly by my program, in other cases I find it useful to integrate with Indigo, particularly for the control pages. I am working on one for my spa, which uses Pentair equipment.

I have struggled with how to reliably transmit control page button presses to my external script. Indigo does not have an explicit means to do this as far as I can tell, so I tried to be creative. At first I did it using a variable for each button. This proved problematic for a variety of reasons: there are situations which can cause commands to the Pentair interface to be dropped (equipment is in service mode, two commands sent in immediate succession, TCP connection lost, etc). Since Indigo only sends the variable change notifications when the variable actually changes, there is no event triggered when the button is pressed a second time. Thus the control page could easily get in a state where it would not reflect the actual situation at the spa controller, and further button presses would not have the expected effect because they were already "stuck down".

I noticed that the Indigo log records an entry every time a button is pressed, so I tried using that to trigger my script. This worked MUCH better but was kind of kludgy to set up. Each button is configured to assert a dummy variable, because it needs to have some action associated with it in order for Indigo to log it. Then my script watches for the log updates, and sends the corresponding commands to the Pentair system. When the pentair responds with the status updates, these are mapped to the variables that I want to show in Indigo.

At first, while testing this on my Mac's browser, everything appeared to be working perfectly, but then I ran into a show stopper: when clicking control page buttons on the indigo touch app, no updates are recorded to the log. However, if I use Safari on the iPhone to open the control page, it works correctly! So that is question #1: what's going on differently in the app that makes it fail to log the button events?.

And Question #2: could Indigo provide a better way to do this by triggering an explicit event notice to an XML client? . Actually, the LogStream messages would suffice as-is, if I could be sure that they were sent on ANY button click event (even if the action associated with the button is a no-op). What would be even better is if it could use a symbolic name so that I don't have hard coded z-order numbers in the external script.

thanks!

-----
Here's the control page [updated]:



Here's how the buttons are configured:



My external script is connected via the Indigo control port. It receives control page events via the Indigo log:



Each control page button (hard coded by z-order) triggers a corresponding command which is sent to the Pentair iLink interface:



When I receive status updates from the Pentair system, they are mapped to variable updates which are sent to Indigo:



..and likewise for the chemical feeder:

[matt (support)]

Indigo Touch sends commands directly to Indigo Server and not Indigo Web Server. Actually, that isn't totally true because the commands actually pass-through the Indigo Web Server, but it is more of a proxy situation with the Web Server acting as a gateway into Indigo Server. The logging you are patching into happens at the Indigo Web Server level, and thus never occurs when accessing from Indigo Touch. Perhaps at some point I'll push that logging down into Indigo Server...

But I've got a couple of different solutions you can try:

1) Change your Control Page control Server action from Modify Variable to Execute AppleScript. You can then use the AppleScript log verb to log whatever you want/need that can be caught by your Perl script.

2) You idea of changing the Indigo Variable value and catching that change from Indigo Server in your Perl script is pretty good. To avoid the problem caused by Indigo Server only broadcasting changes, just change the Variable value twice. For example, change it to "Spa Control Hit" and then immediately (you can have multiple Server actions for a single Control Page control) change it back to "--" or just empty. Indigo Server will then broadcast out both changes and you can just ignore any value changes to "--". I would suggest you create an AppleScript attachment that defines a function to encapsulate the functionality a bit. The advantage of this technique versus catching the Event Log stream additions being that it won't cause extra event logging.

This is an interesting level of integration you are doing -- thanks for sharing the specifics of your setup and solution.

1) Change your Control Page control Server action from Modify Variable to Execute AppleScript. You can then use the AppleScript log verb to log whatever you want/need that can be caught by your Perl script.

Great, I tested that and it seems to be just the ticket. I'll just use a form like "button: spa/filter_on". Yes it creates a little redundancy in the log when using a web client but that doesn't bother me.

2) You idea of changing the Indigo Variable value and catching that change from Indigo Server in your Perl script is pretty good. To avoid the problem caused by Indigo Server only broadcasting changes, just change the Variable value twice. For example, change it to "Spa Control Hit" and then immediately (you can have multiple Server actions for a single Control Page control) change it back to "--" or just empty. Indigo Server will then broadcast out both changes and you can just ignore any value changes to "--". I would suggest you create an AppleScript attachment that defines a function to encapsulate the functionality a bit. The advantage of this technique versus catching the Event Log stream additions being that it won't cause extra event logging.

It later occurred to me that I could use incrementing... but I don't like using variables for this because it entails a potentially large number of variables. The one-line of Applescript is nice because it's contained within the control page config.

This is an interesting level of integration you are doing -- thanks for sharing the specifics of your setup and solution.

Yeah I am having a lot of fun with it.

I have a continuously running perl script which maintains TCP connections to a terminal server...

I have been playing with remote control of my A/V amp (Denon 3808) and have had mixed results - sending commands is working. But, so far, listening for output from the amp has been a failure. It sounds like your PERL script might be quite useful. I don't need the terminal server since I can TELNET directly to the amp. But, if the script could connect to the amp then I might have something.

Do you think this would work, and are you willing to share your script?

Thanks

I have a continuously running perl script which maintains TCP connections to a terminal server...

I have been playing with remote control of my A/V amp (Denon 3808) and have had mixed results - sending commands is working. But, so far, listening for output from the amp has been a failure. It sounds like your PERL script might be quite useful. I don't need the terminal server since I can TELNET directly to the amp. But, if the script could connect to the amp then I might have something.

My scripts would be perfect for this, but I have to warn you it is nowhere near a state that is easy enough for general consumption - you would need some proficiency in perl to be able to add support for the Denon and write your control logic. But that said, all the hardest part is done for you, and one of the devices I'm already supporting is probably very similar to the Denon so you would have a template. Do you have a protocol spec for it?

Yes. I have the full spec, and, I used to be pretty competent at perl. PM me with your email address and I can send you a copy of the protocol spec.

or... just take a look at: http://usa.denon.com/AVR-3808CISerialPr ... 5.2.0a.pdf

Looks like a good fit. I need to clean up a few things and then I will post some code for you. I'm automating several Rotel devices which are very similar to this.

Here you go: http://www.seanadams.com/ha/automogator [link updated]

Here's a quick overview:

I am using POE (Perl Object Environment) to handle all the nasty low-level stuff like timers, event dispatching, socket multiplexing, buffering, reconnecting, etc. However, POE has a significant learning curve of it's own - you should in particular read up on POE::Component::Client::TCP to get an idea of how I'm using it.

automate.pl is the top level where you will see the control logic that is implemented for my own house. Since it's all specific to my house, you will be mostly writing your own one of these - this is just an example.

Automogator.pm is basically a wrapper for the POE stuff. Just add a line here "use POE::Filter::Denon" for the module that you will be creating.

POE::Filter::* are each of the modules needed to communicate with various devices. Filters convert back and forth between device-specific formatting and perl data structures. Devices already implemented to varying degrees are:

• Indigo
• Rotel Receiver, DVD player, and Radio tuner.
• "GC IRE" infrared receiver (very cool product for this)
• NEC plasma TV
• Pentair pool controller
• "CAT 2000" ph/ORP controller
• Aprilaire thermostats (work in progress)

There is also available from CPAN a filter for the SqueezeCenter software (for the Logitech Squeezebox).

POE:Wheel::* are more sophisticated modules for communicating with devices where more than just a filter is needed. Right now there is just one example for the Elk M1 alarm panel. Indigo actually should be a "Wheel" so that I can encapsulate its login process instead of exposing it in my top-level automate.pl.

elk_test.pl is a test for the ELK M1 wheel. I have not actually used this for anything yet, but it is almost done and will be one of the more interesting devices that is supported.

It would be nice to have a foo_test.pl for each of the filters/wheels to help you troubleshoot and/or bring them up in your script for the first time. Unfortunately I haven't done that yet so you will need to start by stripping down my automate.pl script.

Most of my devices have RS232 interfaces, so I communicate with them via a Digi Portsterver TS16 terminal server - they are easy to find on ebay for $350 or so. However, if your device accepts TCP connections directly, that is even better.

WOW! I guess I've got my work cut out for a day or two.

Thanks

Seanadams... I sent you a PM a few days ago, did you see it yet? (It seems to be stuck in my outbox and I'm not sure if it was actually sent)

Question on the Automogator code:

I am setting up a HA configuration that includes both ELK M1 and Indigo so naturally I am investing Seans very cool POE libraries. (I'm still trying to wrap my head around the POE paradigm). I have the ELK and Indigo filters working, but I was hoping to see the automate.pl to give me a head start on implementing the control logic (I'll need the help, I haven't done much coding of late...). The tgz referenced above is no longer available. Is it available elsewhere? Is anyone else working on a similar project?

It's here: http://www.seanadams.com/ha/automogator/
The download link on that page works.

I will have a look next week and see what changes I have made since that release and put together an update. I'm glad someone is going to use the Elk module - you will really like it!

Sean,

Could you post a basic example of just turning something on/off/toggle from automogator framework?

I've tried stripping down your web example.

The $poe_kernel->post('Indigo', 'Command', 'TurnOn', uri_unescape("basement%20light")); seems to be the key line, but if I take it out of the web_index sub then it errors out. Works fine if it is inside but then I need to reload a web page to trigger it.

Also is there a list of commands that could be passed, or did you just dig thru things to come up with the TurnOn/TurnOff?

Thanks!

-Chris

I am glad people are taking an interest in this. It will certainly motivate me to make some more docs and examples.

So the first thing to understand is that -everything- in this paradigm must be driven by some event. It is not meaningful for example to call that from the main body of the program because that code is only executed during initialization, which means (among other things) that the connection to Indigo hasn't been established yet (indeed, the POE kernel isn't even started yet).

If you want to make a trivial test program that just issues one command to Indigo, you can put it in the initialized_callback sub block - any code in here is executed once, upon a successful connection and authentication to Indigo. But that is probably not what you ultimately intend to do. Usually there will be some other thing that triggers it, and that event needs to come in from a POE component. It could be the POE web server or it could be one of my other modules (Elk, etc).

Also it is probably easiest to let Indigo do what it does best and put your rules about turning on devices and such into Indigo triggers. The way I use automogator is mostly as a "glue" layer to just get events into and out of Indigo from other devices. For example my alarm panel communicates with Indigo by setting variables, eg set variable "zone update" to "front door: violated". Then in Indigo I will match on this variable condition and use that to turn on the foyer lights if it's after dark. No sense reinventing the wheel although you certinaly COULD do this in automogator.

So the question is: what is the other thing besides Indigo that you will be talking to?