Humm strange…
The place it’s choking is right where it would parse the first line of text back from the EVL - which is an odd place for it to be dying. You redefined all the zones/partitions/etc according to the new alarmserver.cfg example right? They need to be in their own sections at the bottom of the file now. I’m guessing it’s just failing out because it can’t talk to ST though…EDIT: it can’t be that, i just tried using invalid tokens and it still worked fine for me…something else must be weird…might need some more details to figure this out…we can add some stuff to debug further.
you could try adding this logger line just above the “code” line on line 307 that is giving the error:
alarmserver_logger(‘raw input:’+str(input))
code=int(input[:3])
then look for the “raw input” lines in the log…that code= line where it’s dying is trying to grab out the first 3 numbers of the line sent by EVL - normally the first thing the EVL sends would be “5053CD” and it’s trying to grab “505” out of that. The “3” is the parameter to “505” which is “password request” and that should be when alarmserver responds with the password, but it’s dying before that ever happens. The last two characters of the line (CD) are a checksum of the rest of the line, and that can be ignored for now. When you add the “raw input” line, it should hopefully give an idea as to what exactly is getting corrupted. If you can telnet OK - then you should see the same line coming from the EVL device…also make sure there isn’t any weird formatting/corruption issues with your alarmserver files…this is definitely a weird one…it’s almost acting as if the first 3 characters returned were “Log” which makes no sense - unless you simply have the wrong IP in your alarmserver.py or something? if all else fails, try rebooting the EVL as well - there’s a link you can click in the network tab to reboot it when you go to it in your web browser. I can confirm that the only way this could be happening is if whatever you connected the alarmserver to is returning “Log” or something starting with “Log” rather than a valid status code. Did you specify the wrong IP/port under envisalink section in alarmserver? I have no idea where it would get that string of text from…
So here’s how i tested, I setup netcat to listen on an arbitrary port, then I connected alarmserver to that port, and I sent “Blarg” and then ^M which is basically like a new line character.
$ nc -l -p 4028 -T -vv
Listening on any address 4028 (dtserver-port)
Connection from 127.0.0.1:49198
Blarg^M
Total received bytes: 0
Total sent bytes: 7
And here’s the error I was able to reproduce in alarmserver:
2016-04-10 04:17:47 Connected to 127.0.0.1:4028
2016-04-10 04:17:52 raw input:Blarg
error: uncaptured python exception, closing channel <main.EnvisalinkClient connected 127.0.0.1:4028 at 0x7fa688786cb0> (<type ‘exceptions.ValueError’>:invalid literal for int() with base 10: ‘Bla’ [/usr/lib/python2.7/asyncore.py|read|83] [/usr/lib/python2.7/asyncore.py|handle_read_event|449] [/usr/lib/python2.7/asynchat.py|handle_read|165] [./alarmserver.py|found_terminator|276] [./alarmserver.py|handle_line|308])
(it’s line 308 instead of 307 since I added that “raw input” line, but, you can see, the error is now “Bla” instead of “Log” meaning whatever you connected alarmserver to is sending it weird data! If i sent say, “Logging” then the error would indeed say “Log” so this is definitely what’s happening, but as to why, I still am baffled - there must be something weird on your end…)
Much has changed since you’ve probably seen it last! Alarmserver is sending everything via json now and the smartapps/devicetypes are all different now too in order to support the automatic creation of all the devices/panels (this means the device handlers and smartapps must be installed before you run alarmserver so it can create the devices using the device handlers, you’ll want to make sure to install the stay/away panels and the contact/motions as a bare minimum…smoke/carbon are option if you don’t have any) And yeah - it should work with EVL-4 just fine. I only have an EVL-4 myself! So i’ve never even tested with a 3…those comments are just outdated!
I am hoping to create a proper oauth gui at some point - so you can just navigate to a page (hosted by alarmserver maybe?) and it would do all the oauth setup for you…but…that’s not anywhere near ready yet unfortunately…
On an unrelated note, i’ve started developing some new apps that can take switch actions based on routines, and/or remote button presses. This might be an alternative to rule machine for some of the people that wanted to switch the alarm on/off based on certain actions, as rule machine has been really unreliable due to some ST issues as of late. I started another thread about my new apps over here: