[OBSOLETE] DSC -> EVL-3(4) -> Alarmserver -> Smartthings

I had half a post typed up as a draft and accidentally posted it at 2 a.m. from my phone while I was sleepily browsing this thread from my phone. I saw it when I woke up this morning and removed it. Sorry about that, haha!

I thought I had done everything correctly, but no matter what I did, the DSC devices would not show up in my Smartthings app. I screwed around with it numerous times last night and decided I would just delete everything in the Smartthings IDE and start fresh. While doing that, I discovered my problem and figured I’d post it here in case someone else runs into that issue. When I was copying and pasting the myURL base from my email, I was right-clicking and selecting “Copy Link Address” and pasting that into the alarmserver.cfg file not realizing that it was not carrying over the port from the URL. So instead of getting https://graph-na04-useast2.api.smartthings.com:443/api/smartapps/installations, I was actually getting https://graph-na04-useast2.api.smartthings.com/api/smartapps/installations, and I totally passed over it while trying to do my rudimentary debugging.

There were also a couple of things that I found confusing about the process that I’m putting here in case anyone else has the same questions I did:

  1. To add the device handlers, you need to go to the “Device Handlers” tab in the Smartthings IDE. You’d think that would be apparent based on the name of the device you’re adding, but that totally slipped past me in my haste to get things up and running. I ended up adding four Smartthings Apps in the IDE the first time.

  2. The OAuth app id and access token from the app that you install on your phone (Step 3 in the ###Smartapp Setup section of the Readme file) does not match the one you see in the IDE when you publish. You have to use the one you see on your phone.

  3. If you setup the phone app to send you alerts for “all” events, your phone will sound like a slot machine that hit a jackpot when once you start the alarmserver app on your Pi, haha.

This app is really cool. Thanks to everyone that has worked on it!

Port 443 is the default port for https anyway, so whether you specify the port or not shoundn’t have really mattered, strange, I’d sooner suspect maybe some strange/special characters got pasted in that weren’t visible to a normal text editor. We’ve seen similar issues with corrupt config files before - especially when people are transferring files around from windows to linux or what not.

I did confirm this - i am not using 443 in my config at all - even though the app shows that, and it’s working just fine. I suspect you might have had corrupt characters or something hidden in your config file that you couldn’t see with a basic text editor.

1 Like

nevermind, i’m an idiot…

Got it fully operational, now on to webCore scripts!

Weird problem with closing - it seems that alarm doesn’t distinguish between Stay and Away arming mode. Here’s the alarmserver log. It seems that it sends all the correct codes, but always receives “armed away” response:

arming away

2017-10-08 13:28:24 Web request: GET /api/alarm/arm?part=1
2017-10-08 13:28:24 TX > 0301C4 ### correct code 030 here
2017-10-08 13:28:24 RX < 500 - 030 - Command Acknowledge
2017-10-08 13:28:25 RX < 510 - 83 - Keypad Led State - Partition 1
2017-10-08 13:28:25 myURL: …
2017-10-08 13:28:26 RX < 656 - 1 - Partition Home Exit Delay in Progress
2017-10-08 13:28:26 myURL: …
2017-10-08 13:29:24 RX < 510 - 82 - Keypad Led State - Partition 1
2017-10-08 13:29:24 myURL: …
2017-10-08 13:29:25 RX < 701 - 1 - Partition Home Special Closing
2017-10-08 13:29:25 RX < 652 - 10 - Partition Home Armed Mode Away

last line - correct code 652 - 10, i.e. armed away

Now, arming Stay

2017-10-08 13:24:39 Web request: GET /api/alarm/stayarm?part=1
2017-10-08 13:24:39 TX > 0311C5 ### correct code 031 here
2017-10-08 13:24:39 RX < 500 - 031 - Command Acknowledge
2017-10-08 13:24:40 RX < 510 - 83 - Keypad Led State - Partition 1
2017-10-08 13:24:40 myURL: …
2017-10-08 13:24:40 RX < 656 - 1 - Partition Home Exit Delay in Progress
2017-10-08 13:24:40 myURL: …
2017-10-08 13:26:39 RX < 510 - 82 - Keypad Led State - Partition 1
2017-10-08 13:26:39 myURL: …
2017-10-08 13:26:40 RX < 701 - 1 - Partition Home Special Closing
2017-10-08 13:26:40 RX < 652 - 10 - Partition Home Armed Mode Away

I would expect last line to read RX < 652 - 11

Figured it out, basically one of the forum links at the top describes similar situation, when there’s no bypass zones, and DSC in its infinite wisdom ignores away/stay mode in that case. I made a slight modification to the alarmserver.py, remembering 30 or 31 command as closecommand, and checking for it when 652, i.e. current close status is received. So if 652 is received as armed and away, but closecommand was ‘stay’ then I set the status to stay, otherwise default it to away.

One case where it wouldn’t work is if the alarm is in the stay mode, and the server was restarted.

is there a reason you’re trying to make the stay mode work even though it doesn’t do anything? doing this change in alarmserver is definitely not where I’d prefer to do it, and this would mean the DSC Stay/Away devices will be displaying an invalid alarm state that doesn’t really match the true state of the DSC panel, so more than anything I’d like to find a better way to implement what you’re trying to achieve without hacking it in there, possibly through the smartapp instead, if it’s even a necessary change at all? I could probably have the last stay/away command state stored in the smartapp instead, that would mean it would be resistant to alarmserver reboots, but I guess i’m trying to figure out why you need this feature? Like is it actually buying you something other than making something that doesn’t work seem like it works?

There’s already a preference in the smartapp to turn off the SMH sync stuff for this situation, as it doesn’t really work right if you don’t have any bypass zones as you mentioned previously. On top of that, I don’t think you’d have any way to set stay mode from the physical DSC panel as I think it will just not arm stay, but I could be wrong - that’d be worth checking anyway. Can you confirm if arming “stay” from the physical DSC panel actually sends Stay when you don’t have any bypass zones? That might be justification for this, anyway. Otherwise, the existing smartapp preference may be all you need? Just wanted to make sure you didn’t miss that before we dig further into anything.

DSC panel doesn’t distinguish away from stay if there are no motion/interior zones defined.

I found a better way to get rid of the URL in the log… When commenting out the lines in alarmserver.py I noticed that there was a reference to a setting in the config file to hide the log entry…

## Log URL requests
## By default all the url requests are logged. These happen every 5
## seconds with the web ui’s. To disable all these set this to False
logurlrequests=False

Setting the above to FALSE will get rid of all the annoyingly long myURL print out in the log.

Just sharing in case there are others bothered by it.

1 Like

wow you would think i should know that lol. Hahaha. Truth be told, that’s part of the code I didn’t write.

I think I’m finally 99% of the way there, haha. The last little bit of figuring out I need to do is why the SHM sporadically reports the wrong status.

On a related note, does anyone have a tweak that will make SHM or the “My Home” show an accurate mode when the connection to the Alarmserver is down? Both will show a status for my “things” (e.g. panels and contacts) if the Alarmserver app is not running or if the Pi is down. Is there a way to change that so that it shows “Unknown” if the app isn’t reporting to Smartthings?

My last resolved aggravation (yay!) was finally getting the Alarmserver script to start at boot. I’m using my old Pi for a webserver running Tiny RSS, so I didn’t want to bog it down with another application. I went ahead and ponied up the cash for a new Pi 3, which is running Raspbian Stretch. I’m reading that there were some changes in Wheezy and possibly more in Stretch, that affect how the Pi boot order is done, so nothing I did with the RC.Local or Screen instructions from this thread (or elsewhere on the web) would get it to run at start-up.

I finally found a method that worked–using systemd to run a service. I thought I’d dump my steps here in case it’s helpful for anyone else that was in my position.

Here’s the site with the details: https://www.raspberrypi-spy.co.uk/2015/10/how-to-autorun-a-python-script-on-boot-using-systemd/

You create the alarmserver.service:

sudo nano /lib/systemd/system/alarmserver.service

The contents should look like this:

[Unit]
Description=Alarm Startup Script
After=multi-user.target

[Service]
Type=idle
ExecStart=/usr/bin/python /home/pi/alarmserver/alarmserver.py -c /home/pi/alarmserver/alarmserver.cfg

[Install]
WantedBy=multi-user.target

Save it and then change permissions

sudo chmod 664 /lib/systemd/system/alarmserver.service

Then you need to reload and enable:

sudo systemctl daemon-reload 
sudo systemctl enable alarmserver.service 

And then reboot.

Once it reboots, you can check status by using sudo systemctl status alarmserver.service

You should see something like this:

alarmstart.service - Alarm Startup Script
   Loaded: loaded (/lib/systemd/system/alarmstart.service; enabled; vendor prese
   Active: active (running) since Wed 2017-10-11 16:15:05 CDT; 1min 7s ago
 Main PID: 782 (python)
   CGroup: /system.slice/alarmstart.service
           └─782 /usr/bin/python /home/pi/alarmserver/alarmserver.py -c /home/pi
1 Like

you should probably add some user=pi stuff in there unless you want it running as root…but that’s just me. I do have a systemd script that uses screen that i have in the git repo - although that was more for my own legacy reasons for using screen, I was trying to gather logs, but with systemd i can use journalctl to get the same logs so it probably doesn’t really need screen anymore hah…The other issue is, we aren’t installing alarmserver to a standard location right now so it’s hard for me to make any notion of a standardized init-script in terms of the paths and username and such.

and if shm is reporting the wrong status you may have the same issue that we are talking about above where if you dont have any bypass zones, you essentially don’t have a stay mode - which messes with the DSC->SHM sync stuff, so there’s an option in the smartapp to turn off that sync

My recently updated pi3 died (hardware fault) so I decided to replicate my AlarmServer on an Odroid C2 running Ubuntu 16.04 lts. I am a Linux novice so I am having a hard time setting the server to start automatically. Based on what I read I can no longer use the rc.local method I was using on my pi3 as it was obsoleted in favor of systemd.

I have the Odroid configured to automatically login to CLI as root as I am not concerned about security issues in this project.

I have a 5 inch LCD hooked up via HDMI so that I can display the AlarmServer log on screen to know it is working (this SBC is installed in my alarm panel) and just because it looks cool :wink:

I use screen to enable showing the log on screen but also on remote SSH sessions. When I connect I am prompted whether I just want a regular CLI prompt or to connect to the screen session so that I can use the SBC for other things as well.

ISSUE: The issue I am having is that I am unable to get the alarmserver service to start automatically. It appears that something is not ready when it tries starting it so it fails. When I connect to SSH as soon as I am allowed and try to run the service manually it does not start a screen session however if I give it a tiny bit more time, then I am able to start the server and connect to the session.

I followed all instructions I could find in this thread and did my own testing. The service gile I posted below is what seems to work except it doesn’t start on its own:

Unit]
Description=screen
After=network-online.target
After=multi-user.target

[Service]
Type=forking
User=root
ExecStart=/usr/bin/screen -dm -S alarm /opt/alarmserver/alarmserver.py -c /opt/alarmserver/alarmserver.cfg
ExecStop=/usr/bin/screen -S alarm -X quit

[Install]
WantedBy=multi-user.target

I am not sure what “After=multi-user.target” does but I was looking for anything that would delay the start of the service. I read that Type=idle would do that or at least wait 5s but it doesn’t seem to work as I can no longer start the service manually if I change it to “idle”.

I’d appreciate any suggestions…

will this setup replicate to honeywell->EVL->AS->ST ???

How did you change the location on the smartapp? I have the same issue cannot arm/disarm from the smartapp and my locations is blank, I can find anywhere on the smartapp IDE to change the location.

no this won’t do honeywell unfortunately, there are other versions of this that do, but they may not have been updated/maintained in the ways that this one has.

This version is tailored specifically to try and incorporate as many of the DSC panel features as possible, and in that process it’s likely become a bit overly specific to the DSC+EVL3/4 combination. Though some of the upgrades I’ve made - like using JSON for the AS->ST communication instead of basic URLs, would actually allow the smartapp to become more generic and less speciifc to one or the other, given some work that is, but ultimately, there’s still a lot of differences and it would still become 2 separate alarmserver projects to maintain all that, although speaking collaboratively, I’d be open to standardizing the smartapp on some kind of json format that can cover all the EVL-supported alarm systems, but I don’t think I could take on re-writing the honeywell alarmserver portion as i just dont have the time nor any honeywell panels to test it with.

1 Like

I followed https://github.com/LXXero/DSCAlarm guide to setup alarmserver and smartapps. When I run alarmserver, the DSC simple stay/away panels and the zones devices were automatically created and reporting status fine, but I couldnt use the DSC simple stay/away panels to arm the system. On the device handler event log, it says the command stay/away sent to alarmserver successfully, but on the alarmserver I only see code 615 (ping test) and it returns Evnisalink Zone Timer Dump.

the http://192.168.2.xx:8111/api/alarm/stayarm does work.

The devices that were created automatically did not assign to any hub, I tried manually recreate them and assigned to my hub but it did not work, just keep reporting “alarming” state.

Anyone have any ideas?

did you set the IP address to your alarmserver in the smartapp settings?

arrag silly me, I put in the EVL IP, I knew I did something stupid.
But now I getting authentication fail:

2017-10-13 00:58:39 Incoming proxy connection from (‘192.168.2.152’, 44266)
2017-10-13 00:58:39 PROXY REQ < GET /api/alarm/stayarm?part=1 HTTP/1.1
2017-10-13 00:58:39 Proxy User Authentication failed
2017-10-13 00:58:39 PROXY REQ < Accept: /
2017-10-13 00:58:39 Proxy User Authentication failed
2017-10-13 00:58:39 PROXY REQ < User-Agent: Linux UPnP/1.0 SmartThings
2017-10-13 00:58:39 Proxy User Authentication failed
2017-10-13 00:58:39 PROXY REQ < HOST: 192.168.2.55:4025
2017-10-13 00:58:39 Proxy User Authentication failed
2017-10-13 00:58:39 PROXY REQ <
2017-10-13 00:58:39 Proxy User Authentication failed

192.168.2.55 is the alarmserver, I have not change the evl password, it should be the default password user. Is the proxy password different from the login password? I tried putting enableproxy=false, then it just wont do anything.