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

you need to install the requests module using “pip install requests”

1 Like

Any more info can you provide? From what you posted it seems like the connection is lost and then cannot be re-established by AlarmServer to either ST or EVL device.

Thanks for your Reply, what I found is that the Alarmserver stop receiving updates from the Envisalink after 1 or 2 hours of good work. It happens at Alarmserver Level, however the Alarmserver service continues active and running but not receiving updates. It is the same as happened to others in this thread, as in thread 1638 By Mike7 or 1639 by 88Fingerslukee among others. They resolved the issue creating a cronjob to stop and start the alarmserver every certain time. However I consider this as a partial solution as stopping and starting the alarm server every hour open a security breach, while the alarmserver is restarting. I have seen the same behaviour with several users of Alarmserver stopping receiving updates, so maybe the solution could be in the Py code that at certain giving routine look the server is receiving events updates and if not reconnect or something. There is no other error that log shows to amply this info. Thanks

Thanks for your Reply, what I found is that the Alarmserver stop receiving updates from the Envisalink after 1 or 2 hours of good work. It happens at Alarmserver Level, however the Alarmserver service continues active and running but not receiving updates. It is the same as happened to others in this thread, as in thread 1638 By Mike7 or 1639 by 88Fingerslukee among others. They resolved the issue creating a cronjob to stop and start the alarmserver every certain time. However I consider this as a partial solution as stopping and starting the alarm server every hour open a security breach, while the alarmserver is restarting. I have seen the same behaviour with several users of Alarmserver stopping receiving updates, so maybe the solution could be in the Py code that at certain giving routine look the server is receiving events updates and if not reconnect or something. There is no other error that log shows to amply this info. Thanks

I’m just running into this issue. I now have the updated Alarmserver running on my Windows server (thanks for your insight in the previous post… I did end up figuring out that I needed to install the requests module). ST now works with the new instance of Alarmserver.

However, in my household I also have Homebridge running for my iPhones & iPads so the alarm can be controlled in the Homekit app. Previously, I have the homebridge-envisalink plugin running on my homebridge device (raspi4), pointing to the same alarmserver instance as ST. Both platforms worked well and each can control the DSC alarm without issues.

After I upgraded ST and updated the alarmserver to the latest, I’m finding that the homebridge-envisalink doesn’t quite connect with the updated Alarmserver. What version of alarmserver was updated to fix the proxy issue that you spoke about? I’m wondering if this fix will resolve my issue.

I don’t know how homebridge works, and have no experience with it. Do you configure it to connect to the envisalink device directly? If so, you can’t have both it and AlarmServer connect to envisalink. You must use a proxy for one of them (if homebridge allows creation of a proxy).

For developing purposes I’m running two instances of Alarmserver, one on a raspi4, another on my Windows sever. The one on the windows sever connects to the envisalink device and creates a proxy for it.
The version on the raspi4 is configured to not create a proxy, and connects to the proxy on the windows server (configured with the ip of envisalink to point to the windows server ip).

(I hope this makes sense)

I have had this running for hours without any hiccups. You may have to setup homebridge to use alarmserver proxy it creates for the envisalink device. This way everything works correctly.

Do you have your envisalink on a static IP? Does your network/switch have any disconnects? The error you posted is related to alarmserver losing connection to envisalink and/or smartthings. Can you provide more information, logs, etc?

Are you using the latest alarmserver from there?:

My homebridge’s envisalink plugin points to the IP where my alarmserver resides, and my alarmserver connects to the envisalink. But for some reason, after upgrading alarmserver to the latest version, the homebridge envisalink plugin started having problems, which causes the homebridge server to crash out and restart.

I’ve now solve the problem by having two alarmservers running on two separate Windows machines–the new version running on my Windows server, and the old version running on one of my Windows 10 desktops that I keep running 24/7. The new version points to the old version, and the old version points to the Envisalink’s IP. I find for SmartThings, after updating the Smartapp and all the devices, it works best with the new version (3.8). But the homebridge-envisalink plugin works better with the old version (2.7). For now, I’ll keep it running like this as it seems fairly stable now.

Request to Ralph - “Keeper of Alarmserver” :grin:

I would like 2 new functions added:

  1. A way to request and receive the memory state. This is an important function needed - when an alarm goes off, you need to be able to inspect which zone(s) caused it, and this could be displayed on the panel details. Ideally we need a new rest API like /api/alarm/memory to request it, and then an update from alarmserver similar to the ‘bypass’ callback that would send a json with all the zones and their memory states.

  2. Currently there is a ‘Program’ API /api/pgm that implements a *7; I’m not sure if anyone actually uses that… What would be more useful (to me anyway) is an API for *6. Specifically I want to be able to set the time/date which is a pain to have to do 2x a year with DST changes. Would love to be able to automate this through alarmserver. An alternative is to implement a specific /api/timedate API to do this, although a generic *6 API would gives access to a number of other functions accessed through *6 (auto-arm, system test, etc.)

Your thoughts? Anyone else have opinions?

Interesting: with the Envisalink board, I don’t have to change time to/from DST. Perhaps it’s just because it have it connected to the free Eyez-On account.

1 Like

Yes I suppose it must be Eyez-On keeping your time updated. Nice!

Interesting about having to set your time. I have 2 Envisalinks (office and home), neither one monitored by Eyez-On, and both keep the time correctly.

Anyways, I did look at the docs briefly and this should be easily to add a rest api for setting the time/date. Something like /api/setclock
With the *6, I figure, what if I implemented a /api/raw so that you could just send any raw code sequences to envisalink, like if you were entering the sequence at a panel? This way you could really do anything. Of course this would come with a warning of “don’t use unless you know what you are doing”.

For the memory state, doing a call to /api should return the last state of all zones and partitions last I looked at this part of the code. I guessing this is what you mean by the memory state?

I’ve also been thinking of maybe adding some type of security to alarmserver. As it is, if it every get exposed to the internet, it becomes wide open for obuse.

It’s the DSC keypad that needs the time updated, but you got me wondering if there is a configuration I’m missing on the Envisalink that might take care of that. Let me explore that , and the /api call to get the last state of zone and partitions. I haven’t tried that one. The specific function I’m looking for is the *3 alarm memory function, but maybe it’s included in the /api result. I’ll experiment.

Thanks!

If anyone is interested, I have alarmserver zones now fully functional as Raspberry Pi-based direct-connected devices, along with new ST custom capabilities. I’ve had it running for a couple weeks now and have replaced my IDE/groovy-based stuff. No changes to alarmserver itself other than a config file setting. Only one panel device is needed to cover both stay and away actions and states, so when the new automations engine is working, things should be more straight forward. I’ve also created a ‘bonus’ GUI-based DSC panel that is integrated in so you can have full control of your DSC alarm system from your Pi desktop.

I haven’t packaged this up into a turnkey solution since I’m not sure how many people will be interested in going down this road, but I’m more than willing to handhold anyone through the setup. Pre-requisite is that you’ve installed my RPI setup package for direct connected devices. And by the way, I’ve recently added a Python API wrapper option to that package, in case the C language requirement was a concern.

1 Like

Ping me offline and we can discuss the steps…

This was one of my first custom codes and it was a complete BEAR!! It literally took me 2 weeks to get it up and running. Once I became more familiar with ST and the IDE and Linux, I realized just how simple this was. Saying all that, this has been working since 2016 and I am so scared to break it but I am very intrigued by your work.

Sooooo…I am going to give it a go!

2 Likes

I wish I could say this will be easier, but there are a number of steps involved and it may seem a bit daunting as well, but I’m here if you need help.

The only change to alarmserver is a minor one in its config file, so it will be simple enough to revert back if needed. All new devices on the mobile app, so you won’t touch your existing setup.

The benefit of all the effort is that you’ll be free of the IDE, DTHs, and Groovy, and no need for a SmartApp for alarmserver. Beyond that, you can then write your own device apps to run on your own Pi to do just about anything you want.

Make sure you have a Pi model 3 or later, upgrade it to the latest O/S (Raspbian Buster) and get yourself a Developer Workspace account.

So - looking at the instructions this afternoon, but my immediate thoughts go to - couldn’t we just build the whole shebang including appropriate versions of Python, the SmartThings directConnect, AlarmServer and such into a Docker Container?

Possibly! I thought about eliminating the core SDK pre-req altogether and just providing the executables, but not sure how portable that would be across OS versions and Pi models. The one catch is the need to generate device serial numbers and device QR codes (for onboarding) using a couple SDK tools, but they’re just python scripts, so that could probably be easily packaged up without the rest of the SDK. In fact those tools are the only reason for the Python pre-req at all.

If you have experience in this area, let’s work together to explore that option. I’d say go ahead and install as-is and get a feel for all the elements, then it might become obvious what the possibilities are regarding containers, or generally simplifying things.

I appreciate the fact that many if not most alarmserver users just want the thing installed and working, and may not be interested in any further device app development, therefore no need or interest in all the SDK gorp.

1 Like

I’ve started to write down some README info that you might find useful: DC_alarmserver/README.md at main · toddaustin07/DC_alarmserver · GitHub

Also new news: automations is evidently starting to work now for custom capabilities, so that’s positive and I can make sure my device configs are fully functional in that respect.