You are Right, is a Typo.I made all changes in the alarmserver.cfg file.
Hey everyone,
I’m trying to use CoRE to toggle the chime. It looks like the variable is chime / nochime but I’m not really sure how to use it. I’ve got the chime toggling based on the change of routine but i want to set it to off or on, not just toggle it
Ideas?
Hi everyone,
I am trying to start the alarmserver with python running in Ubuntu. I have followed the direction from @phiz118 's document. I have EVL 4.
I am getting the following error:
Traceback (most recent call last):
File “alarmserver.py”, line 858, in
server = AlarmServer(config)
File “alarmserver.py”, line 620, in init
self._envisalinkclient = EnvisalinkClient(config)
File “alarmserver.py”, line 263, in init
self.do_connect()
File “alarmserver.py”, line 274, in do_connect
self.connect((self._config.ENVISALINKHOST, self._config.ENVISALINKPORT))
File “/usr/lib/python2.7/asyncore.py”, line 347, in connect
err = self.socket.connect_ex(address)
File “/usr/lib/python2.7/socket.py”, line 228, in meth
return getattr(self._sock,name)(*args)
socket.gaierror: [Errno -2] Name or service not known
Any ideas or suggestions?
Alarmserver doesn’t seem to be maintaining an active connection for me. After about 10 or 15 minutes I no longer get realtime updates to my devices showing in the app.
I found that pressing the refresh button on one of the app panels seems to cause a restart (log file looks like the startup sequence) and things start working again… but only to stop again a short while later.
Running RP3 with V8 Raspian Ethernet connected; EnvisaLink 4; DSC 1616. Followed all great instructions here (THANK YOU!) to auto run in screen on boot up.
Everything seems to work fine otherwise and no errors being reported anywhere. I’m using a log file but may switch to console logging to better debug in realtime. Not sure if data from EL4 stops flowing, RP3 is going to sleep, or connection to ST is somehow failing.
Any ideas?
If it works for 1 minute it should work for 1 year. My Pi doesn’t sleep and I never messed with any settings in it. Jesse is what I am running. Only thing I can think of is logging into the Envi server stops the connection for ST unless you enable a parameter in the config file.
Other than that, you might have some issues with your internet or router. If no issues are present with your connection then, it’s easy enough to start from scratch now that you know how to get it going.
Spend 8 hours troubleshooting. Spend 40 minutes starting from scratch.
I did also set up an EyezOn account so I can monitor my security system with their web page. Could it be that this is interfering with the alarmserver connection? Even tho I’m not signing into it, maybe it’s still refreshing every 10 minutes or so and knocking out my alarmserver connection?
What is the config file parameter you mentioned that addresses this? The proxy for 1 connection limit? I have this:
enableproxy=True
proxyport=4025
proxypass=user
Thanks for any help. This is a mystery I want to solve.
Yep that’s it. However, even with that, the EyezOn either via web or LAN was knocking my connection out and didn’t realize it to after days of frustration. After I finally realized that what the problem was, I’ve been connected consistently since.
What did you do to fix the problem, remove your device from EyezOn?
I had the web site opened in multiple locations, phone, kitchen pc, study pc and a lan connection. I think I just closed all connections by making sure I was logged out, and never looked back…Well maybe once or twice. 
Don’t get me wrong, my installation is not perfect. I had to make a couple of CoRE rules to sync SHM and DSC Panel arm/disarm. Also, my panel, disconnects and reconnects every 2-4 minutes. I think it might be the battery that’s been dead since I moved in. However, this doesn’t cause any break in functionality. If I look at the wall panel, I the lights blinks off then on real quick and in the recent activity page in the ST I get a bunch of stuff. Fills up the log constantly but I just don’t worry about it anymore. It arms/disarms and works as it should.
I checked to make sure I’m logged off from EyezOn; still no luck. I’ve confirmed that it is definitely the EVL4 that is disconnecting after a few minutes. I’ve been looking at the Alarmserver code and realize that it’s not very robust in that it doesn’t confirm that its socket connection with the EVL4 stays alive. I wonder how many people are relying on this thing that don’t even realize their devices aren’t being updated until they do something in the App that forces a re-connection. Talking about a false sense of security! I will try one last thing: I’ll go ahead and delete my device from EyezOn, and change the config file to disable the proxy. If that doesn’t work I wonder if the DSC4 just doesn’t allow ongoing connections and all this is really good for is remote arm/disarm and not for realtime status of the security devices.
Hmm, I use the Power Series 8 PC5010. Not sure what model the DSC4 is? You sure there is not a PCXXXX at the panel? You might have a faulty EVL4… Switch out the network cable and make sure its a Cat 5e or better.
How is it connected to your internet? Straight to router? Through a switch?
Confused. When I referred to “panel” in my previous posts I was referring to the stay and away panels in the app. That’s where I can hit refresh and that forces the server to re-establish connection with the EVL4.
The physical security system itself without the EVL4 works just fine. It’s a DSC PC1616. The EVL4 is connected to a router in my wiring closet off of 192.168.1.xxx. The RP3 is connected to another wireless router sitting at 192.168.2.xxx (that wireless router sits off of 192.168.1.xxx). There’s a nice new Syslog feature that’s now in the latest EVL4 firmware that I wish I could take advantage of, but for some reason it requires setting up the server on 192.168.1.xxx. That would allow me to confirm without a doubt that the EVL4 is still working and seeing updates from the DSC. I really don’t think it’s a network connection problem because when alarmserver loses its socket connection to the EVL4 I can ping the EVL4 so I know it’s still alive and communicating. For some reason, tho, it’s dropping the socket connection to alarmserver after a short time.
I was reading up on the EVL4 developer documentation (from Envisacor), and it states:
“Note: as with all network communications, it is possible the TCP socket could be lost due to a network disruption, or an exception at either the client or server end. Application programmers are advised to include some handling for dropped connections. The Poll command (000) is a useful command to test if the connection is still alive. Alternately, an application could watch for the period time broadcast (510) which is issued by the panel every 4 minutes”
The alarmserver code doesn’t do either of these things.
It’s very interesting that I’ve never seen the period time broadcast in the log. Could be I’m losing connection before it ever gets a chance to show up.
Despite what my problem is, this alarmserver code needs to be enhanced to do a better job at maintaining the connection.
I continue with the problem with Only 11 zones created in my phone. I did everything the zones are recognized in alarmserver log and send info of motion open etc, however devices not created in ST. only 11 out of 47. Please if somebody can help me. Thanks.
Hi. Check your alarmserver.cfg for host name=EnvisaLink. If that looks ok then try pinging “EnvisaLink”. If it can’t find it then your EVL isn’t alive on your network and that may be causing that socket connect error.
No, Only 11. They do not appear in the smartthing IDE. I stopped and restart the alarmseand several times and now I have 13 zones working. So for some reason it creates 2 more. However still far from the 47 zones I have defined in the config file.
Hey guys,
Has anyone figured out a good way to change the chime on and off without trying to just make the toggle command work? I’m struggling a bit to sort out the variables since I’m pretty rubbish with code. I found something in the smart app about chime/nochime but I’m really kind of lost how to use that variable in CoRE to disable and enable the chime or even know if that’s the right variable. Anyone tried this?
Gonna Post anything here I find about the chime in the devicetype if it’s helpful…
standardTile(“chime”, “device.chime”, width: 2, height: 2, title: “Chime”, decoration:“flat”){
state “togglechime”, label: ‘Toggling Chime’, action: “togglechime”, icon: "st.alarm.beep.beep"
state “chime”, label: ‘Chime’, action: “togglechime”, icon: "st.custom.sonos.unmuted"
state “nochime”, label: ‘No Chime’, action: “togglechime”, icon: “st.custom.sonos.muted”
def chimeList = [‘chime’,‘nochime’]
if (onList.contains(state)) {
sendEvent (name: “switch”, value: “on”)
} else if (!(chimeList.contains(state) || troubleMap[state] || state.startsWith(‘led’) || state.startsWith(‘key’))) {
sendEvent (name: “switch”, value: “off”)
You obviously have knowledge of networking so let me just offer something as a point-of-reference and then maybe a couple suggestions.
As point-of-reference, my system has been online for 13 days without a hiccup. My AlarmServer network is all hardwired with Cat5e cable. My router is a TP-Link N600 running OpenWRT Chaos Calmer 15.05 and has 10/100 ports. One port is feeding an old NetGear DS104 10/100 Hub and from there, a jumper cable, to my EVL4 and RPi3.
Unless I misread, your connection to the EVL4 is via WiFi using the 2 routers on different subnets. Routing, on its own, should not be an issue. But WiFi links are notorious for dropping connections. That could very likely be your problem.
Regarding WiFi links, I’ve had better luck with bridging rather than routing. More specifically, unless my business clients requires separate subnets, I like to use Layer 2 transparent bridging, often referred to as WDS mode. That way, I can be assured that all network protocols are passed though the wireless link. Of course, that doesn’t necessarily guarantee success in your situation and you may not have that option. It depends on the firmware in your router.
If either of your routers have a firewall active on the WiFi interface, then the firewall may maintain a idle timer for each connection and is dropping the connection with it times out. You may be able to overcome this problem by sending more frequent keep-alive packets. The default keep-alive timer in Raspbian Jesse is 2 hours, as shown by using the command…
sysctl net.ipv4.tcp_keepalive_time
The following is returned…
net.ipv4.tcp_keepalive_time = 7200
You can modify the keepalive time, probes and intervals to 60 seconds, 4, 15 seconds, respectively by using the following commands from /home/pi.
sudo sysctl -w net.ipv4.tcp_keepalive_time=60
sudo sysctl -w net.ipv4.tcp_keepalive_intvl=15
sudo sysctl -w net.ipv4.tcp_keepalive_probes=4
The result of this is that a keepalive message will be sent if there is no activity over a socket for 60 seconds and, if no response, then a probe will be sent 4 times at 15 second intervals before giving up and closing the connection. You might play around with these settings and find something that works for you. Be aware, these settings are not persistent. Therefore, you would have to edit the /etc/sysctl.conf file and add the necessary lines to the file. For example, from /home/pi…
sudo nano /etc/sysctl.conf
Copy and paste or type in the following lines:
net.ipv4.tcp_keepalive_time=60
net.ipv4.tcp_keepalive_intvl=15
net.ipv4.tcp_keepalive_probes=4
Crtl[O] to write out the file and
Ctrl[X] to exit nano
Reboot for these permanent changes to take effect
sudo reboot
This is not the best way to solve your networking or application issues but it might just be enough.
Good luck and cheers!
Mitch - Thank for the thoughtful and thorough reply!
I was unfortunately vague when I said my RPi3 was attached to a wireless router on 192.168.2.xxx; in fact it is cabled to that wireless router, not on wireless; in fact I’ve disabled wireless on the pi for now. I don’t THINK I have firewalls enabled on that routers but I am going to check. To eliminate the second (wirelesss) router as a potential source of problems, I’m going to move my pi to the 192.168.1.xxx subnet and see how things go that way.
When I mentioned earlier about the new syslog capability from the EVL4 and wanting to use it, it got me also wondering why they restricted it to 192.163.1.xxx subnets. It got me wondering if there is something in the EVL4 firmware that it doesn’t like to be anywhere else OR, as you point out, maybe there are too many problems going through routers to other subnets that they are just avoiding the issue. So best to move it and see what happens and maybe get the syslog feature working too.
If that experiment fails, I’ll next try your keepalive recommendation.
By the way - slightly different topic - does anyone know what’s up with the reboot on the EVL4? When you point a browser directly to it and get access to the config screens, you go to the network page and at the bottom there is TEXT - not a button - but text that says “Reboot EnvisLink”. There’s no visual clue that it’s clickable, but it is. However it doesn’t seem to do anything - just reload the page. (I can’t believe it reboots that fast and returns you to the same page, but maybe…). So I’m not confident I’m really rebooting when I want to and I don’t want to be constantly detaching and attaching wires… BTW, my firmware version: 01.01.108.