New Feature Requests

Information and support for EnvisaLink modules.

Moderators: EyezOnRich, GrandWizard

DeanRobinson
Posts: 59
Joined: Sun Jan 27, 2013 1:11 am

Re: New Feature Requests

Post by DeanRobinson »

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.
blakem
Posts: 36
Joined: Fri Jan 11, 2013 8:00 am

Re: New Feature Requests

Post by blakem »

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.
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.
GrandWizard
Posts: 2289
Joined: Tue Nov 16, 2010 4:08 pm

Re: New Feature Requests

Post by GrandWizard »

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.
That's not actually how it works. Zone Followers are real events, sent when they happened. So you could do what you propose.

I suppose we could synthesize a new event called "Entry Delay".
DeanRobinson
Posts: 59
Joined: Sun Jan 27, 2013 1:11 am

Re: New Feature Requests

Post by DeanRobinson »

I find the zone followers opening reports are very fast, usually I will get notified within 10 Seconds of opening a zone. So they would have to get in and find the unit or cables very fast to disable it before that time.
mikep
Posts: 138
Joined: Wed May 30, 2012 1:49 pm
Contact:

Re: New Feature Requests

Post by mikep »

If I were trying to get in and I knew you had an envisalink, I'd probably cut your internet connection first before kicking the door in.

Seems like the important message is "loss of supervision", counting on an entry event to happen first might not cover all situations.

Mike
DscServer for android/linux/windows: https://sites.google.com/site/mppsuite/dscserver
Jason
Posts: 13
Joined: Wed Aug 28, 2013 5:38 pm

Re: New Feature Requests

Post by Jason »

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.
K-Man
Posts: 143
Joined: Fri Jun 01, 2012 1:08 pm

Re: TPI Enhancement Proposal

Post by K-Man »

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
Hi, sorry for the delay.

I guess I am trying to figure out why sending the RST when the connection is busy is bad? I'm not sure I would like my TPI connection booted off by another connection. I don't like the idea of having my session hijacked by something else.
K-Man
Posts: 143
Joined: Fri Jun 01, 2012 1:08 pm

Re: New Feature Requests

Post by K-Man »

GrandWizard wrote:
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.
That's not actually how it works. Zone Followers are real events, sent when they happened. So you could do what you propose.

I suppose we could synthesize a new event called "Entry Delay".
Yes we could synthesize an event. I'll add this to the feature list.
K-Man
Posts: 143
Joined: Fri Jun 01, 2012 1:08 pm

Re: New Feature Requests

Post by K-Man »

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.
You just enter "*4", that's pretty easy in my opinion.

As for whether the partition has chime enabled or not, we have no visablity on this as chime actually comes from the control panel, not from the keypad. Basically the panel tells the keypad to "beep" and the keypads obey. There is also no visual indication on the keypad as to this state either.

As for your work-around solution, this would be possible but there is no current mechanism to intercept these "beeps", let alone associate it with a remote keypress command. There could an easier way to do this. That is, if there was a synthetic event on toggle, that would be easier that trying to maintain state.

Considering that changing the "chime" option is a once a year deal (if that), I think it would be a while before it popped up to the top of the priority stack. I'm not trying to be snarky, but we have a tonne of major features piled up right now.
ams123
Posts: 3
Joined: Thu Sep 05, 2013 1:27 pm

Re: New Feature Requests

Post by ams123 »

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.
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.
Post Reply