Page 4 of 6
Re: 3rd Party Local API - Beta Testers/Contributers Wanted
Posted: Fri Dec 07, 2012 11:00 pm
by donnyk
gschrader wrote:Just tried this, very good start. I'm able to arm/disarm and my zones update. I'm not sure the partition status is working, it always said 'armed': False for me. Is it too soon to request some new features?
I see in the code the push notifications, I assume that isn't hooked up yet?
gschrader,
Please feel free to pm me the log so I can take a look at the events that led to your alarm being armed. It may do it slightly different the mine and as a result that may be why the events don't get triggered. As well any features requests would certainly be welcome. If you give me a top5.. I'll look into it
I am not really happy with how I am tracking the state of everything at this point. I have a busy weekend (throwing a party as I just got married/eloped 3 months ago or so) but maybe Sunday I will have some time to take a look, I'm going to change it up a little bit.
As for notifications that is ready to go perse but yes not hooked in yet. I need to make that configurable and think of a good way to configure it. Doing it all in a database per pounders thoughts might not be a bad idea but I'd like to keep this stupid simple too. I will think about it.
Re: 3rd Party Local API - Beta Testers/Contributers Wanted
Posted: Mon Dec 10, 2012 5:31 pm
by donnyk
The code has been updated with much improved event tracking and json output for current status.
Re: 3rd Party Local API - Beta Testers/Contributers Wanted
Posted: Tue Dec 11, 2012 3:05 am
by donnyk
donnyk wrote:The code has been updated with much improved event tracking and json output for current status.
Zone and partition names now committed to github and available via json requests.
Re: 3rd Party Local API - Beta Testers/Contributers Wanted
Posted: Tue Dec 11, 2012 10:52 am
by donnyk
Pounder,
Have you seen anything weird happen to the TPI connection when chime is enabled or disabled? I've seen some funky behaviour that doesn't go away until I go to the TPI web server and tell it to reboot. Give it a try and let me know.
Re: 3rd Party Local API - Beta Testers/Contributers Wanted
Posted: Tue Dec 11, 2012 7:30 pm
by PurdueGuy
Wow....I didn't realize I didn't have notifications for replies turned on for this thread...sorry!
I'll see if I can grab things tonight and see what havoc I can wreak in the next few days, if I'm lucky to get any time at all!
Re: 3rd Party Local API - Beta Testers/Contributers Wanted
Posted: Thu Dec 13, 2012 3:08 am
by donnyk
Just a FYI, committed more code to git hub.
https://github.com/juggie/AlarmServer
Feature set so far:
- Start of an api for accessing the alarm interface.
- Avail Commands (all replies are json):
- /api/alarm/arm
- /api/alarm/stayarm
- /api/alarm/disarm
- /api/alarm/disarm?alarmcode=1234
- /api/alarm/refresh (sends 001 to force the 2DS/3 to resend all current states, used for debugging)
- /api dumps all current status in a json object.
- Web interface is non-existent. I require a html based w/ javascript enabled interface that pulls data from the json object and displays it. On a timer ~15 seconds as to keep the screen accurate. Should have buttons for all current commands and you can also assume others will be present (eg chime). When command is pressed eg arm, display result. I believe gschrader plans to take a stab at this, this weekend. My html/javascript foo is weak, i can do it but i don't like doing it I am not a UI guy. The json object also includes the most recent events for each zone and partition up to a user configrable max. These could also be displayed.
- The mini web server will also serve files out of the ext/ sub folder from within the directory where the source is installed. Currently favicon.ico is served from there.
- The proxy does work, I have tested it by running this code a client of itself, as well as using the android TPI client. It has no protection for doing stupid things and may never have that. Consider yourself warned. I would like to put all the smarts into the http/api/json interface rather then spending time on a TPI proxy.
- Zone and Partition labels were added recently.
- Notifications via pageonce (android & apple clients) work great but are not hooked in yet. An entire configuration system to select which events you wish to be notified for etc is missing. Any suggestions on how to implement a user friendly config for this are welcome.
Todo:
- Notification system (emails, other misc notification options)
- Mini GUI
- Authentication so you can safely port forward from an external network onto your lan.
- Distant Future: Android App.
- Any other ideas? Submit them here or via github
.
Disclaimer: This is the very first python application I've ever written. I chose python for several reasons I won't bore you with again but mostly it has been a fun learning experience. I have been programming for 10+ years but python is new to me. As a result there is a good chance I will have made poor decisions or done things in a less then optimal way. If anyone has suggestions or comments, please feel free to make them or even better make some changes to my code on github and submit it back to me to be committed!
Thanks!
Re: 3rd Party Local API - Beta Testers/Contributers Wanted
Posted: Fri Dec 14, 2012 11:18 am
by mikep
Hi guys - I might be able to help some, but I'm struggling a little to understand what the interface would be used to do.
From what I can tell, unless you host it on a web server with SSL and generate your own certificates you can't expose this interface outside of a local encrypted LAN - do I have that right?
So it's intended primarily to capture a log and status to display in a local web client? And then provide a REST API to do things like integrate into a home automation system, something like that?
I do have an engine that I use for system status tracking myself, I could pop a REST interface on it if that would help - then the focus could be on the rest of the function you wanted to enable.
Mike
Re: 3rd Party Local API - Beta Testers/Contributers Wanted
Posted: Fri Dec 14, 2012 12:14 pm
by donnyk
mikep wrote:Hi guys - I might be able to help some, but I'm struggling a little to understand what the interface would be used to do.
From what I can tell, unless you host it on a web server with SSL and generate your own certificates you can't expose this interface outside of a local encrypted LAN - do I have that right?
So it's intended primarily to capture a log and status to display in a local web client? And then provide a REST API to do things like integrate into a home automation system, something like that?
I do have an engine that I use for system status tracking myself, I could pop a REST interface on it if that would help - then the focus could be on the rest of the function you wanted to enable.
Mike
Hi Mike,
We/I are working one step at a time, you are correct at this point there is no encryption or authentication layer bolted on yet, but if you read over the entire thread I have mentioned that is on my todo list several times. I was just discussing that this morning with gschrader actually and I may use this weekend to convert the built in web server to https. This will be done in python so no other external web server will be required. It may however require installing an addon on top of python but that is worth it in the name of security.
I did notice a Dsc server in java application mentioned on your web site but nothing was released.
The goals are:
- to provide a web interface that replaces the existing web interface in situations where it is preferable to not use it, or it may not be possible to use it.
- To provide an api that keeps state and will make smart decisions.
- To allow you to integrate with whatever solution you chose with minimal difficulty. Your dsc client for android while nice, is fairly limited by the TPI interface in the sense that it takes 5-10 seconds at least just to load up all the current information when launched. Then it has to maintain an open connection to watch things change (which does not allow the phone to sleep, a huge battery killer), or keep creating a new connection and downloading the status of every zone/partition each time. Your current DSC server app may solve this but then it requires an always on android device of some sort to act as the server.
- To allow alternate types of notifications, eg push notifications using data as opposed to data/sms.
- Make intelligent decisions for you based on your rules, eg if your stay alarm isnt armed by midnight and no zones are open, arm it.
- Easily Integrate with home automation software without hogging the one allowed TPI connection.
- More I can't think of, or have not thought of yet.
Donny
Re: 3rd Party Local API - Beta Testers/Contributers Wanted
Posted: Fri Dec 14, 2012 1:05 pm
by mikep
Cool, HTTPS is a good solution (as you probably know without it all of the information including passwords would be sent in the clear). Terrifying if you connect from an internet cafe or over free wifi! SSL certificates are a pain but do-able. You might want to provide some sort of lockout to prevent brute force password attacks as well.
You're quite right, the DscKeypad is for occasional access from your phone, or use with the widget on a dedicated tablet as an additional and portable DSC keypad. I do like the immediacy of the zone updates of the always on widget - my web server version (based on the IT100) required refreshing and there was a short lag. Once they eyezon service came out I couldn't see any reason to keep the web version.
I've just posted the java version for non-android systems that gives that same fan-out capability. You're right, it really helps a lot with performance to cut down the unused zone and partition traffic (I've been using the server for so long I almost forgot how slow the single connection startup is comparitively). The DscServer on (a dedicated) android adds text (SMS) messaging in the case of network outages.
I think the DSC itself already has much of the smart arming built in doesn't it?
Anyway, if it helps, the java DscServer can be used to do the fan-out capability requested early in this thread so you can do development on multiple systems at once (in fact that's how I do my work - I hub/spoke or daisy chain the servers and test them simultaneously). It responds just as the envisalink would other than filtering out unused zone and partition information. I'm already working on the REST API for the management functions I need, it's pretty trivial for me to add additional commands if it's useful and you all could focus on the other functions instead.
Mike
Re: 3rd Party Local API - Beta Testers/Contributers Wanted
Posted: Fri Dec 14, 2012 1:14 pm
by donnyk
mikep wrote:Cool, HTTPS is a good solution (as you probably know without it all of the information including passwords would be sent in the clear). Terrifying if you connect from an internet cafe or over free wifi! SSL certificates are a pain but do-able. You might want to provide some sort of lockout to prevent brute force password attacks as well.
You're quite right, the DscKeypad is for occasional access from your phone, or use with the widget on a dedicated tablet as an additional and portable DSC keypad. I do like the immediacy of the zone updates of the always on widget - my web server version (based on the IT100) required refreshing and there was a short lag. Once they eyezon service came out I couldn't see any reason to keep the web version.
I've just posted the java version for non-android systems that gives that same fan-out capability. You're right, it really helps a lot with performance to cut down the unused zone and partition traffic (I've been using the server for so long I almost forgot how slow the single connection startup is comparitively). The DscServer on (a dedicated) android adds text (SMS) messaging in the case of network outages.
I think the DSC itself already has much of the smart arming built in doesn't it?
Anyway, if it helps, the java DscServer can be used to do the fan-out capability requested early in this thread so you can do development on multiple systems at once (in fact that's how I do my work - I hub/spoke or daisy chain the servers and test them simultaneously). It responds just as the envisalink would other than filtering out unused zone and partition information. I'm already working on the REST API for the management functions I need, it's pretty trivial for me to add additional commands if it's useful and you all could focus on the other functions instead.
Mike
Hi Mike,
I have a pretty big hate on for java (despite the fact that its the core of android aps which I like) but I will take a look. What I love about python is the rapid development aspect as well as the portability to tons of platforms. Java obviously does the same thing, but is definitely more overhead. I've ran this code on my router, several linux boxes and my windows box, they all work great. I am not just doing this though for the need of the application a lot of my drive comes from the desire to just learn a new language and do something different. The primary goal for me was a fun learning experience and secondary to that was to come up with a useful application.