One more vote for a virtual keypad for the Ademco system (Vista 20P).
Thanks.
New Feature Requests
Moderators: EyezOnRich, GrandWizard
Re: New Feature Requests
Exactly, I'm looking for that as well. I'd want the alarm to auto disarm if it has been auto armed. In other words, if I manually arm it myself, like when I'm away for a few days, I would not want it to auto disarm.raygallion wrote:It would be nice to be able to schedule auto arm with stay or with away at a specific time and then be able to disarm at a specific time as well. Being able to schedule from the portal would be awesome.
Thanks
Re: New Feature Requests
Even if it's not a full blown scheduling of arm/disarm, I'd really like the following simple feature:
- If the Alarm is in ready mode, automatically Stay arm it at a defined time, say 11pm, when going to bed.
- If the alarm is in Stay Armed mode, auto-disarm it at a defined time, say 6am, when waking up. If the alarm is in Away armed mode, it should not be auto-disarmed of course.
That should be fairly simple to implement (DSC PC1832).
- If the Alarm is in ready mode, automatically Stay arm it at a defined time, say 11pm, when going to bed.
- If the alarm is in Stay Armed mode, auto-disarm it at a defined time, say 6am, when waking up. If the alarm is in Away armed mode, it should not be auto-disarmed of course.
That should be fairly simple to implement (DSC PC1832).
Re: New Feature Requests
I think this is a good idea in terms of convenience, but this would mean one of your alarm system user or master codes would need to be stored in the eyez-on portal. It might not be a bad feature for some that don't mind that risk, but I don't want the ability for someone to hack into my portal account where they can schedule my alarm to disarm. So far that is one of the best things about the envisalink is that it does not save your alarm code so it operates transparently as a keypad that can be accessed from the internet.Madelinot wrote:Even if it's not a full blown scheduling of arm/disarm, I'd really like the following simple feature:
- If the Alarm is in ready mode, automatically Stay arm it at a defined time, say 11pm, when going to bed.
- If the alarm is in Stay Armed mode, auto-disarm it at a defined time, say 6am, when waking up. If the alarm is in Away armed mode, it should not be auto-disarmed of course.
That should be fairly simple to implement (DSC PC1832).
As an added measure since installing the envisalink I have setup programming section 012 in my DSC alarm to enable the keypad lockout feature. After a set number of wrong codes it locks the keypad for a set duration of time. I figure it protects me some from a brute force alarm code attack if somehow someone gained access to my eyez-on portal account.
Please don't think I am trying to say the the portal does not have good security. I am just pointing out that auto arm disarm from the portal is maybe not the best in terms of security. If you want that feature look into a home automation device that can integrate with the TPI.
Re: New Feature Requests
The Android app needs help!
My biggest gripe with it is that it uses the native keypad to enter alarm codes. This is very error prone. How about an alarm pad style interface with big fat buttons?
The Status alarm page has a rather small right arrow button to go to details (picky, picky).
I would prefer a user option that would take me directly to the Status page or arm/disarm page without having to select the device first.
The icon that takes you to the Commands page is far from intuitive. I'd much rather have a "commands" button just like you have an "arm" button.
I think that the Arm page layout could use a lot of work. I know you need to support even low resolution devices, but it is rather a pain to have to scroll way down to the "arm with code area. Part of the problem might be that you take up a lot of room with (1) the "Arming options for Partition x" title and the titles/borders around each section. (2) do you really need to have "Code" entry boxes twice? How about Code once with "Arm" "*9 Arm, Away Arm, Stay Arm?
The Away Arm and Stay Arm buttons could be colored differently to indicate that they were "without code" style arms. (3) Do the Code text boxes really need to be that big? as far as I know there aren't any supported alarm systems with codes greater than 6 digits (maybe 4).
I hit "Stay Arm". I got a big yellow box with a close X on it. What is the X for?
The phone still say and allows "Arm" to be pressed. If it IS armed then it should say Disarm. If it isn't yet armed, but is in the process of arming, the Arm button is still active. Is this because you can change between a stay and away arm?
As far as I can see the Status page never changes to "armed" or "disarmed" after you perform either action. How about an occasional refresh? I have to tried a lot of things to get the correct "arm" status to show up and for the button to change name. I'm not sure what I did to get it to do it. I know that I went to "Events" and there was a "opened" event even though the page was still showing armed. I know that you don't want to do a lot of status update while the user is sitting at the status page, but I really would like to know if the system is armed or disarmed before opening a door.
Does the Status page have a refresh button or is it supposed to auto-refresh? If there is a refresh button I can't find it. If it auto updates it does it quite slowly. If there is an auto update and it is as slow as it appears there should be a large/easy to use refresh button. If the auto update is just slow, then a countdown or progress bar to the next update would be very nice.
I've been a software engineer for 25 years, but I'm not a graphics designer. Regardless, there is definite room for substantial improvement.
My biggest gripe with it is that it uses the native keypad to enter alarm codes. This is very error prone. How about an alarm pad style interface with big fat buttons?
The Status alarm page has a rather small right arrow button to go to details (picky, picky).
I would prefer a user option that would take me directly to the Status page or arm/disarm page without having to select the device first.
The icon that takes you to the Commands page is far from intuitive. I'd much rather have a "commands" button just like you have an "arm" button.
I think that the Arm page layout could use a lot of work. I know you need to support even low resolution devices, but it is rather a pain to have to scroll way down to the "arm with code area. Part of the problem might be that you take up a lot of room with (1) the "Arming options for Partition x" title and the titles/borders around each section. (2) do you really need to have "Code" entry boxes twice? How about Code once with "Arm" "*9 Arm, Away Arm, Stay Arm?
The Away Arm and Stay Arm buttons could be colored differently to indicate that they were "without code" style arms. (3) Do the Code text boxes really need to be that big? as far as I know there aren't any supported alarm systems with codes greater than 6 digits (maybe 4).
I hit "Stay Arm". I got a big yellow box with a close X on it. What is the X for?
The phone still say and allows "Arm" to be pressed. If it IS armed then it should say Disarm. If it isn't yet armed, but is in the process of arming, the Arm button is still active. Is this because you can change between a stay and away arm?
As far as I can see the Status page never changes to "armed" or "disarmed" after you perform either action. How about an occasional refresh? I have to tried a lot of things to get the correct "arm" status to show up and for the button to change name. I'm not sure what I did to get it to do it. I know that I went to "Events" and there was a "opened" event even though the page was still showing armed. I know that you don't want to do a lot of status update while the user is sitting at the status page, but I really would like to know if the system is armed or disarmed before opening a door.
Does the Status page have a refresh button or is it supposed to auto-refresh? If there is a refresh button I can't find it. If it auto updates it does it quite slowly. If there is an auto update and it is as slow as it appears there should be a large/easy to use refresh button. If the auto update is just slow, then a countdown or progress bar to the next update would be very nice.
I've been a software engineer for 25 years, but I'm not a graphics designer. Regardless, there is definite room for substantial improvement.
Re: New Feature Requests
Are you talking about the android app developed by forum member mikep?Ken98045 wrote:The Android app needs help!
My biggest gripe with it is that it uses the native keypad to enter alarm codes. This is very error prone. How about an alarm pad style interface with big fat buttons?
http://forum.eyez-on.com/FORUM/viewtopi ... 6cd4f0085e
Or are you talking about the eyez-on mobile portal accessed through your phone's browser?
Re: New Feature Requests
I was referring to the android web applet per eyez-on.com. I wasn't aware of the other.
I thought that eyez-on had an android specific version of their web page, but I guess I was wrong. In any event, I should have said the the mobile web page needs help I guess.
I was thinking about volunteering to do an app even though I'm not an android guy. I guess that's been done. I'll take a look at what's there.
I thought that eyez-on had an android specific version of their web page, but I guess I was wrong. In any event, I should have said the the mobile web page needs help I guess.
I was thinking about volunteering to do an app even though I'm not an android guy. I guess that's been done. I'll take a look at what's there.
Re: New Feature Requests
OK, I looked at the DSC Keypad app. The UI looks good and works well, but it looks like it is intended to work only from your local network since there is no security. Is this true?
I did see the related DSCServer. That apparent looks like it requires a full time data connection on a phone or tablet. I'm not doing that on my phone due to bandwidth and battery concerns.
What I'd really like is something like the web app, but with with a better UI and real time status updates. I don't necessarily need real time data unless I'm actually viewing the application since the eyez-on notifications are mostly good.
If I were to do an app like this I'd have an app running on my home PC using port forwarding. I'd then have the home pc running the connection to the envisalink. I'd have the Android alarm monitor app make a secure connection to the home PC. Only as long as I'm viewing the Android app I'd have real time data. Since I would only have real time data while I was looking at the app I wouldn't needlessly consume battery. Obviously I'd provide for arm/disarm, sms/email capability. I'd probably also have the home PC app send a "special" SMS message that would sound and alarm and bring up the Android UI when event I'm interested happens.
If the DSCServer Android app has those kinds of capabilities it is not apparent from the app web site.
If there is some other app that would do what I've described let me know. Otherwise I may start working on an app like that if there is any interest. I know not everybody keeps their PC always on. I do because I have other apps running.
I did see the related DSCServer. That apparent looks like it requires a full time data connection on a phone or tablet. I'm not doing that on my phone due to bandwidth and battery concerns.
What I'd really like is something like the web app, but with with a better UI and real time status updates. I don't necessarily need real time data unless I'm actually viewing the application since the eyez-on notifications are mostly good.
If I were to do an app like this I'd have an app running on my home PC using port forwarding. I'd then have the home pc running the connection to the envisalink. I'd have the Android alarm monitor app make a secure connection to the home PC. Only as long as I'm viewing the Android app I'd have real time data. Since I would only have real time data while I was looking at the app I wouldn't needlessly consume battery. Obviously I'd provide for arm/disarm, sms/email capability. I'd probably also have the home PC app send a "special" SMS message that would sound and alarm and bring up the Android UI when event I'm interested happens.
If the DSCServer Android app has those kinds of capabilities it is not apparent from the app web site.
If there is some other app that would do what I've described let me know. Otherwise I may start working on an app like that if there is any interest. I know not everybody keeps their PC always on. I do because I have other apps running.
Re: New Feature Requests
The DscServer is intended to run on a dedicated tablet/phone that you leave hooked to your home network rather than the phone you carry around with you. It works as a proxy for the envisalink, adding encryption, fan-out, email and text messaging (if you activate it on your phone network), and it keeps a log. It will also email/text you if the tablet loses power, internet connectivity, the connection to the envisalink, etc. There's a java version for the PC but it has less function than the phone version (I haven't had requests for much additional). It's cheaper and more reliable to keep a tablet/phone always active within your network than keeping a PC on - the DscServer runs on a modest phone (I use a LG P500H for mine, runs a few dedicated apps including this one and my thermostat server).
The DscKeypad app can hook up to the envisalink directly from within your network, remotely through an SSH proxy, or remotely to that DscServer. It's connection isn't active all the time unless you use the widget. It's really dual purpose - remote access from your phone (though you can use the eyezon service for that) or locally so you can use a tablet within your home instead of buying and wiring additional DSC dedicated keypads.
The idea is hook up that dedicated phone to contact your personal phone via email (I use that for zone alerts) or SMS (for alarms, loss of connectivity, power, etc). You pop up the DscKeypad from your phone whenever you get a message you need to check out.
Hope this helps! Thanks for the feedback on the DscServer app description, I'll try to beef it up.
Mike
The DscKeypad app can hook up to the envisalink directly from within your network, remotely through an SSH proxy, or remotely to that DscServer. It's connection isn't active all the time unless you use the widget. It's really dual purpose - remote access from your phone (though you can use the eyezon service for that) or locally so you can use a tablet within your home instead of buying and wiring additional DSC dedicated keypads.
The idea is hook up that dedicated phone to contact your personal phone via email (I use that for zone alerts) or SMS (for alarms, loss of connectivity, power, etc). You pop up the DscKeypad from your phone whenever you get a message you need to check out.
Hope this helps! Thanks for the feedback on the DscServer app description, I'll try to beef it up.
Mike
DscServer for android/linux/windows: https://sites.google.com/site/mppsuite/dscserver
Re: New Feature Requests
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.
Regardless of timestamps, I really don't need to see all the closing activity that SHORTLY follows openings. What do you think ?
I want to also add my thanks for what you have done. I had a tough start up, but I have come to really appreciate your work.
I have a slightly different solution to the problem EV3_fan presented above that I think will accomplish the reduced traffic and not require as much programing changes on your part. I would like to see the email and SMS messages of open and then close events that occur within a short duration (say less than 2 second apart) be sent as one message. So that in the EV3_fan scenario of the door opening and closing within a few seconds, I would receive just one email/SMS message showing the zone went close/open/close or open/close/open. Often times emails and SMS are slow to arrive anyway, so I wouldn't think it would be a big deal to anybody if you waited a few seconds to see if the zone status changes back before you sent the report. I use to work in the power industry where much equipment is remotely monitored and controlled. It was very important to us to know when a switch went through a double or triple transition and that was exactly how it was logged (e.g. open-close-open). Most RTU (Remote Terminal Units) were set for a 10 second scan however when an RTU reported an event, our central computer would force scan all the RTUs in the area every one second. We would still get reports of double transitions. What do you think?
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.
Regardless of timestamps, I really don't need to see all the closing activity that SHORTLY follows openings. What do you think ?
I want to also add my thanks for what you have done. I had a tough start up, but I have come to really appreciate your work.
I have a slightly different solution to the problem EV3_fan presented above that I think will accomplish the reduced traffic and not require as much programing changes on your part. I would like to see the email and SMS messages of open and then close events that occur within a short duration (say less than 2 second apart) be sent as one message. So that in the EV3_fan scenario of the door opening and closing within a few seconds, I would receive just one email/SMS message showing the zone went close/open/close or open/close/open. Often times emails and SMS are slow to arrive anyway, so I wouldn't think it would be a big deal to anybody if you waited a few seconds to see if the zone status changes back before you sent the report. I use to work in the power industry where much equipment is remotely monitored and controlled. It was very important to us to know when a switch went through a double or triple transition and that was exactly how it was logged (e.g. open-close-open). Most RTU (Remote Terminal Units) were set for a 10 second scan however when an RTU reported an event, our central computer would force scan all the RTUs in the area every one second. We would still get reports of double transitions. What do you think?