DSC -> EVL-3(4) -> Alarmserver -> Smartthings

I’m having issues as well. With the prior code version (from Oct 2020) everything was working well. I noticed today that new versions were available so I upgraded to the newest Smart App and device handlers as well as the newest alarmserver code.

First thing I noticed is that in the smartapp the STHM sync option is now gone.

I’ve also noticed that any attempts to do ‘arm stay’ fails - when using the DSC Stay Panel on/off button, it just hangs and eventually returns “A network or server error occurred. Try again later” from Smartthings.

Using the DSC Away Panel on/off works - both both arm and disarm though the api error is generated in the alarm server log on disarm even though it appears to succeed in the app and the physical panel: 2021-04-07 22:56:23 => System Error 023 = API System Not Armed (sent in response to a disarm command)

I also tried doing a partition command for arm stay from both the stay and away panel and while each showed the partition status as being in away stay, the actual alarm did not enter that mode and no log sent to the alarmserver log.

I tested several of the partition commands and these are the commands that appear to not be working or at least did not send anything to the alarmserver log.

  • DSC Stay Panel (on/off)
  • Arm Stay
  • Bypass

I did not test any of the ‘Key’ or Arm Instant or Arm Night modes as I don’t have any of those implemented.

For now I’ve reverted the smartapps, DTH and alarm server code back to the archived Oct 26, 2020 code from Github and all is working again.

Sounds like similar issues to me after I upgraded

1 Like

First thing I noticed is that in the smartapp the STHM sync option is now gone.

I removed it as it did not do anything in the new ST app; the new ST app does not allow the syncing of the STHM. The classic app did allow this with the SHM.

I’ve also noticed that any attempts to do ‘arm stay’ fails - when using the DSC Stay Panel on/off >button, it just hangs and eventually returns “A network or server error occurred. Try again later” from >Smartthings.

I cannot replicate this at all. It works fine from my end (Android ST app). Are you on an iOS device?

Using the DSC Away Panel on/off works - both both arm and disarm though the api error is generated >in the alarm server log on disarm even though it appears to succeed in the app and the physical panel: >2021-04-07 22:56:23 => System Error 023 = API System Not Armed (sent in response to a disarm >command)

This Alarmserver error is stating that it attempted to disarm the security system, but it was not in an armed state. It caused by Having both a DSC Away and DSC Stay devices, and both will respond independently. It doesn’t make any difference or harm to the system.

I also tried doing a partition command for arm stay from both the stay and away panel and while each >showed the partition status as being in away stay, the actual alarm did not enter that mode and no log >sent to the alarmserver log.

Again, works perfectly fine on my side of things.

I was going to ask if you could send me IDE logs for the DSC devices and the SmartApp, but since you reverted back to what works for you, then don’t worry about it.

I have ios. Still having problems I listed earlier. And now reverting back to the Oct 2020 version of DTH and smartapp did not solve it. So now I’m on the latest version and just dealing with these new loop/race issues

Hi Nathan - Following up on your thought on using Containers. I’ve looked at it more closely and the biggest problem I see right now is that Raspberry Pi buster images are (surprisingly) not available right now as a docker image. There are old images for Stretch and Jessie and I tried loading them, but they appear to be only subsets of the full OS, missing some of the networking functions I need, for example. I also tried the official Debian buster image, which does exist, but of course doesn’t include the Raspberry Pi mods. But alas again it doesn’t have some of the networking functions I need (e.g. dhcpcd). Maybe I’m missing something…

So to do this would require a complete from-the-ground up build of a Buster docker image to begin, and I don’t think I’m up to that task right now! If you have any other thoughts, let me know. I haven’t given up entirely; when I get some more time I’ll experiment some more.

RE: Direct-connect version of alarmserver setup

Hi all - I’ve posted here previously regarding this subject, so wanted to provide this update:

I now have a github repository with all required files to implement alarmserver with direct-connected devices: https://github.com/toddaustin07/DC_alarmserver

Read through the README first to decide whether or not this is something you want to try. No one else has tested this yet besides me, so please be patient if you have any issues. It’s working great for me, but we all know how that goes…

If you have a problem, question or suggestion, please open an issue on github and I will promptly respond and work with you feverishly to get it resolved!

You get a bonus alarm system GUI you can optionally use on your PI!:

Hoping someone can help with this: I had everything installed in 2017 and worked great. Then had a SD card crash and lost the code for the Alarmserver. Now trying to set up everything again…tough to remember from 2017.

Anyway, installed the RPi and have alarmserver.py running without issue. Only problem I have is that I’m missing something somewhere for the devices. I only want STAY, AWAY and MOTION. I created the device handlers by copying the code and creating the handlers in the ST IDE. Then, went into My Devices and created 3 new switches using the device handler info in the “TYPE” drop down box.

The network ID is set to DSC_AWAY for example. I’m thinking that may be the issue but can’t find a post to figure out what the correct value is. Also, I have the following in the alarmserver.cfg file:

name=DSC Zone 01 Doors
type=contact
[zone2]
name=DSC Zone 02 Windows
type=contact
[zone3]
name=DSC Zone 03 Motion Sensor
type=motion

Any help would be appreciated!
Chet

Just realized that I have to set the zones for my system. Do I do this manually or is there a way to pull this off of the app or ENV???

Thanks

You have to do it manually in the .cfg file. There is no way to pull all the required info from the Envisalink device. Here is an example:

[zone1]
name=DSC-Master Bedroom Motion
type=motion
[zone2]
name=DSC-Foyer Motion
type=motion
[zone3]
name=DSC-Upstairs Motion
type=motion
[zone4]
name=DSC-Basement Motion
type=motion
[zone5]
name=DSC-Master Bedroom Glass
type=motion
[zone8]
name=DSC-Sump Pump
type=water
[zone9]
name=DSC-Small Garage Door
type=contact

Thanks – I will do that today. Much appreciated!

For the Network ID for each device (in the IDE), is there something specific it should be or does it matter?

Thank again,
Chet

Those sensor and partition devices will ve created automatically by the smartapp once the INI file is setup correctly and logs into the EVL the first time. You generally don’t mess with the devices directly in the IDE.

If youre rebuilding /reinstalling from scratch (which is how I would do it) you may need to delete existing sensor /partition devices.

Thanks for the help.

So in the alamrserver.cfg file, I would need to set up all the partitions right? I have 10 partitions in the house so if I set those up, the devices will be automatically created?

I will go ahead and delete the devices from the IDE if that is what you’re saying.

Thanks so much!

Chet

1 Like

Partitions? or Zones? (I’d expect 1 or 2 partitions, and between 1-64 zones) Both get created on first run when the smartapp logs into the EVL if your .ini file is correct.

Yes – I meant zones.

Wouldn’t there be only 1 partition if it’s one alarm system? Not sure what a partition refers to

It’s an independent unit in your alarm that can be controlled independently. If you have multiple partitions in your system you generally will know it.

Thomas - I’m having the exact same issues. Got everything installed and have the network error after the Arm Stay hangs for a while.

I tried and tried with the newer version but couldn’t get past the network error.

So, ended up deleting everything and reinstalling the original LXXero version from 2017 and everything works perfectly now.

Would like to upgrade to the newer rtorch version but since it keeps hanging at the same point you mention, this is a decent fix for me.

One last thing — having a lot of trouble getting alarmserver to run automatically at bootup.

I’ve tried editing the rc.local file as well as the .bashrch method.

when checking if alarmserver.py is running (by typing: ps -fA | grep python), I don’t see the py file running.

Any ideas?

Anyone have the newer version working properly in iOS?
Also, what about having this in a docker container using docker-compose?

@rtorch I finally had some time to come back to this. I went ahead and reupgraded all of the components to the new versions and still was facing some weird issues.

This time though, I decided to modify the alarmserver.cfg to remove the stay panel since it was the only one giving me an obvious and repeatable problem at the time (also removed it from any automations). Started alarm server and it automatically removed from IDE and the app as expected. Then I added it back to the cfg file and restart to have it recreated. bam… arm and disarm just like it is supposed to. I did the same steps for the away panel and that one now seems to be working properly too.

All seems to be working for me now in the new code. looks like some weird code gremlins in my system that did not upgrade properly on the panels.

Thanks again for all of your hard work on this and keeping it going.

1 Like

New Edge driver now available for testing:

3 Likes