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

You shouldn’t need it… Did you find it in one of the other categories?

-Nathan

Based on my knowledge, I don’t see the Actuator capability with any of the DTHs in the DSC-Envisalink codebase. But again, I’m not very experienced with this and I might be missing something obvious :slight_smile:. Sorry and appreciate a bit more guidance. Thanks!

No worries - just understand - editing a DTH should ALWAYs be last resort.

I just looked - You go into the settings for your WebCoRE install > Available Devices > Capability Group 3 >Which Switches

Enable your panel there. it will show up in webCoRE
(Edit: added screenshots)

Oh wow. I assumed the “Select devices by capability” was a different way of searching that shows the same devices. Thank you for that pointer. Very helpful!

Hi Nathan @nathancu Xero @Xero

I was able to use your information here and connect RPI w EVL4 using alarmservers and also added all DTH and smart app on new ST app. I am getting into an issue that now DSCAWAY and DSCSTAY buttons are always on. If I press them, they try to disarm my alarm but they won’t arm it. Any pointers?

When I do http://192.168.X.X:8111/api/alarm/arm it works fine from laptop browser and also http://192.168.X:x:8111/api/alarm/disarm works fine as well

Quick question for you Ray: the new ST devices you created for alarmserver (contact, motion, smoke, panels, etc) - it looks like those might have been created as custom capabilities based on looking at pizzafiber16443.troubleStatus, pizzafiber16443.zoneBypass, etc. Did you do that yourself? I’m starting to look at how I can use these for the direct-connected device mode, but the Developer Workspace doesn’t let you select capabilities other than the standard ST ones. The documentation claims it will also let you select any custom capabilities you have defined under your own ID, so I want to try that, but I’ll need to re-create those pizzafiber* ones. Are there source files (json, YAML, or whatever it is the CLI uses) you can post to your github that would save me some effort?

Thanks.

Its Ralph, not Ray, but I get different names all the time! (Frank, Paul, etc), so no worries. :rofl:

Let me locate my files and put them online for you; just give me a few days. I’ve moved lots of things on my systems over the past few weeks due to a ransomeware attach on my home server (lost most of my backups and some minor files, but didn’t trust anything so I rebuilt the main server I had :worried:; on the positive side, I needed to update things anyways).

In the SmartApp, did you verify that the correct IP address of alarmserver is entered?

Had a chance to upload the files today:


Hope this helps you out.
1 Like

RALPH - Very sorry for being annoying calling you “Ray”!

But thank you for posting the files. I’ll check them out.

Quick update on my end - I have a all my zones and panel now implemented as direct connect devices talking to alarmserver. Things seem to be humming along nicely. Now with your custom capabilities I can hopefully get the functionality back to where it used to be. I just hope Samsung soon provides a way to use shared custom capabilities, otherwise everyone is going to have to re-create them, like I’m about to do…

1 Like

Just updated AlarmServer to fix the proxy server portion (Am I the only one to have ever used it until now?)
I also now have a raspberry pi (my wife got me a RasPi4/8Gb for Christmas! She’s the best!), so I can test out your code once its ready.

1 Like

Tell me more about the proxy server fix; what was the issue? I’m having a problem that I wonder is related.

I’m realizing the alarmserver network comms is a strange hybrid - they set up a socket-based server on port 8111 where they receive command requests (api/alarm/xxx0) and send short replies, but also separately use the python requests module to send device status updates to ST to the url:port from config file (and ignores replies). Very strange. So it seems that two separate sockets are required to communicate with it - one set up as a server to receive updates via requests module usage, and another connecting as a client to port 8111 to send down /api/alarm commands. Is this how you are managing it?

AlarmServer has the ability to setup a proxy server for the Envisalink device. This is important because the Evisalink device only supports one connection at any time, which the AlarmServer takes up. WIth a proxy, you can now create new connections to Envisalink device via AlarmServer.

I found that it wasn’t working correctly because I had attempted to use the proxy. I setup another instance of AlarmServer for my new SmartApp to connect to my existing AlarmServer, via proxy, that way I wouldn’t have to keep taking down my main AlamServer for my home when testing.

You are correct with AlarmServer. It does setup multiple sockets, one for communicating with the Envisalink device, another for communicating with SmartThings using a webhooks/RESTful api. It also sets up a proxy for any other device that may want to communicate with the Envisalink device.

I’m sure there are better ways of doing it, but it all works for now, so I’m in no hurry to replace it. I would like to eventually move its functions into my current SmartApp, but that’s not happening anytime soon.

1 Like

So for posterity… there are 3 communications being used in alarmserver:

  1. one proxy server for communicating with envisalink (EnvisalinkClient class)
  2. one server socket (via AlarmServer & HTTPChannel classes) for receiving /api commands and sending replies via port 8111 (not really a proper RESTful api or webhooks implementation)
  3. use of requests module (one-off HTTP sends from Envisalink Client class) for sending device updates to ST url (not really a proper RESTful api or webhooks implementation)

Have you found anything unique about socket configuration requirements for the /api commands? I’m having a problem where the first request works fine, but subsequent ones aren’t working - from code, that is - the frustrating part is it works fine just sending them from a browser! It must be some socket configuration issue or header format, but I haven’t cracked the code.

I haven’t run into that kind of problem; every request works.
I would recommend to look at the SmartApp written in groovy to get a feel for how to communicate with AlarmServer. That is how I managed to work it all out.

Found my problem - alarmserver was ignoring the keep-alive connection header and closing the client connection each time. yay

1 Like

Hi, I moved to the new Ralph stuff today from previous version of LXxero. initially everything was ok, but 2 hours after fired up the server it stopped sending events updates, showing the following error message in windows CMD <class ‘requests.exceptions.ConnectionError’> the error appears 4 times.
If I shutdown and re start the server it works for a while but then stop again with the same messages. Please help to resolve this. Thanks.

Anyone find a solution for PGM OUT? Thank you

I’m trying to update my setup by creating a new alarmserver instance that runs on Python 3 as I understand the latest update by Ralph needs Python 3. Currently my alarmserver is installed in a VM running on one of my Win10 clients so I was planning to create the new instance on my Windows server 2012. I installed the latest Python 3.9.1 on my Windows server, and I can call it up by typing ‘python’ or ‘py’ in the command line to verify it works. But when I tried to run the alarmserver script, I get this error:

c:\alarmserver>python alarmserver.py -c alarmserver.cfg
Traceback (most recent call last):
File "C:\alarmserver\alarmserver.py", line 22, in <module>
   import requests
ModuleNotFoundError: No module named 'requests'

c:\alarmserver>

If I run using ‘py’ instead of ‘python’ I get the error for import configparser on line 14 instead of requests.

What am I doing wrong?

Edit: In the last hour or so of trying to troubleshoot this, I’ve also tried installing on a raspi4 with Python3.8 installed, and I’m getting the same ModuleNotFoundError error.

I bit on this as well and just went through the setup process. I also had the same findings re: unable to use in automations or routines.

I found the device type is “placeholder” and I’m wondering if we just need to apply or create something to get it fleshed out properly.

Is it possible to apply custom device type handlers for linked services like this? From what I understand this product just went onto Kickstarter a couple months ago, so if we push hard enough surely we can get this built out into something secure & functional, either with or without Nexx’s help.

Anyone have any ideas? Want to create a new thread?