New Feature Requests

[Ssc]

One feature I would like to see is a way to covert the user id codes reported during "Opening " and "Closing" alerts to names.

So instead of seeing a message like:

Office - Opening By User Code 50

We would get:

Office - Opening By User John Doe

Seeing that I've installed an Envisalink for an office with over 30 different user codes, this would be very useful. I see it as something similar to the partition map/table, but for user codes instead.

[GrandWizard]

That's already a feature. Read the Envisalink primer.

[mikep]

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.

There's a couple of apps on google play that you can use when you're connected to the same network as the envisalink that provide that feature.

Mike

[ams123]

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.

There's a couple of apps on google play that you can use when you're connected to the same network as the envisalink that provide that feature.

Mike

Thanks for the response Mike but I am not willing to trust login and pw or access codes to apps in the google play store.

[Jason]

That's already a feature. Read the Envisalink primer.

Could you be more specific? I also have the same question.

I checked here: http://www.eyezon.com/?page_id=469 and did not find the answer.

[hypnosis4u2nv]

That's already a feature. Read the Envisalink primer.

Could you be more specific? I also have the same question.

I checked here: http://www.eyezon.com/?page_id=469 and did not find the answer.

Log into your Eyez-On account.. Go into manage your device, set up users by naming the numbers.. You should find it in the same area where you name your zones..

[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.

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.

Thanks for the response. In our use case it is pretty common. We turn it off early in the morning when I have to leave early and not wake the kids. Same for in the evening if we need to run out to the garage. We probably turn it on and off on a daily basis when it gets annoying with kids running in and out of the back door. However, we definitely want it on when we go to bed.

Simply having a button on the mobile site that did *4 would be an improvement.

[Jason]

That's already a feature. Read the Envisalink primer.

Could you be more specific? I also have the same question.

I checked here: http://www.eyezon.com/?page_id=469 and did not find the answer.

Log into your Eyez-On account.. Go into manage your device, set up users by naming the numbers.. You should find it in the same area where you name your zones..

Rock. That was it. 'Manage User Names' under 'Manage Device'. Thanks!

[mitalum]

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.

Hi K-Man

The issue is not with the server sending the RST to indicate that it is not accepting connections. The issue is that there is no way to take over the TPI when the TCP connection is in a bad state.

Suppose the client silently disappears, for example it suffers a power loss. The server does not know that the client is gone until it attempts to send data to the client and then times out and closes after not receiving an ack back from the client. The server may not send data to the client for a very long time, minutes or even hours when there are no events. During this time the client may power back on and try to connect. This client will be denied a connection because the server believes it has already has an open TCP connection.

There are other ways that the server gets into this state. Suppose there is a temporary network disruption. During this time, the connected client may poll the server for status and get no response. The client's TCP stack then times out and closes. The server does not see any FIN packet from the client due to the network disruption. Eventually when network disruption clears the client cannot immediately start a new connection because the server still believes it is already connected to a client.

The above network disruption scenario is the one I keep seeing. I think the server constraining itself to a single TPI session is okay. However, there should be a method to abort an old session and initiate a new session. Right now, it is not really possible for a TPI client to recover quickly in the face of network disruptions, power failures, etc. You can't entirely prevent such things from happening. Unfortunately, to make the recovery faster the server really needs to change.

John

[brandonlive]

New feature request:

It would be great to be able to drill down further or filter on the alert settings so users can be more selective in the alerts they get. For example, a user might want to get an alert if the system is armed or disarmed by a particular user code (say, the code for the kids or for a maintenance guy) but not receive all arm/disarm alerts. Another example, someone might want routine alarms to go to the household members only but to send duress or panic alarms to someone outside the household.

In theory, there are a few ways you could do something like this. The easiest option might be a simple text filter - so for each contact, in addition to the general category options currently, you could set it to send only messages with "User code 4" or "Duress code" in them (or perhaps exclude messages that contain text). I actually am trying to set my email account to work somewhat like this - receiving the messages and using filters to pass on only selected ones, which is a pretty usable workaround but less ideal than settings on the Eyez-on system.

Alternatively you could make a sub-checklist of each type of alert in each category so people could choose to drill down if they'd like, checking and unchecking options. You could alternatively add options just addressing the ways people would likely use this (like those listed above).

It'd be great if this made its way to the free version but, if nothing else, this would probably be an attractive EnvisAlerts+ feature.