@Beedix, @Xero just merged my changes, so look at the official repo 
Wow, awesome. Thanks guys
Thanks again @blacktirion , and yes I did merge them in a few minutes ago! I did check one thing before I merged it - I wanted to see if it’d trash my old tokens or require me to use/generate new tokens - from what I could tell, both the old and the newly generated access tokens both worked, so it seems we’re golden. Otherwise, I’d have wanted to put up a disclaimer saying it might need people to use the newly-generated token, but fortunately, this doesn’t seem to be the case. I hope anyway. Haha. We’ll see if anyone chimes in, but fingers crossed this should be a win-win.
1 Like
Looks good, I got it up and running without problem. The last version of this server I used was from a node.js fork. One thing I noticed that others might run into is that the URL returned contains a trailing slash that must be excluded from the configuration. I pasted it in as is and the server is applying it’s own trailing slash so it was very easy to spot in the log file.
So when you take this part (will be different for you):
“app_url”: “https://graph-na04-useast2.api.smartthings.com:443/api/smartapps/installations/”
Be sure to paste it in like this:
https://graph-na04-useast2.api.smartthings.com:443/api/smartapps/installations
Great job again to @blacktirion and @Xero and of course the original and preceding forks that got us here. I’ve been missing my alarm control since I migrated to a v2 hub and having the 500 error. Slick way to solve it.
Thanks for the Feedback. I’ve modified my fork and made the adjustment for that.
CHANGES MERGED - SEE UPDATED REPO
i got the latest stuff merged in now which fixes that trailing slash issue and added the smartapp label as mentioned, pretty minor change, just tested and upgraded to it now.
I know I should leave well enough alone but I sooooo want to try this! I’ve been recommending this setup for a while now but I know the install was a little rough because of housekeeping issues such as the read me. Now, I think this should be pretty straightforward for most now.
Again, awesome work guys!
Haha, I did look at the TODO list again and I just remembered item #2 is probably super easy to pull off now. Though I do wonder how stable state variables have been in ST lately, I remember a year ago state variable corruption was a real concern…seems like those issues are mostly a thing of the past though.
The next question would be, if alarmserver sends the IP to the app, which IP does it send? Which interface, etc…may still need to specify something somewhere to tell it which IP to send, or I could try to guess which interface is internal based on internal subnets like 192.168.x/172.16.x/10.x/ etc…that’d be easy enough although it feels slightly dirty to just guess.
PDlove’s Homebridge-smartthings did this an interesting way, maybe you could duplicate? It bound to the MAC of the alarmserver, so you declare that once and doesn’t matter after that if the IP changes.
I don’t have an EVL chip. My brother was the one with the chip, but I knew the integration portion for JSON queries was able to be done without one.
oh weird, I’m not sure we’d have a good way to use the MAC address in this case, I’d have to take a look I guess. basically the smartapp needs to know the IP of alarmserver, unless it was gonna try to query via ARP the MAC and get the IP that way - but that seems iffy and would only work over ethernet
Definitely weird,
However I did deduce that his code doesn’t have the MAC query, that’s in the main “homebridge” github. I’m pouring through some of the js to see if I can isolate where the conversion is, but you’re right about only working over LAN. Since WiFi does MAC as well, it should theoretically work, but yeah, kind of iffy.
I noticed he has a “direct_ip” and “direct_port” thing - wonder if it’s just specifying it manually like we are somewhere.
Pulled and updated. Worked fine here as well.
Anybody have a decent FreeBSD rc.d init script for alarmserver? If not, it’s not a big deal but currently alarmserver’s command line checking code doesn’t seem to like additional parameters on the command line which are necessary to daemonize using the traditional mechanisms recommended by freebsd.
Plenty of work arounds…currently I just launch it in a detached screen within a chroot jail. It auto starts and of course starts via the “service dscalarm start” command but I can’t stop it using the service command. I would rarely if ever need to stop it, but doing it will kill or control-c after reattaching to screen doesn’t seem right 
Editing this post as necessary…
index.js file:
function SmartThingsPlatform(log, config) {
this.app_url = config["app_url"];
this.app_id = config["app_id"];
this.access_token = config["access_token"];
this.direct_port = config["direct_port"];
if (!this.direct_port) this.direct_port = 8000;
this.direct_ip = config["direct_ip"];
if (!this.direct_ip) this.direct_ip = smartthing_getIP();
/lib/smartthingsapi.js File…
var smartthings = {
init: function (inURL, inAppID, inAccess_Token) {
var appURL = url.parse(inURL);
app_host = appURL.hostname || "graph.api.smartthings.com";
app_port = appURL.port || "443";
app_path = (appURL.path || "/api/smartapps/installations/") + inAppID + "/";
access_token = inAccess_Token;
},
“~~~~~~~~~~~~”
startDirect: function (callback, myIP, myPort) {
GET({ debug: false, path: 'startDirect/' + myIP + '/' + myPort }, function (data) {
if (callback) { callback(); callback=undefined; };;
})
},
Hope that gives you some ideas
Are you not able to pass the quit command to /usr/bin/screen -S alarmserver -X quit?
Something like this: ( i know that says linux, but I would assume it works the same)
EDIT:
Additionally, you might try this method:
do_stop() {
local result
pidofproc -p "${DAEMON_PID}" "${DAEMON_PATH}" > /dev/null
if [ $? -ne 0 ]; then
log_warning_msg "${DAEMON_NAME} is not started"
result=0
else
log_daemon_msg "Stopping ${DAEMON_DESC}" "${DAEMON_NAME}"
killproc -p "${DAEMON_PID}" "${DAEMON_PATH}"
result=$?
log_end_msg $result
rm "${DAEMON_PID}"
fi
return $result
}
Saw this on: https://www.freebsd.org/doc/en/books/porters-handbook/rc-scripts.html. Don’t know if that will help.
If the script uses an interpreted language like perl, python, or ruby, make certain that command_interpreter is set appropriately, for example, for Perl, by adding PERL=${PERL} to SUB_LIST and using %%PERL%%. Otherwise,
# service name stop
will probably not work properly. See service(8) for more information.You seems to be giving a hand to @Xero lately.
Maybe your fresh eyes would be able to spot what cause this issue : DSC -> EVL-3(4) -> Alarmserver -> Smartthings
Basically, whenever I try to bypass, it does bypass on the physical panel but get auto-reverted back within 1-2 seconds to no bypass.
Thanks mate, any help would be greatly appreciated. Btw, am I the only one having this issue?
I just do what I can in my spare time at work
I’m more familiar with Linux and certain types of code, however I can see If I can help somewhat.
Does the same thing happen when you try to bypass from the Envisalink portal? maybe the SmartApp thinks it’s not turned on?
Have you reinstalled the device handler? ---- Nevermind, just read your thread about that.
Sorry, some of this may not sound helpful, but I don’t own an EVL chip, but my Brother does, so when I’m over next, I’ll give his a test.
I do see a commit on Aug 8th for the main Alarmserver python program about bypass. Have you updated to that yet?
Good morning!
Thanks for your help. Yeah I tried reinstalling the DHT and I have no problem with bypass using the EVL portal or their new app. The issue occur only when using the DSC integration smartapp bypass button.
Alarmserver log seems to be receiving a duplication bypass command, thus “un-bypassing” everything.
I do run the latest version of alarmserver yes.
Very odd.
I see this code and you might make a change to your code to see if it helps with the bypass delay. just to see if we can track it down:
This is “alarmserver.py” about line 686
elif query.path == '/api/alarm/bypass':
try:
zones = str(query_array['zone'][0]).split(',')
for zone in zones:
if str(zone) == '0':
partition = part
else:
partition = str(self._config.ZONES[int(zone)]['partition'])
if len(zone) == 1: zone = '0' + zone
alarmserver_logger("request to bypass zone %s on partition %s" % (zone, partition))
channel.pushok(json.dumps({'response' : 'Request to bypass zone received'}))
self._envisalinkclient.send_command('071', partition + '*1' + str(zone) + '#')
**time.sleep(2)**
Can you change the “Time Sleep” to 30 sec or so?
While that’s in sleep, try processing another command, or see if it ignores everything till the 30 sec are up.