Do I need to communicate to the Eyez-On server?

[jwshome]

Hi,

I'm a new user of Envisalink 4 (connected to an Edemco Vista 20P panel and Homeseer). I'm getting about a dozen errors a day of the following type:

Code: Select all

Apr-22 03:03:34 ERROR Receiver::Run() A socket error has occured: Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
Apr-22 03:03:45 ERROR Receiver::Run() A socket error has occured: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.

I'm assuming this error occurs when the Envisalink tries to contact the Eyez-On server - is that correct?

Most of the time the Eyez-On server connection is maintained. However, I have no need for it. Is there a way to turn it off and only work through my LAN? I have other ways of accessing the Envisalink and alarm system externally that are apparently more reliable.

Thanks in advance for any help.

Regards.

[GrandWizard]

The TPI, Envisalarms, and Envisalerts are completely different services and do not interfere with each other so your error is releated to something else.

Whomever told you that accessing the Envisalink remotely is more reliable that the Envisalerts service is lying to you. You should NEVER expose your Envisalink to the public Internet. The only safe and secure method of accessing your Envisalink remotely is through the Envisalerts service, either through Eyezon, or one of the other service partners.

[jwshome]

Thanks for the quick response. I should have been more precise in my comments. I would, as you suggest, never expose the Envisalink for remote access. I have secure remote access to PCs on my home network, and I would use that access to locally access the Envisalink via the LAN. It would be the PCs, not the Envisalink, that is exposed to the outside, and I am confident about the security of that connection.

The errors I listed below indicate that the Envisalink cannot access the Eyez-On cloud server from time to time. From what I have read, this has been a consistent problem that has been widely reported for at least three years, and Eyez-On has not solved it, so my assumption is that it won't be solved. Given that, I'd prefer to disconnect the Envisalink from the cloud server, but I don't know two things:

1. If I disconnect from the cloud, will Homeseer no longer be able to communicate with the Envisalink? and
2. How do I disconnect?

I will also post this question on the Homeseer site to see if the author of the plugin can answer either or both questions.

Thanks.

[GrandWizard]

No, you are incorrect. There is no relationship between the TPI, which homeseer uses, and the Envisalerts service. The error you are reporting is an error with HomeSeer.

Secondly, the Envisalerts service has been rock-solid for more than 12 years now. If there was a widely reported problem wouldn't you see this widely reported? Please feel free to highlight a single posting on this forum substantiating your claim, otherwise you should retract it.

If you don't want to use Envisalerts, then just cancel your Eyezon account. It won't fix your problem as your problem lies with HomeSeer.

[jwshome]

Hi,

Thanks. Apologies if I am using the wrong terminology or making incorrect assumptions. I'm trying to infer from your responses the actual answers to my questions, and I think we are making progress in that regard. Let me know if what I've written below is correct.

First, I am guessing that "Envisalerts" is a cloud-based platform, while the "TPI" is used to directly access the EVL4 on the LAN. If that is the case, then you are of course correct that the problem indeed cannot lie with Homeseer reaching out to a remote server, but exists in the socket connection between the Homeseer plugin and the EVL4 right on the LAN itself. That is very helpful to narrow the range of the problem. Thank you.

Second, socket communications obviously involve two-way communications, so either side could be "at fault". Whether or not the Homeseer plugin is properly formatting its communications to the EVL4, or whether the server on the EVL4 is not responding properly, is an issue that can only be resolved by the technical people on both sides talking to each other. I take it, from the tone of your prior post, that you have little interest in engaging in that discussion because you are convinced, perhaps with good reason, that the problem lies on the Homeseer side. I have no idea if you are right or wrong, by the way, only that you are disinterested in participating in finding the solution. If I have that wrong, please let me know; otherwise, I will work exclusively with the Homeseer folks to try to resolve the issue, as I have no other choice.

Third, I am inferring from your comment that I can simply cancel my Eyez-On account, that the EVL4 will continue top operate with Homeseer. The installation instructions that come with the EVL4 note prominently that one must set up an Eyez-On account before installing the EVL4, so I was concerned about cancelling it, but knowing that I can is very helpful. Thank you.

Fourth, I apologize for suggesting that something is wrong with anything regarding any of the Eyez-On products mentioned above. I have no specific knowledge that any of the Eyez-On products have any problems whatsoever, and retract any accusation of product flaws that I made in prior posts.

Finally, in response to your request that I identify a single post on this issue there are, for the record, ten posts on this site discussing socket errors:

• by K-Man on Feb 02, 2017 at 3:03 pm

• by ptr454 on Feb 02, 2017 at 1:08 pm

• by vladb on Apr 06, 2016 at 2:40 am

• by dumbo25 on Jan 21, 2015 at 11:24 pm

• by mitalum on Sep 20, 2013 at 3:41 pm

• by K-Man on Thu Sep 05, 2013 at 1:55 pm

• by Z06jerry on Fri Aug 23, 2013 at 10:55 am

• by mitalum on Wed Jul 31, 2013 at 8:00 pm

• by mitalum on Tue Jul 30, 2013 at 8:29 pm

• by hypnosis4u2nv on Thu Sep 13, 2012 at 9:56 am

On the Homeseer site there is a post by the Envisalink plugin author that states "This problem has been reported by other users, it looks like the envisalink board is stuck for some time before it can successfully communicate again. I reported the problem to Envisacor but I don't think they have ever figured it out." A search for "socket error" and "envisalink" on the Homeseer site returns more than 500 posts, though I'm sure not all of them relate to this error.

I suppose my point is that it was not ridiculous for me to inquire about a problem that I am experiencing nor to note that others seem to have experienced similar issues. I probably should not have opined on who was at fault, and for that I'm sorry. I realize supporting these types of products is often a labor of love and we all need to be grateful to the community for the efforts the experts put in to help us. You're obviously one of those experts, and your responses have been quite useful in helping me address this issue.

Thanks.

[Crikey]

On the Homeseer site there is a post by the Envisalink plugin author that states "This problem has been reported by other users, it looks like the envisalink board is stuck for some time before it can successfully communicate again. I reported the problem to Envisacor but I don't think they have ever figured it out."

This is ever the problem with integrating products from multiple vendors.

I'll only note that the author of that comment writes "it looks like," not, definitively, "it is."

The only way to gain more insight, lacking the two development teams working hand-in-hand, would be for some enterprising individual well-versed in network communications to replicate the problem on a LAN with a network hub, rather than switch, or a network switch with port mirroring, so they can run something like tcpdump or wireshark on an independent computer and analyze just which node is doing what. Or not doing, as the case may be. Of course: They'd then have to convince the guilty party they're at fault, and why, which may likewise be no mean feat.