EyezOn Forum

OK, so I've had my Envisalink board installed and running beautifully for about a month or so now and LOVE it.
However, on occasion, I'm receiving a "Network Supervision Fault" every few days. The fault seems to last about a minute and then restores itself.
Since I'm managing my own network, I'm very familiar with any problems that might occasionally exist and I'm always quick to fix them. In each case, at the time of the fault message, there is absolutely nothing going on in regard to my network that I can find to be causing this. Checking router logs, modem connect/disconnects, etc.

So my question is threefold:
1) Can I assume that the Eyez-on service occasionally "belches" like this and that is normal?
2) Is there a way to confirm there was a momentary glitch, like some event log that is posted by Eyez-on to confirm some disconnect or unavailability issue occurred?
3) at what point does the system 'tattle' that it cannot talk to the mother ship? Is it dynamic (at the time it happes) or pre set, like checking in every 1 minute? Please explain.

Hi

1) No, we haven't had a single outage since November of 2012 on any of the alerting servers.
2) See above
3) 10 minutes is the current supervisory window. If "mother ship" doesn't hear from "shuttlecraft" within 10 minutes it will gererate this fault. Update pings happen every 30 seconds.

Customers who have frequent supervisory faults account for about 2% of the installed base.

There are three known causes for frequent supervisory faults (other than a real outage).

1) DNS issues. The Envisalink uses DNS to determine which of the alerting servers it is supposed to communicate with. It updates its tables every hour or so. We've seen some routers that masquerade as DNS servers give erroneous information. You can test this by looking at your local Envisalink's network statistics page during an "outage". If you see that your Envisalerts server is something crazy like 127.0.0.1 or 255.255.255.255, then you have this problem. Try using Google's public DNS at 8.8.8.8 instead.

2) El cheapo Ethernet switches. The Envisalink uses 10BaseT UDP packets and some switches, over time, seem to forget which port the Envisalink is on and fail to route the outbound packets. If you reboot your switch and the Envisalink comes back, you have this problem.

3) Firewall/Router security settings. The Envisalink uses periodic UDP based communications that can annoy some firewalls. They tend to think this type of traffic is "bot" related and block them. As well, newer routers have global security features and many customers have reported that their traffic was being peridodically blocked by the router. Lowering their security setting (whatever that does) has solved their problems.

I hope that helps

Thanks for the detailed info, it is appreciated.
Regarding #3 answer, what is the difference between the update pings and non-communication for 10 minutes. If you don't mind, can you explain that, I'm wondering what the update pings are.

Thanks

The Envisalink is a client to the Alerting server. The Envisalink sends an update packet every 30 seconds regardless of event activity. This not only updates the alerting server with panel status, but is also used as a heartbeat for supervision.

When I switched from my 2DS connecting to the eyez-on servers to an EVL3 which connected (via Connect2Go) to my alarm company's monitoring server, I too would get network outage reports, but from my alarm company. Like the OP, my network was working fine. But I noticed the problem seemed to be when there was something happening requiring significant sustained traffic (eg. streaming as video or a big download).
On a whim, I made an adjustment to my QoS (Quality of Service) settings on my router. I'm using DD-WRT firmware on my router, and I'm not afraid to mess with the settings within (and there are plenty of them). Other routers may not have the same flexibility/functionality.
Basically, my QoS settings allow you to set priority by MAC, along with some limits. I just plugged in the MAC of my EVL3, with LAN settings of 100kbits (since EVL3 packets are quite small). I'm not a QoS expert, but based on my understanding the best way to describe this setting in English is "for data chunks of under 100kbits, this MAC gets top priority to the Internet over all other devices/traffic".
As soon as I made that change, I have never received an unexpected network supervision notice again.

Brad.

bpsmicro wrote:When I switched from my 2DS connecting to the eyez-on servers to an EVL3 which connected (via Connect2Go) to my alarm company's monitoring server, I too would get network outage reports, but from my alarm company. Like the OP, my network was working fine. But I noticed the problem seemed to be when there was something happening requiring significant sustained traffic (eg. streaming as video or a big download).
On a whim, I made an adjustment to my QoS (Quality of Service) settings on my router. I'm using DD-WRT firmware on my router, and I'm not afraid to mess with the settings within (and there are plenty of them). Other routers may not have the same flexibility/functionality.
Basically, my QoS settings allow you to set priority by MAC, along with some limits. I just plugged in the MAC of my EVL3, with LAN settings of 100kbits (since EVL3 packets are quite small). I'm not a QoS expert, but based on my understanding the best way to describe this setting in English is "for data chunks of under 100kbits, this MAC gets top priority to the Internet over all other devices/traffic".
As soon as I made that change, I have never received an unexpected network supervision notice again.

Brad.

That is an excellent suggestion, thanks!

I am on vacation, far away from my panel and I received a text "supervision fault" at 0842 this morning. I have had the envisalink 3 for about three months and have never had this fault. I logged onto eyez-on and see my panel listed as "off line".

I then contacted my internet provide and learned my modem is off line. So at least this time I am positive the problem is not an eyez-on issue. I am wondering if in the future is there an easier way to determine the cause of the fault message. Can I rule out the outage is an eyez-on computer problem by the fact that I am able log on and see the "off line" message?