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

Wiki Projects & Stories
, ,
1181

I’m at a clients location but had a bit of downtime so I sent an email to EyezOn and they pushed out the latest firmware with syslog support. Ver 01.01.108

Here’s what I did to get it up and running until I get more time to go into detail. Again, I’m running a RPi3 with the latest Raspian Jessie. All commands are run from the ‘pi’ home directory. /home/pi

Let’s configue the rsyslog server by add/modify the file:
sudo nano /etc/rsyslog.conf

Uncomment the following lines by removing the # sign:

#$ModLoad imudp
#$UDPServerRun 514

#$ModLoad imtcp
#$InputTCPServerRun 514

Then, just below there, and before the GLOBAL DIRECTIVES section, add these lines:

$template RemoteLogs,"/var/log/%HOSTNAME%/%PROGRAMNAME%.log" *
*.*  ?RemoteLogs
& ~

This will allow the rsyslog server to listen on UDP and TCP ports, just in case it’s needed. The template section will create and write to a log file based upon the hostname and application of the client. Make sure you have the hostname in /etc/hosts. In my case, it’s writing to:

/var/log/envisalink/ENVISALINK.log

Restart the rsyslog server by;
sudo systemctl restart rsyslog

You can test for the listening ports with:
sudo netstat -tulpn | grep rsyslog

Now log into your EVL-4 and configue the syslog client section. The IP subnet address should already be filled in and you only need to add the server number. For example, if the subnet is 192.168.125 and your alarmserver/rsyslog server is 15 then the full IP address would be 192.168.125.15. I set my facility number to 23, which I believe should be the debug severity, but I don’t have time right now to experiment.

Then click the ‘Change’ button and ‘reboot’ the EVL. I also rebooted my Rpi, just to be safe. I armed and disarmed my alarm system remotely and checked the log file for entries with the following command:
sudo cat /var/log/envisalink/ENVISALINK.log

Of course, while these instructions worked for me, your results may vary based upon your particular configuration. I hope I didn’t miss anything as I’m in a bit of a hurry, at the moment. Maybe it’s enough to get you all started and then you can help out with anything I missed.

Cheers!

1182

I might have been a bit vague with information in my last post. My apologies.

I should have mentioned that rsyslog is the default syslog daemon in the latest Raspian Jessie OS. It is already running for local client logging and therefore does not need to be installed. It basically just needs to be told to listen for remote clients. That is why it is necessary to uncomment the lines that I noted. You could only use UDP, which is faster but can be error prone at times, or you could just use TCP. I turned on both just to get you up and running while leaving the experimenting up to you.

I wanted my logs to go into a separate named log file instead of into a shared log file so that is the reason for the 3 added lines in the rsyslog.conf file.

I’m sure that @Xero will be able to add great information to help with making a better configuration and for getting as much log info as possible, whenever he gets time. I’ll also try to dig deeper into logging as I’m sure @TAustin will too.

Thanks to all of you!

EDIT: As your log file gets larger, you may want to pipe the output to ‘less’ so that you can scroll up and down;
sudo cat /var/log/envisalink/ENVISALINK.log | less

1183

Excellent. Thank you! Working for me.

1184

Unfortunately I don’t know how to reproduce the error. I think it might have to do with how my EVL-4 is hooked to the network. Because it’s located in a closet away from all of my networking gear, I have used a powerline adapter to connect it to my router. Anybody else have this setup?

1185

So far, I’ve noticed that the EVL is picky about how it is connected to the network. I have a network cable, I guess around 120’ long, that I use to troubleshoot network issues. I can connect directly from my router to any area in the house. This has helped me solve many issues such as faulty cables and connections. I have used a powerline adapter in the past and it was flaky at best.

Here’s my spaghetti mess!

019ae0e7fe9a0010a9d124e5d205de79da4c1d609c.jpg1537×2049 566 KB

1 Like
1186

Hey Mitch - something I found regarding your guidance above to disable the auto-start. The only way I was able to stop my pi3 from autoloading screen+alarmserver (so I could do some debugging) was to rename the screen@pi.* files to something else. The stop and disable systemctl commands seemed to have no effect. I tried executing the commands both using sudo and as root, when I rebooted, lo and behold I found screen running alarmserver. Crazy. The only thing I can think of is some other service is still loading them; Maybe some old systemd config file or something maybe?

1187

No, it’s just an idiosyncrasy of syslogd, I suppose. I had forgotten that you can’t use paths with the ‘disable’ command but you can with the ‘enable’ command. Go figure!!

Therefore, to disable the screen@pi.timer file, or other unit file, you must change to it’s directory:
cd /lib/systemd/system

Then, from there you must do:
sudo systemctl disable screen@pi.timer

And it’s best to get in the habit of doing this after any change to a unit file:
sudo systemctl daemon-reload

Then reboot or sudo reboot, depending on how you logged in.

You can continue to run the enable command from /home/pi, if you want. It still holds true that you only need the screen@pi.timer file enabled and not the screen@pi.service file.

I’m not at home right now but I did remote in and tested this and it does work. I’ll edit my original instructions when I get a chance. Hopefully, I’ll still be able to edit that post. Sorry for the mistake! :disappointed:

1188

That’s a tricky one! Thanks.

1189

Ok if we’re going to share dirty laundry, here’s my contribution!

IMG_1500.JPG2448×3264 2.2 MB

Try and find the EVL :nerd_face:

1 Like
1190

Ohhhhh look at the G-String on That!!! :joy:

1191

Where’s Waldo?? Err… EVL? :joy:
I see it!!! :grin:

1192

Any idea how hard it would be to create a device handler or device type for the chime? I’m totally fine with a separate switch as long as I can control it. Any advice on where to start?

1194

I’ve attempted to edit and change all references in my posts regarding the use of the ‘systemctl disable’ command. The ‘disable’ command will not work if using paths in the command line. It only works from within the folder that contains the unit file that you are attempting to disable.

Thanks to @TAustin for discovering the issue.

1195

Mr. Xero -

I’ve since resolved the errors I had been getting by re-configuring my network, but here’s a clip of a saved log file that shows the pertinent messages I had been getting. The connection was being dropped a short time after initialization, but I wasn’t seeing any realtime log messages indicating a problem; unfortunately I wasn’t capturing anything that might have been going to the command line. But I eventually was testing without a log file - all messages going to console, and even in that mode I wasn’t seeing any extra error messages. Anyway, hope this is helpful input.

Initializing…
.
.
.
2017-04-05 22:06:49 myURL: https://graph-na02-useast1.api.smartthings.com/api/smartapps/installations/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/update?access_token=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
2017-04-05 22:06:50 RX < 650 - 1 - Partition Home Ready
2017-04-05 22:06:50 myURL: https://graph-na02-useast1.api.smartthings.com/api/smartapps/installations/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/update?access_token=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
2017-04-05 22:06:51 RX < 616 - 0000000000000000 - Bypassed Zones Bitfield Dump
2017-04-05 22:06:51 myURL: https://graph-na02-useast1.api.smartthings.com/api/smartapps/installations/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/update?access_token=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

<<---- At this point things were working normal, but after 5 minutes or so of inactivity, I would discover that zone status change notifications stopped coming from the EVL4
<<---- Only way to restore things was to initiate something from the ST app, so that’s the next thing that appears in the log:

2017-04-05 22:24:42 Incoming web connection from (‘192.168.2.127’, 48596)
2017-04-05 22:24:42 Web request: GET /api/alarm/refresh
2017-04-05 22:24:42 TX > 00191
2017-04-05 22:24:44 TX > 07111#47
2017-04-05 22:24:44 Disconnected from EnvisaLink:4025 <<---- Here is where alarmserver seems to first discover that it lost the socket connection
2017-04-05 22:24:44 Connection failed, retrying in 10 seconds
2017-04-05 22:24:54 Connected to EnvisaLink:4025
2017-04-05 22:24:54 RX < 505 - 3 - Login Interaction
2017-04-05 22:24:54 TX > 005user54
2017-04-05 22:24:54 Disconnected from EnvisaLink:4025
2017-04-05 22:24:54 Connection failed, retrying in 10 seconds
2017-04-05 22:25:04 Connected to EnvisaLink:4025
2017-04-05 22:25:04 RX < 505 - 3 - Login Interaction
2017-04-05 22:25:04 TX > 005user54
2017-04-05 22:25:04 RX < 500 - 005 - Command Acknowledge
2017-04-05 22:25:04 RX < 505 - 1 - Login Interaction
2017-04-05 22:25:04 TX > 00191
2017-04-05 22:25:06 TX > 07111#47
2017-04-05 22:25:06 RX < 500 - 001 - Command Acknowledge
2017-04-05 22:25:06 RX < 610 - 001 - Zone DSC Zone 01 Delay Doors Restored <<----- Now things are back working again
2017-04-05 22:25:06 myURL: https://graph-na02-useast1.api.smartthings.com/api/smartapps/installations/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/update?access_token=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
2017-04-05 22:25:06 RX < 610 - 002 - Zone DSC Zone 02 Master Bedroom Restored
2017-04-05 22:25:06 myURL: https://graph-na02-useast1.api.smartthings.com/api/smartapps/installations/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/update?access_token=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
2017-04-05 22:25:07 RX < 609 - 003 - Zone DSC Zone 03 Inlaw Suite Open
.
.
.
Proceed with partition/device initialization

1196

@salvar01

As I mentioned in an earlier post, my goal has been to also have multiple partitions. In my case, I will have a partition for my house, workshop and a storage building. I’ve finally taken some time to start working on this and my results have been very much like yours…:disappointed:

I currently am using only 7 sensors/zones. I have been testing AlarmServer with all 7 zones in Partition1 (House) using three keypads: RFK5564, PK5500 and LCD5511. All has been working great.

Today, I moved the LCD5511 to partition2 (Workshop) along with the door sensor for that zone. AlarmServer was not running during this initial testing of the multiple partitions. After reprogramming the DSC1864 alarm panel, all keypads and re-configuring my EyezOn account, I ran many different combinations of arm/disarm, etc., from all three keypads and from the EyezOn account. No problems! I could also arm/disarm any partition from any keypad by temporarily assigning that keypad to a different partition using keypad commands. Again, no problems!

I then re-configured the alarmserver.cfg file and started alarmserver.py. The new panels were created in the SmartApp and all functions of partition1 (House) worked as before. However, partition2 (Workshop), did not work at all but instead would control partition1 (House). Probably very similar to the same problems that you were having. There were other inconsistacies but I won’t go into detail because they are most likely related to the root issue.

I’ve just spent the past couple hours running a variety of test. I’ve examined the logs thoroughly and I believe that I have enough information to point Jordan @Xero in the right direction to locate the problem. I’ll add the details in another post and hopefully he’ll take a look at it, whenever time permits.

Just “hang in there”!! This app is great and has even more potential than most of us can imagine!

Cheers!

1197

@Xero
@salvar01

Jordan, when you have some free time, would you look into the problem that @salvar01 and I are having with mulitiple partitions? You may reference my post, above.

For now, I’ll just try to give you the basic information I have that might lead you to the underlying problem. I’ll provide any logs necessary and/or answer any other questions that you might have.

The panels for partition2 are being created properly in the SmartApp. I’m only using the Stay/Away panels. Not Simple Panels or SHM. The Network Device ID’s are being created in the IDE, dscstay2 and dscaway2.

When I arm/disarm either partition from the keypads or EyezOn website, the alarmserver logs and the IDE live loggging show the the proper commands for partition1 and partition2 and they both work properly. The SmartApp will show the correct status for partition1 and partition2. The problem is that when I try arming/disarming from the partition2 panel in the SmartApp, it will arm/disarm partition1 instead. Both logs will show that it is sending the commands for partition1 instead of partition2. All partition1 switches in the SmartApp partition1 panel work properly for partition1. All partition2 switches in the SmartApp will also control partition1.

That was probably confusing. The bottom line is that I can control partition1 or partition2 from all sources expect the SmartApp. The SmartApp will show all correct partition statuses when commands are sent from all sources except the SmartApp. The logs show that the partition2 panel is sending commands for partition1 instead.

Please let me know if I can provide more/better information and/or logs that might assist you.

Best regards!

1198

Hello,
I have a DSC that’s integrated into my SHM, thanks to all the great work by many of you on this group. I also have a few extra devices (motion detectors, etc.) that integrate into the SmartThings ecosystem, but not into the DSC system.

My SHM monitors all those extra devices too. When there’s a violation on any of the DSC integrated devices, the DSC system itself goes off and so does the SHM, which sends me an alert. But, when the extra devices detect any violation, that understandably doesn’t trigger the DSC system, but only triggers the SHM. I’m wondering, if there’s an alarm or siren capability that could and should be added to the DSC Away/Home device handler, which could then be triggered, whenever SHM detects a violation.

Is this possible at all and if so, will very much appreciate if I someone can provide the guidance.

1199

I think if you just turn the alarm panel “on” or use core to trigger the alarm function that way you could easily accomplish this.

1200

Thank you for that. Sorry, if it should be obvious to me, at this point. But, should I create a new device type to “turn on” the alarm panel or is there some other way with the current device handlers (from LXXero/DSCAlarm), I can easily achieve this?

If I have to create a new device handler for the alarm panel and utilize the “DSC Integration” smart app as the parent, should I then, just create the device under the same namespace or is there something else I should do, to ensure that the parent-child relationship is maintained?

1201

As stated previously in another thread:

The only variable that is exposed dealing with the siren/alarm event is Panic.

Create a Virtual Switch and call it “SHM Alarm”…Virtual Switches are created in the IDE or you can use the app Switch Mania.

Use this Virtual Switch as a light in the Turn On Lights Option in the SHM settings when Alarm is tripped.

Use CoRE to say,
If Switch “SHM Alarm” Changes To on
Then Using DSC Alarm Panel
Panic

This will make the siren sound in the DSC Panel. SHM will send alarm events for both non DSC stuff and ST triggers.