Re: New Feature Requests
Posted: Tue Aug 27, 2013 11:32 am
One option to cover that scenario would be make that door a zone follower, But of course you would get a message every time that door was opened.
This setup still has the same vulerability if the intruder disabled the envisalink before the heartbeat containing the open door data was sent out. In either case you should get the network connection failure notification. I think the op wanted the remote server to monitor that the entry delay ended by entering a code and not by unplugging the panel before the entry delay ends.DeanRobinson wrote:One option to cover that scenario would be make that door a zone follower, But of course you would get a message every time that door was opened.
That's not actually how it works. Zone Followers are real events, sent when they happened. So you could do what you propose.blakem wrote: This setup still has the same vulerability if the intruder disabled the envisalink before the heartbeat containing the open door data was sent out. In either case you should get the network connection failure notification. I think the op wanted the remote server to monitor that the entry delay ended by entering a code and not by unplugging the panel before the entry delay ends.
Hi, sorry for the delay.mitalum wrote:The envisalink will only accept one client connection on port 4025. When a connection is established an attempt at a second connection has the following behavior.
client sends SYN
envisalink sends SYN-ACK
client sends ACK
(this is the normal 3-way TCP handshake for connections establishment) then
envisalink sends RST
This is a standard way to say that there is "no connection". I will propose what I think is a better way to handle an attempt at a second connection and respectfully ask for this enhancement.
Proposal:
The second attempt at a connection should allow the TCP connection to be established and request the password. If the password is incorrect or one is not received in 10 seconds, close the second connection. If the password is correct, the session should be established on the second connection. If the envisalink believes that there was already an existing session connected, then that connection should be closed by the envisalink. Perhaps before closing the socket a TPI system error can be sent with an error code indicating that a second session has been established.
I think this is a much more robust way to guarantee the ability for a client to connect. This provides a way for a client to take over control of the TPI even when there is an existing session (or if the envisalink *thinks* there is an existing session - which is a problem that I see).
An alternate proposal.
Listen on two sockets (4025 and 4026):
When a connection is attempted to 4025 and there is an established connection, then keep the existing behavior and send the RST flag to indicate "no connection".
When a connection is attempted to 4026 and there is an established connection, then close the established connection and accept the new connection. This closes the existing connection before even verifying the password on the new connection. Perhaps this behavior can be enabled and disabled via the web UI. Some people might not like the ability to close an existing session without a valid password on the second session.
I appreciate any response.
John
Yes we could synthesize an event. I'll add this to the feature list.GrandWizard wrote:That's not actually how it works. Zone Followers are real events, sent when they happened. So you could do what you propose.blakem wrote: This setup still has the same vulerability if the intruder disabled the envisalink before the heartbeat containing the open door data was sent out. In either case you should get the network connection failure notification. I think the op wanted the remote server to monitor that the entry delay ended by entering a code and not by unplugging the panel before the entry delay ends.
I suppose we could synthesize a new event called "Entry Delay".
You just enter "*4", that's pretty easy in my opinion.Jason wrote:Can you provide a way to easily toggle the door chime? It would also be useful to view whether it is currently enabled/disabled. I have a DSC panel. Enabling/disabling of the door chime is handled by holding down the chime button on the keypad. It results in a long beep or three short beeps to indicate status.
It would be nice to be able to view status and toggle the chime from the GUI and mobile link.
If the panel does not report status, a workaround for the envisalink would be to toggle the chime, read the type of beep, and toggle the chime back to return to the original state. The state would be the inverse of the beep reported.
I have to agree with the first comment. As a happy new user of evl-3 with a DSC panel the only thing I am disappointed by is the number of clicks it takes to Arm w/o code on the smart phone web app. At least I think it should be on top of the list.huveu wrote:I've been using my Envisalink 3 with a DSC PC1616 for a couple of weeks now. Here are my suggestions for possible features:
- One click access to Away Arm and Stay Arm (w/o code). So we don't have to click ARM, wait, scroll, and click either option.
- Automatic refreshing.
- As mentioned by other users. Scheduling for alerts would be an awesome feature.
Thanks for the work you do. It is truly appreciated.