EyezOn Forum

Update: I got an alert from Envisalerts at midnight last night about the wireless zone with the low battery. I'm glad that I did finally get a low battery alert from Envisalarts and I'm glad that it shows in my Eyez-on portal event log. I got the Verbose trouble status code on 11/7 at 11:18 (am). (W...

Ok, Interesting.

FYI, I still have the iControl (Telguard) portal connected. It was able to send me an alert mentioning the specific zone.

(It's connected to the panel via RS-422. I've never been able to find any docs on what protocol is available via the RS422 connection.)

Panel: DSC 1832 v. 4.6, Wireless connected via TR5164. EVL-4 01.01.114 I had a wireless zone report a low battery this morning but the only thing I've gotten from the EVL via TPI was a verbose trouble status, and the only thing that shows on the Eye-zon portal is that the panel status indicates trou...

I'd like to see some moderately flexible user definable alerts. Maybe some of this exists in Envisalerts+ but I couldn't tell from the description. One of the things that I liked from the iControl portal is setting alerts for zone openings that should rarely ever have activity regardless of alarm s...

Is there any plan to support theses IT-100 commands : LCD Update (Command 901) LCD Cursor (Command 902) LED Status (Command 903) Beep Status (Command 904) Tone status (Command 905) Buzzer status (Command 906) Door chime statut (Command 907) Thanks Ok, now I finally understand why there are still so...

I'd like to see some moderately flexible user definable alerts. Maybe some of this exists in Envisalerts+ but I couldn't tell from the description. One of the things that I liked from the iControl portal is setting alerts for zone openings that should rarely ever have activity regardless of alarm st...

A helpful enhancement would be to syslog loss of connectivity to the envisalerts service and restoral. (Last night I had an internet outage which was logged by the envisalerts service as you would expect. However nothing was syslogged with firmware 01.01.114. I'd also love to see TPI codes for loss ...

I guess. Bit academic though - doesn't matter if it's invalid 'cause it's short or invalid 'cause it's a bad checksum, I discard it in either case. What I'm trying to sort out is whether the envisalink itself has sent an invalid message or it's been corrupted while traversing the network. Which is ...

IIRC valid messages will always end in CRLF, and be a minimum of 5 data bytes -- 3 digit command/response code + 2 digit checksum.

So if you've got less than 5 data bytes and/or the message doesn't end in CRLF, you've got a short read and couldn't have something valid to checksum.

Didn't see any response to this. Could someone let me know if I'm not understanding things correctly or whether this is/was a bug? I think 849 Verbose trouble status (849) should have been sent/updated via the TPI with bit 3 - Failure to Communicate set, when the panel decided it had FTC trouble. Su...