Alright, will try this when I get home tonight and report back. Thanks a lot. 
No worries
I’m not sure if what I suggested will help, but it’s worth a shot. My first instinct would be that the SmartApp/Device Handler doesn’t read that bypass is enabled yet, so it reprocesses the command. Dunno.
If that doesn’t work, I’ll give zone bypass a shot on my Brother’s system.
honestly it still seemed like some sort of sporadic double-button-press or the command being sent twice, maybe even some kind of network packet duplication. I mean i’ve seen weirder. A while ago I was helping one guy with some alarmserver issues and he had a type of wifi smart lightbulbs that were interfering with his entire network - I had him do a TCP dump and stuff that was supposed to be alarmserver traffic was like clearly crazy traffic from his lightbulb. Needless to say, once you start adding all these devices, you never know when you might get the occasional bug
I really have to sniff those packets. I was supposed to do so but I run Alarmserver on Windows and packet sniffing seems a lot more of a PITA than on linux.
Can the duplicated command be somehow related to the OS?
haha sadly it’s not even that smart. alarmserver has no idea if a zone is bypassed or not, as it doesn’t keep any sort of state like that, only the smartapp has any notion of the bypass states, but this is only used for the autobypass feature which just generates a list of open, unbypassed zones and sends it to the alarmserver bypass URL.
All alarmserver knows how to do is toggle it, and if you’re lucky, whatever you’re toggling will trigger the EVL to send a status update afterwards with what you did.
Which brings us to another fun issue, it doesn’t send the status update all the time, only after certain commands, and I actually force it to send the updates in a few places by sending *1# or something like. This is just how the EVL is setup - they added the feature to send the bypass status recently, and I wrote the function to decode the binary format that it’s in and send it tot he smartapp, but it’s still kinda weird. One remaining known issue is that it doesn’t always send these status updates when a zone is bypassed on a partition other than partition #1, although it should be possible to maybe force it to by hitting the refresh button. Totally seems like an EVL bug though, as it’s the EVL that isn’t sending it out.
Almost nothing is very smart with these panels - nearly all the commands are just toggles, and the only way to see what you toggled is to check the status it sends after it’s toggled. so the status isn’t really used to trigger things one way or another - it just sends the toggle, then gets a status update from the EVL afterwards saying “I’m in this state”.
From the logs he sent before, it was acting like the button was pressed twice, like someone hit the button in the smart app twice. like as if the bypass URL was hit twice by the hub when he pressed the button in the device panel. That’s kind of why it’s been baffling to me, as alarmserver is basically doing what it should be doing if the URL was hit twice like that.
Very interesting. Doesn’t surprise me about the stateless config of these devices, after all, they’re on simple PCB.
I’m definitely inclined to agree. However, what if he did adjust the sleep to say 7 sec after bypass? Theoretically, that would be a messy fix, but I’d assume that it would prevent the re-sending of the toggle command? Not a fan of that, by any means, but if it is something in his network, it could be worth a shot.
Wireshark is a great packet sniffer for Windows. Works pretty simple and has very powerful filter features.
I use it fairly frequently since I work in IT, so it’s a great resource to have around.
It definately look and feel like this but as you can imagine, I made sure I was not double-tapping 
Thanks, will use it to collect data before trying to modify alarmserver as you suggested.
I think it would just delay the 2nd command send by 7 seconds, but i’m not sure it’d actually fix the issue.
Excellent Point. Hope we get it either way.
So I’m not a technical person but I REALLY want to integrate my DSC/Envisalink into my SmartThings.
My question is what do I need to do to get the alarmserver cfg onto my imac where it will run as the server? I see the changes I need to make to the cfg file for it but where are the steps to run it? Again, sorry for missing the obvious and I appreciate your patience with me.
Thank you everyone for the work and information you put together in this thread! I had one of the first AlarmServers running for 3 years on my RPI3 but a few days ago that install died so I figured I would adopt more recent, and supported, code. I have installed and configured everything but I cannot verify whether things are working until I return home. One thing that caught my attention is that the log is full of “myURL” messages making it nearly impossible to read. I reviewed >700 posts in this thread and have not seen similar logs with so many instances of the same URL appearing so I must assume there is something broken in my setup.
Just in case it matters… I have a RPI3 in my Alarm Panel that shows the log output on its LCD and when I connect to it via SSH I am offered the possibility to view what is going on (screen) or to simply go to the command prompt. Below is the output that I get with the ID and Secret blanked out.
Using username "pi".
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Oct 2 12:53:33 2017
Do you want to connect to AlarmServer screen session?
1) Yes
2) No
#? 1
/api/smartapps/installations/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx|
xxxxx/update?access_token=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx|
xx |
2017-10-02 12:54:04 RX < 840 - 1 - Partition Home Trouble LE|
D ON |
2017-10-02 12:54:04 myURL: https://graph.api.smartthings.com|
/api/smartapps/installations/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx|
xxxxx/update?access_token=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx|
xx |
2017-10-02 12:55:05 RX < 511 - 10 - Keypad Led Flash State -|
Partition 1 |
2017-10-02 12:55:05 myURL: https://graph.api.smartthings.com|
/api/smartapps/installations/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx|
xxxxx/update?access_token=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx|
xx |
2017-10-02 12:55:07 RX < 849 - 01 - Verbose Trouble Status |
2017-10-02 12:55:07 RX < 510 - 80 - Keypad Led State - Parti|
tion 1 |
2017-10-02 12:55:07 myURL: https://graph.api.smartthings.com|
/api/smartapps/installations/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx|
xxxxx/update?access_token=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx|
xx |
2017-10-02 12:55:08 RX < 511 - 00 - Keypad Led Flash State -|
Partition 1 |
2017-10-02 12:55:08 myURL: https://graph.api.smartthings.com|
/api/smartapps/installations/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx|
xxxxx/update?access_token=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx|
xx |
2017-10-02 12:55:09 RX < 510 - 90 - Keypad Led State - Parti|
tion 1 |
2017-10-02 12:55:09 myURL: https://graph.api.smartthings.com|
/api/smartapps/installations/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx|
xxxxx/update?access_token=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx|
xx |
2017-10-02 12:55:10 RX < 651 - 1 - Partition Home Not Ready |
2017-10-02 12:55:10 myURL: https://graph.api.smartthings.com|
/api/smartapps/installations/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxx|
xxxxx/update?access_token=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx|
xx |
|
------------------------------------------------------------are you actually having a problem or are you just assuming it is one? They aren’t technically “the same” url - they have JSON post data in them that differs. However this is what the log normally looks like…if you were using a 3 year old version you may have been using one of the ones that used different URLs for each action - but that had to be done away with once we added more functionality, now most data is transfered via JSON, not via the URL itself. However the URL shown is still communicating the correct actions to the smartapp.
you’d need an installation of python2.7 to make alarmserver work on a mac.
@xero - it seems to be working but I did not get much of a chance to test it. What puzzles me is that the URL that appears is always the same and without any arguements:
Given I use a 3.5 inch LCD screen to show the log, the super log URL now makes it pointless as it prints out constantly and uses up 4 lines.
Do you confirm this is intended functionality? If so, what is the purpose of printing the same thing over and over? Just asking to understand… I do appreciate you sharing your work.
It’s the line before the URL that is more important, the URL itself is just indicating that the command was sent. I’m sure you could comment out the myURL Line in the code if you dont want it to print that.
1 Like
Were you able to get the packet capture?
Have the most recent commits to the code fixed your issue? I know you were having the 500 error.
I didn’t have much time to go over it in details, however it got me a bit confused. I updated the source from the github and tried to go through the usual steps, i.e. execute 1st url and get the code and then execute 2nd url with all 3 pieces and still got 500.
BUT, I noticed that you referred to the new README, which I briefly skimmed and do I understand it correctly that these URLs are not required anymore to make this whole thing work?
Also I am having hard time to find a detailed step-by-step instructions as to how to install alarmserver - I know I saw it before and even set it up on my synology NAS, but can’t find it again to save my life…
The usual steps are no longer required. getting your AppID and Access_Token can be found in the SmartApp itself on your device. See the bottom section called “Token Info”.
That should solve your previous issues.
The README.md on Github (Which has been updated to reflect the changes) also has step-by-step for installation, from what I could tell. If you’re having issues with these, let me know and I’ll see if I can help.
I tried running tcpdump -i any on my Linux boot but got overwhelmed with data.
Is there a way to reduce what it returns and focus on what you need?
Thanks!
You might try some of these switches. I’ll be honest, I’ve never used TCPdump, but this should be the right path.
EDIT:
Most notable commands include:
SHOW TRAFFIC RELATED TO A SPECIFIC PORT
You can find specific port traffic by using the port option followed by the port number.
# tcpdump port 3389
# tcpdump src port 1025
FILTERING BY SOURCE AND DESTINATION
It’s quite easy to isolate traffic based on either source or destination using src and dst.
# tcpdump src 2.3.4.5
# tcpdump dst 3.4.5.6
FIND TRAFFIC BY IP
One of the most common queries, this will show you traffic from 1.2.3.4, whether it’s the source or the destination.
# tcpdump host 1.2.3.4