New Feature Requests
Moderators: EyezOnRich, GrandWizard
-
- Posts: 59
- Joined: Sun Jan 27, 2013 1:11 am
Re: New Feature Requests
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.
Re: New Feature Requests
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.
-
- Posts: 2319
- Joined: Tue Nov 16, 2010 4:08 pm
Re: New Feature Requests
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".
-
- Posts: 59
- Joined: Sun Jan 27, 2013 1:11 am
Re: New Feature Requests
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.
Re: New Feature Requests
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
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
Re: New Feature Requests
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.
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.
Re: TPI Enhancement Proposal
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
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.
Re: New Feature Requests
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".
Re: New Feature Requests
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.
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.
Re: New Feature Requests
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.