dcuste wrote:EV3_fan wrote this comment...........
First I wanna say the EVL-3 and your web-based services are GREAT !
Now I have a serious suggestion to help reduce traffic from your servers, and maybe make the online viewers even happier... ADD an option like a checkbox on the device manager screen to Hide Closing Events of zones. And also allow this option to be set for each zone on the Zone follower setup or Zone labeling page. Either checkbox would filter out closing events from being listed. This would reduce outbound traffic/bandwidth from your servers and make the Recent events screens less cluttered, especially when someone turns on zone following for a motion sensor
Regardless of filtering, continue to show all events in the "View Full Log" page.
Another reason I thought this is a good idea is that when I open and close a door within a few seconds, the events may come via text a few minutes apart, and with timestamps representing the time the text was sent instead of the actual event time, it all appears very confusing. Maybe that is caused by timestamping on your end but I would prefer to see timestamps more representative of the actual event time.
I had an explanation to the zone followers. The zone follower events are not generated by the alarm panel but are generated by the remote eyezon server. Periodically, well just say every 2 minutes, the EVL3 reports the zone timers to the remote server. If there is a change since the last time and the follower is turned on then you get the notification. That means if you open the door a few seconds before it reports it appears instant, but if it just reported then it may seem like it takes a minute or two. Also there is no open timer so an open zone is designated by 0 seconds since it was last closed. That is the reason why you only see 1 zone closed after opening and closing a zone within the report period of the zone timers.
The problem of over active zone followers has already been addressed so there is a limit set to how many notifications can be sent in a short time, say for a motion detector zone follower.
For those of us with Ademco panels, this would be a great workaround to not being able to split the reporting for Open/Close (Disarm/Arm) status changes.
Similar to how zone follow alerts are generated by the EyezOn Server, have a setting for when the status of the alarm changes from "Ready" to "Armed" (or any flavor of arming) that you can have it send an alert. While you will not be able to get which user code armed or disarmed the system, you would be at least able to get a notification on when the system arming status changed.
This seems like it would be easy to do, as it would follow the same workflow as zone follows. If the status of the alarm arming state changes, send an alert with the new status.
Thanks for the response. To me, it impacts anyone with an Ademco/Honeywell panel. Since most of us probably don't want to pay for open/closing reports with our provider, it would seem like an easy workaround to be able to provide the same service independently.
If you would like for me to open up my EnvisaLink for testing I would be happy to do so
He would be great for me to be able create toggle button (at least 2) for opening/close my garage. it's a real pain to go through menu reach program and type the code each time!
1. Local web portal can enable/disable remote arm/disarm feature
2. Local web portal has option to set auto or manually firmware update.
3. Local web portal has option to configure destination servers IPs or hostnames for sending alert messages. In this way, customers can configure their own SMTP server to send messages. The alarm system can be run as a self monitored system.
4. Remote portal has option to delete Commands in Command Queue.
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.
Would it be possible to add an alert for if the alarm goes into entry delay but never receives a code or sends an alarm signal? The thought being to alert on the condition that a door is kicked in and the panel is disabled before the alarm signal can be sent out.
