Try this and let me know what you see in the console…
- Stop STNP, uncomment lines 183 and 197 in
plugins/envisalink.js - Start STNP
- Watch the console and let me know when you stop seeing events
Hi Redloro
Really great work. I was able to set it up but not able to get it to work correctly. All devices was setup ok and seen by ST. But the things status will not change when I open doors or windows etc.
I looked at the logfiles, I turned on the RX and TX debug
[2017-01-22T19:02:30.841Z] [stnp] SmartThings Node Proxy listening at http://0.0.0.0:8080
[2017-01-22T19:02:30.872Z] [stnp] Loaded plugin: envisalink
[2017-01-22T19:02:30.876Z] [gnrc] Doing something interesting during init…
[2017-01-22T19:02:30.877Z] [stnp] Loaded plugin: generic
[2017-01-22T19:02:30.882Z] [evl3] Connected to Envisalink at 192.168.0.144:4025
[2017-01-22T19:02:30.885Z] [evl3] RX < Login:
[2017-01-22T19:02:30.886Z] [evl3] TX > user
[2017-01-22T19:02:30.887Z] [evl3] RX < OK
[2017-01-22T19:02:36.919Z] [evl3] RX < %00,01,1C08,08,00,DISARMED Ready to Arm $
[2017-01-22T19:02:36.923Z] [evl3] {“type”:“partition”,“partition”:1,“state”:“ready”,“alpha”:“DISARMED Ready to Arm”}
[2017-01-22T19:02:46.442Z] [evl3] RX < %00,01,1C08,08,00,DISARMED Ready to Arm $
[2017-01-22T19:02:55.464Z] [evl3] RX < %00,01,1C08,08,00,DISARMED Ready to Arm $
[2017-01-22T19:03:04.986Z] [evl3] RX < %00,01,1C08,08,00,DISARMED Ready to Arm $
[2017-01-22T19:03:05.989Z] [evl3] RX < %00,01,1C08,08,00,DISARMED Ready to Arm $
[2017-01-22T19:03:10.499Z] [evl3] RX < %01,00008000000000000000000000000000$
[2017-01-22T19:03:10.499Z] [evl3] Execute zone_state_change: 00008000000000000000000000000000
[2017-01-22T19:03:13.005Z] [evl3] RX < %00,01,1C08,08,00,DISARMED Ready to Arm $
[2017-01-22T19:03:21.024Z] [evl3] RX < %00,01,1C08,08,00,DISARMED Ready to Arm $
Few things puzzle me
- I am not seeing the zone lines showed in other people log.
- the partition always return Ready to Arm, instead of FAULT
Here is an example of thedude130 log
2016-10-31T17:06:07-0500 {“type”:“zone”,“partition”:1,“zone”:18,“state”:“open”}
2016-10-31T17:06:07-0500 {“type”:“partition”,“partition”:1,“state”:“notready”,“alpha”:“FAULT 18 KITCHENMOTION”}
2016-10-31T17:06:09-0500 {“type”:“partition”,“partition”:1,“state”:“notready”,“alpha”:“FAULT 03 BACK DOOR”}
2016-10-31T17:06:10-0500 {“type”:“zone”,“partition”:1,“zone”:17,“state”:“open”}
{“type”:“partition”,“partition”:1,“state”:“notready”,“alpha”:“FAULT 17 LIVING ROOM MOTION”}
2016-10-31T17:06:12-0500 {“type”:“partition”,“partition”:1,“state”:“notready”,“alpha”:“FAULT 03 BACK DOOR”}
I have a envisalink 4 (not version 3). I looked thru the document for Envisalink 4, there are some differences in the number of zones support (version 3 support 64, version 4 support 128) so the size of the return code from TPI commands are bigger. I am not sure this is the cause of the problem I have. For example
- the zone_value_change size is 8 in version 3 but it is 16 in version 4.
- the zone_timer_dump size is 256 in version 3 but it is 512 in version 4.
Here is my setup
- smartthing v2
- envisalink 4
- vista 20p panel
- qnap linux station for proxy
Any comment?
Proxy appears to be caught in loop, here is a snippet from the console log
[1/23/2017, 11:29:14 AM] [evl3] TX > ^02,$
[1/23/2017, 11:30:14 AM] [evl3] TX > ^02,$
[1/23/2017, 11:31:14 AM] [evl3] TX > ^02,$
[1/23/2017, 11:32:14 AM] [evl3] TX > ^02,$
[1/23/2017, 11:33:14 AM] [evl3] TX > ^02,$
[1/23/2017, 11:34:14 AM] [evl3] TX > ^02,$
[1/23/2017, 11:35:14 AM] [evl3] TX > ^02,$
[1/23/2017, 11:36:14 AM] [evl3] TX > ^02,$
[1/23/2017, 11:37:14 AM] [evl3] TX > ^02,$
[1/23/2017, 11:38:14 AM] [evl3] TX > ^02,$
[1/23/2017, 11:39:14 AM] [evl3] TX > ^02,$
[1/23/2017, 11:40:14 AM] [evl3] TX > ^02,$
[1/23/2017, 11:41:14 AM] [evl3] TX > ^02,$
Doesn’t look like the EVL is setup right… can you see alarm panel status, etc from https://www.eyez-on.com?
When you open doors, windows, etc is the correct status displayed on your physical keypad? And is the status shows at https://www.eyez-on.com also correct? Make sure that the envisalink is setup and events are visible on the EyezOn website… then retry. The evl module is obviously not sending the events through…
The proxy was working for 2 days prior to locking up. When I stopped it (Just closed window), I did an http call to the envislink to ensure it was answering (it was), I then restarted the node and all is functioning at this time. I did not think to check the cloud.
Thank you for your assistance in this troubleshooting
This e-mail is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. Any review, dissemination, copying, printing or other use of this e-mail by persons or entities other than the addressee is prohibited. If you have received this e-mail in error, please contact the sender immediately and delete the material from any computer.
I have verified that all within the cloud is correct and functioning at this time
This e-mail is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. Any review, dissemination, copying, printing or other use of this e-mail by persons or entities other than the addressee is prohibited. If you have received this e-mail in error, please contact the sender immediately and delete the material from any computer.
You may need to reboot the evl too… there is a restart button on the admin page of the evl. It’ll randomly (and very seldomly) get locked up, but this is the easiest way to restart.
Anyone having this trouble with the zone dumps
It shows a dump for every zone then a few mins later i get a ETIMEOUT for every zone
[2017-01-23T22:04:21.061Z] [evl3] {“type”:“zone”,“partition”:1,“zone”:63,“state”
:“closed”}
[2017-01-23T22:04:21.063Z] [evl3] {“type”:“zone”,“partition”:1,“zone”:64,“state”
:“closed”}
[2017-01-23T22:04:42.070Z] [stnp] Notify error: Error: connect ETIMEDOUT 10.2.0.
34:39500
[2017-01-23T22:04:42.406Z] [stnp] Notify error: Error: connect ETIMEDOUT 10.2.0.
Hi redloro
Thanks for the reply. Yes, everything is working fine with physical keypad, eyez-on site showing different color on zones if I open doors, windows etc. The evl ip page also showing correct information similar to eyez site. I also did a reboot on the evl and did not seem to help.
Yes, it seems like evl not sending event.
And there is no TX command in between except sending the user password. Are you expect we are sending command to evl? Or doing any initialization etc.
Hi, redloro
One more thing. I just take a look at my log, I did see the state_change function is being called. I uncomment the logger in zone_state_change function.
[2017-01-22T19:03:05.989Z] [evl3] RX < %00,01,1C08,08,00,DISARMED Ready to Arm $
[2017-01-22T19:03:10.499Z] [evl3] RX < %01,00008000000000000000000000000000$
[2017-01-22T19:03:10.499Z] [evl3] Execute zone_state_change: 00008000000000000000000000000000
[2017-01-22T19:03:13.005Z] [evl3] RX < %00,01,1C08,08,00,DISARMED Ready to Arm $
And getting the correct zone change values back. But then it still RX the old status line (not being updated) and not seeing any TX line etc.Are we suppose to do something with zone_state_change?
Sorry, I am not sure I understand the mechanism here.
@pakmanwg… the TX is when STNP sends something to the EVL… but that part is not important. What is important is the RX… this is where the EVL is sending status updates to the STNP… and it’s clear that the EVL is not sending sensor open/close events as these would be logged as such…
RX < %00,01,1C08,08,00,****DISARMED**** Ready to Arm $
RX < %00,01,1C08,08,00,****DISARMED**** Ready to Arm $
RX < %02,0300000000000000$
RX < %00,01,0008,10,00,FAULT 10 FOYER MOTION $
RX < %02,0100000000000000$
RX < %00,01,1C08,08,00,****DISARMED**** Ready to Arm $
RX < %02,0300000000000000$
RX < %00,01,0008,10,00,FAULT 10 FOYER MOTION $
RX < %02,0100000000000000$
RX < %00,01,1C08,08,00,****DISARMED**** Ready to Arm $
If you are not seeing any of the events that start with %00 or %02 other than the ***DISARMED*** then something is not setup right. Can you PM your Envisanlink admin pages?
@Big_Webstas you can ignore those unless it’s causing an issue… the STNP routinely does a zone dump and tries to send all the updates to the Hub… and those can occasionally time out.
Hi redloro
I noticed one thing, in your case, your RX start with %02
RX < %02,0300000000000000$
while in my case RX start with %01
RX < %01,00008000000000000000000000000000$
%02 is partition state change
%01 is zone state change
It seems like my evl send out zone state change while in your case, it send out partition state change
I also have %01 messages… and yes… the problem is that your EVL is not sending %02 messages… please check this video I just posted to verify that your EVL is setup correctly. If you cannot receive %02 messages, then either your EVL is bad, broken or misconfigured.
Hi redloro
It looks like %02 is missing from my evl response
Trying 192.168.0.144…
Connected to 192.168.0.144.
Escape character is ‘^]’.
Login:
user
OK
%00,01,1C08,08,00,DISARMED Ready to Arm $
%00,01,1C08,08,00,DISARMED Ready to Arm $
%00,01,1C08,08,00,DISARMED Ready to Arm $
%01,00008000000000000000000000000000$
%00,01,1C08,08,00,DISARMED Ready to Arm $
%00,01,1C08,08,00,DISARMED Ready to Arm $
%00,01,1C08,08,00,DISARMED Ready to Arm $
%00,01,1C08,08,00,DISARMED Ready to Arm $
%00,01,1C08,08,00,DISARMED Ready to Arm $
%00,01,1C08,08,00,DISARMED Ready to Arm $
%00,01,1C08,08,00,DISARMED Ready to Arm $
%00,01,1C08,08,00,DISARMED Ready to Arm $
%00,01,1C08,08,00,DISARMED Ready to Arm $
Let me research a little bit to see. Thanks.
Hi redloro
Finally get it to work. Turn out the evl is setup to control partition 2 instead of partition 1, so it will not receive fault from partition 1. After reassign honeywell the partition 1 to evl keypad, everything working fine now. Thanks.
Awesome… glad to hear you’re up and running now!
Hi, redloro
Yes, Great software and great help. Thanks.
Redloro Sir,
My STP went into that loop again where it just keeps transmitting [evl3] TX > ^02,$, Booting the envisalink corrected the issue , just as or closing and restarting STP appeared to last time. would it be possible to count the number of consecutive TX’s without a response and if it got to 10 without a response then restart the STP.