For others who are running AlarmServer on a Linux box, here’s a REALLY simple init script for those who want to run it as a service.
Use the appropriate Python and script locations for your case.
@SteveJenkins yeah you never want to replace the default Python on most Linux distros since it will cause all sorts of problems. For CentOS5/RHEL5 I usually compile a custom Python2.7 and install it alongside the main python with a -2.7 ending as in ‘/usr/bin/python-2.7’ and then all the tools like easy_install and pip get the same -2.7 ending to identify them properly. That way you get an updated Python install without changing the system wide Python at all.
Getting closer. I deleted the SmartApp, removed the devices from my phone, and started over from the “Create Panel Device” step.
alarmserver.py is working fine. I can see the output on my server screen from the script as I move around in my office, I see:
2014-07-19 11:21:12 RX < 609 - Zone 024 Open
2014-07-19 11:21:12 RX < 653 - Partition Home Ready - Force Arming Enabled
2014-07-19 11:21:12 RX < 610 - Zone 024 Restored
2014-07-19 11:21:12 RX < 650 - Partition Home Ready
I follow all the steps as laid out, and I’m now seeing activity on the Alarm Panel device Activity Feed. A couple times every minute, I get a grey question icon in the feed, with “DSC Integration sent partition command to Alarm Panel.”
I only added one zone device, but nothing there yet.
I’m wondering if it has something to do with the REST API instructions where it says:
You will now be at an Authorization page, click on the dropdown and select your From: location. Now you need to authorize the Alarm Panel device you created earlier, it should be in the list under “Allow Endpoint to control These Things”. Make sure it’s selected and then click the “Authorize” button at the bottom.
The interface has a few more choices, and it wasn’t clear which radio button options to press. I’m wondering if I missed some.
Also, back on the smartthings-dsc-alarm README, it says:
Edit ‘alarmserver.cfg’ and add in the OAuth/Access Code information, adjust your zones/partitions and callback event codes as needed. Leaving them at the defaults is likely what you already want.
I interpreted that to mean I put the AppID and Access Token in the appropriate places, but beyond that I didn’t know if there were other settings I needed to change. When I saw:
[pushover]
enable=False
usertoken=tokengoeshere
That made me wonder what I’m supposed to put there.
I’m getting close. I’ll keep crunching, but any nudges are appreciated!
@SteveJenkins so a couple of things, 1 make sure you are in the smartthings branch after you cloned the AlarmServer repo. You can verify by typing ‘git branch’ on the CLI, you should see ‘smartthings’ and it should be green and have a asterisk in front of it.
2nd you should also see the 4 config options in the [alarmserver] section of the example config, those are the values you need to replace, not the [pushover] ones, just ignore the whole [pushover] section, that’s for notifications not smartthings and I don’t think it even works right now.
callbackurl_base=https://graph.api.smartthings.com/api/smartapps/installations
callbackurl_app_id=your_app_id_here
callbackurl_access_token=your_access_token_here
callbackurl_event_codes=601,602,609,610,650,651,652,654,656,657,701,702,750,751
3rd the devices you authorize don’t seem to matter much but ideally you should select any device that you created for this including the panel and any zones. However I think on my setup I just authorized the panel and the zones still work fine.
@sanity smartthings branch confirmed:
# git branch
master
- smartthings
My 4 config options were fine… except that I didn’t have the event codes 701, 702, 750, or 751. I’ve added them.
Also, I have 32 zones (it’s a 12,000 square foot house with lots of windows, doors, and motions), so I added a few more zone names:
zone26=AA
zone27=BB
zone28=CC
zone29=DD
zone30=EE
zone31=FF
zone32=GG
And wasnt sure if the user1=MyUser1 options should be messed with.
When I do the test URL (https://graph.api.smartthings.com/api/smartapps/installations/$appID/panel/609/1?access_token=$access_token) I get a blank screen in return, which I’m interpreting as sucess.
I’ve only added Zone V (22 - my office Motion) and Zone Y (24 - my office door) as devices.
The Alarm Panel device on my iPhone seems to be “reporting” properly now. It shows a green “READY” when I close my office door, and it turns yellow and shows “OPEN” within 5 seconds of me opening the door.
However, the door device itself always shows “OPEN” even when it’s closed, and there’s no activity log for the device. Same thing with the Motion zone’s activity log (empty).
And… I just figured something out!
On the mobile device, I went into SmartApps screen and hit the gear on the DSC Integration app.
Under “Alarm Panel” it showed “Alarm Panel (required), Alarm Control Panel, Door: Steve’s Office, Motion: Steve’s Office”
Under “Zone Devices” it showed nothing, so I hit the green arrow and selected both the Zone devices I’d set up.
As soon as I hit Done and went back to Things, the zones seem to be working! WOOT!
Now here’s where it gets weird again. I wanted to test to see which options are actually required to get this working.
So I went go back into the DSC Integration app settings and hit the green arrow under Alarm Panel. I see a display of all the devices on the system. If I deselect everything except “Alarm Control Panel” device, then go back and check my Things, it stops working. But the problem is that if I go back into the DSC Integration app settings and try to re-add all the previous devices under Alarm Panel… I can’t – it only lets you pick ONE device in the mobile interface. So unless you authorize the right ones the FIRST time when you manually put in the First URL in your instructions… you’re hosed.
I went back to my web browser and did the First URL again, and got the Authorization screen again, and added everything back, but that yields a new “code.”
In the mobile app, the Alarm Panel device shows READY and OPEN as it should, but the zone devices no longer respond.
So I had to take the new result code and generate a new access token with the 2nd URL, put that in the alarmserver.cfg file, restart alarmserver.py, then go back into the mobile device and manually add the zone devices in the DSC Integration App settings.
Now the zone devices are working and their activity feed is logging.
Now that we’ve found some bugs (seems like they are ST bugs more than with your code), I’m happy to help test further.
But the big question I’m wondering is… now that I can “watch” what’s happening with the alarm system through my EnvisaLink and alarmserver, how do I arm or disarm my alarm? 
Thanks again for the excellent help.
@SteveJenkins Congrats on getting it working!
So I don’t have arm/disarm functions built in yet, I’m waiting for ST to support a local hub action via HTTPS as I’m not willing to run my AlarmServer without SSL.
It could easily be added though if you modify the panel device and switch AlarmServer to non-SSL (it’s 1-2 lines of code changes to AlarmServer to disable SSL).
@sanity Thanks!
Strangely, when I first launched the app after adding all the zone devices (turns out I only have 26 of my 32 active), the app kept crashing. It would run for a few minutes, and then just barf.
Also, I noticed that zone devices don’t start changing the color of the icon (or logging any activity) unless they are actuated… meaning if a door is closed, it has to open once before the app seems to be “aware” it of it.
I’ve confirmed this many times, walking around the house opening windows, doors, and walking through rooms with motion sensors. I’ve now done all the “easy” ones… but apparently I’m going to need to trip my CO sensor, a smoke sensor, and a bunch of glass break sensors. Any way to “force” the system to poll all the devices?
Also, after “fixing” a few of the easy zones like that, the app stopped crashing. So I’m wondering if that’s coincidence, or if there’s correlation with possible mass polling.
On the SSL issue… if I made the change would it communicate with the local Envisalink via HTTP? If so, I’m fine running that without SSL. But if it’s going to something outside my firewall, I’m not so thrilled. 
@sanity: Even if I can’t arm and disarm the alarm yet, I’m assuming I can now use any of the contact or motion zones as triggers for other events, yes?
Answered my own question - I can use the test URL with the 610 command to “close” everything that’s open initially and make it “visible” to the system
@SteveJenkins yes you can use any zone now as triggers. The only place I have had problems is using them as triggers in the dashboard “Doors & Locks”. I have contacted ST support to try and resolve that issue.
The arm/disarm would go to the AlarmServer web interface not directly to the Envisalink as there is no way to send an arm event to the Envisalink besides using the TPI interface that the AlarmServer code uses. So no it would never leave your network and nothing would be directly exposed to the internet.
@SteveJenkins I have a script that just calls all the zone numbers and sends open then close to reset them all. I was never able to figure out how to make them start out in a particular state which would have been nice.
@sanity Can you share your script that resets all the zones? Should this be run every time AlarmServer is launched? Also - can anyone assist with the constant “zone commands” being shown in SmartThings? Is anyone else experiencing this (please see pic below)? Thanks!
@mbial The script is just a serious of copy and pasted curl lines that send the zone open command followed by the zone close command then as a final series of steps I reset the panel status as well. One line per zone for each open, then each close then 2 lines for the panel not-ready/ready. Previously I had to run it almost weekly when I used my ‘all zones in a single smartthings device setup’ but now that I’m using the singe device per zone I almost never have to run it anymore and no you don’t need to run it when restarting the AlarmServer, you only would run it if your zones get out of whack.
Also those grey “? DSC Integration” messages are normal because every zone event HAS to come through that SmartApp via it’s REST API which in turn sends every zone command to the corresponding device. You can’t turn that off, it’s a Smartthings thing… 
Open zone1:
curl https://graph.api.smartthings.com/api/smartapps/installations/your-app-ID/panel/609/1?access_token=your_access_token
Close zone1:
curl https://graph.api.smartthings.com/api/smartapps/installations/your-app-ID/panel/610/1?access_token=your_access_token
Partition1 not ready:
curl https://graph.api.smartthings.com/api/smartapps/installations/your-app-ID/panel/651/1?access_token=your_access_token
Partition1 ready:
curl https://graph.api.smartthings.com/api/smartapps/installations/your-app-ID/panel/650/1?access_token=your_access_token
@sanity Thanks so much for your ongoing help. I have a question for those of us whose smoke alarm runs through their security panel:
Would it be possible to modify the device type for “DSC Zone” so it reflects that this is a smoke alarm instead of a traditional contact sensor? The terminology of “open/closed” makes plenty of sense for doors and windows, but these terms don’t make a lot of sense when used with a smoke alarm. We’re also not able to use the smoke alarm as the correct device type in other smartapps (like triggering a notification if the smoke alarm “zone” is “open”). I assume the device type would need the correct capabilities added. Thanks for your guidance!
Best,
Matt
@mbial not a problem at all, I see DSC codes 631 and 632 map to Smoke alarm and Smoke restore respectively.
I can create a new device type based off the existing ones and update the fields to map properly to what Smartthings considers a “smoke” device. I actually have a 2 (or 4, I can’t remember) smoke detector in a box I need to hook up to my system and can use that for testing.
Give me a day or so…
@mbial Actually when I went to look at my repo copy I already had a DSC Zone Smoke file ready to go, I just forgot to commit it for some reason. I think I was adding it a few weeks back and never finished it.
Anyway it’s in there now along with support for those 2 previously mentioned DSC events.
Pull a fresh copy from my repo of the Smartapp and the new DSCZoneSmoke device type and let me know if it works as I have not tested it at all.
OK - I updated the DSC Integration SmartApp and added the DSCZoneSmoke device type. After updating the device to the new device type everything appears to be working properly from what I can tell. I was able to create a push notification in the event that the smoke alarm goes off (and when it’s all-clear). Thanks again for all you’ve done for this community. Please see the attached photos below.
Best,
Matt
Any chance we can get a Glass Breakage device type created in addition to the Smoke devices?
Your post says " so once I get this figured out, I’ll be happy to write “n00b friendly” instructions to getting this working." … Did you figure it out and did you document it from scratch??? I am struggling to even understand how to install alarm server – I understood all the other part of how to create device and smart apps etc on smart things developers portal. Any help?