ADT Pulse Web Control Plugin Idea (Need Help)

Plugins & Plugin Development General Plugin Discussion
1

Hi,

I have a cheap Honeywell Lynx system that ADT installed. I tried to see if there was any way to interface with it but I’m coming up real dry. Since I can’t find any way to communicate with the device, I’d like to use the ADT Pulse web interface to interact with it. I feel like this could be a popular plugin but who knows.

ADT Pulse, if you’re not familiar, is a web interface to interact with your ADT gear. It’s pretty easy to use. I’ve got all of the commands in the panel mapped out to simple HTTP GET calls. That’s not the way I would have coded a remote control security system but whatever.

Some things I’d want the plugin to do:

1.) Log onto the portal, constantly polling the web interface. There’s actually some AJAX I reverse engineered already so this can be done pretty easily. The refresh rate would have to be kind of high (15 - 30 sec) in order to pick up all of the activity.
2.) Emulate door / motion sensors
3.) Arm Stay / Arm Away / Disarm the system. Yeah, I know, someone hacks your wifi and gets into your MCV you’re toast. Whatever…

I’m getting OK with Lua scripting though my background is in C and Perl. I do a ton of regex / web based code for work. I don’t mind poking a hole in my firewall if someone wants to help me do some of the code (c’mon guessed!)

Some thoughts:

1.) Not sure if ADT (or the 3rd party company who runs the portal) will appreciate a device hitting it so often. Probably not a huge deal as there is already a 15 sec AJAX poll so it would just be like someone sitting in front of the portal 24/7
2.) All except the motion sensors have logging enabled - so we can technically just poll the log for activity. However, motion sensors do not log unless they trigger an alarm so we’d still have to poll for that.
3.) Commands to arm / disarm have a nice little XML interface
4.) I can do some code if someone wants to unload the mundane stuff to me

Kristopher

2

Personally, I’d buy another Panel… It’ll be cheaper overall given the manpower involved to do what you’re looking to do, the potential limitations of the Hosted “API”, the brittleness of the overall option and the [strong, strong] likelyhood that you’re breaking your TOS with ADT by doing any of it 8)

I know that’s probably not what you wanted to hear, but… there’s a reason these vendors make closed solutions.

Disclaimers aside, it sounds like you’ve already done the bulk of the work… determining how to “call” the hosted service. You should be able to piece together some of the rest by looking at one of the other Panels (like the DSC) and slowly substituting out bits of the code with [tt]luup.inet.wget(…)[/tt] calls to do whatever.

Startup “introspection” of devices may need to be disabled, since I’m guessing there’s no handy way to do that remotely.

3

Perhaps. Though my motivations would be more for unlocking the service to others instead of just myself. I’m actually not real keen on changing out my panel for one that’s already discontinued (Vista), or one that won’t work with the sensors I have. I’ve seen a few other requests for Lynx support on this forum.

The internet is inherently brittle - Google could pull support for GWC tomorrow, MCV could update a firmware and break everyone’s UI, or x10 could decide they don’t want to play with MiOS anymore. That does not particularly bother me. If ADT doesn’t want me to glue my Lynx panel to my Vera using their API, then they can send me a C+D. TOS didn’t say I couldn’t, but I am not a lawyer.

In any case I’ll get some code done tonight and let you know where I end up. I’ll probably run into some questions for you anyway.

Kristopher

4

guessed (and others),

I successfully wrote the prototype LUA to sign into the portal, regex out the appropriate information for the various sensors and states, and then emulate the AJAX and monitor status. Right now I’m just writing everything into a state table because the LUUP code is martian to me.

I started to port over the DSC module to use this code but I really could use the help regarding how all the partitions are setup.

Kristopher

5

@Kristopher,
Probably easiest to post the code that you have so far, most of the bits should be directly derivable from the DSC code, then stripped down.

Loads of [tt]string.match(…)[/tt] stuff in there for data extraction or places like this:
http://code.mios.com/trac/mios_brultech-power-monitor/browser/trunk/L_BrultechMeter1.lua#L355

although it sounds like you’ve already found that Swiss-Army knife :wink:

Right now I'm just writing everything into a state table because the LUUP code is martian to me.
Most of the required Luup bits can be forklifted from the DSC or any of the other panels.
I started to port over the DSC module to use this code but I really could use the help regarding how all the partitions are setup.
Start with one (1) partition. Most alarms only have one anyway, so that'll be a reasonable default. The "Partition" is the thing that you really Arm/Disarm through. The "Panel" is the top-most device, and typically represents the overall CircuitBoard (or whatever)

People use Partitions (sometimes called Areas) for their Main house, and separate ones for outbuildings (Garages, Workshops, etc), so most of the time you need only one Partition in a given system… get that working, and you can work out how to expand it to more later on.

Most of the Alarm implementation(s) have one implementation file (I_xxxxx.xml), and it has code/event/action handlers for all of the Children. When they get called, a “key” of sorts is passed in that’s usually used to lookup the repective Child [Luup] device, and take the appropriate action upon it visually, as well as proxy the command over to the target physical device (in your case call the remote service)

Again, strip the DSC and ad in the equivalent hooks to the new code. Forklift bits of code from the various plugins out there to get the basic callouts (etc) done and you’ll be well on your way.

[quote=“Kristopher, post:4, topic:169031”]guessed (and others),

I successfully wrote the prototype LUA to sign into the portal, regex out the appropriate information for the various sensors and states, and then emulate the AJAX and monitor status. Right now I’m just writing everything into a state table because the LUUP code is martian to me.

I started to port over the DSC module to use this code but I really could use the help regarding how all the partitions are setup.

Kristopher[/quote]

6

Hey Guessed - I started with the Caddx plugin instead of DSC… but I can’t remember why. I can go back to DSC if you think it’s better. Some of your code seems to be in that one too.

Florin and some MCV people are helping me now I think - so that’s a good sign. If you can shoot me a PM I’ll send you the code as I don’t really want to be responsible for pre-alpha stuff just yet.

Kristopher

7

All the codebases have similar elements, so it doesn’t really matter which one you start with… It’s just that I’m more familiar with the DSC codebase. We can proceed from whereever you are at.

Please post your code as an attachment here, I prefer to do things here as we get get a bunch of people to assist, over time, without having to bring them each up to speed (all review history can be online)…

Alternatively, I can get you a code.MiOS.com space if your familiar with SVN (or have tools that’ll SVN for you)

8

Not trying to discourage your developing this (sounds like a fine idea to me), but the Vista series panels aren’t discontinued; they’re still in production.

9

Lynx panel only has one partition, u should upgrade your level of pulse to the next level, as it comes with the I hub that will pretty much do everything that MCV will do, well close… z wave control, some wifi devices. You would have to upgrade your panel to a Vista 20 but your monitoring will stay the same. But for the $250 or $300 bucks to upgrade compared to writing a very awkward approach to intergration for 40 hours hmmmm…