I have a Vera3 and EVL3 working quite well together…however, from time to time, the Vera3 has an incorrect status of a wired door contact. It’s happened on multiple zones at different times so it doesn’t seem like a specific problem with one zone, but more of a problem with Vera and the EVL communicating. The problem is that Vera thinks a window is open, but the DSC reports that it is not, and the door physically is not open. Simply opening and closing the door get’s Vera and the DSC on the same page. I have tried to duplicate the problem, thinking maybe that it was a polling/timing error. I tried opening and closing the door really quickly, or really slowly, or repeatedly. I also tried bogging down the Vera with meaningless tasks to see if I can make it “too busy” to properly poll. I can’t seem to manually recreate the problem.
Does anyone have a similar problem and is there something I could try and tweak…possibly polling interval or something?
The problem happens possibly once every second week at most.
A few quick questions that folks will likely need to answer your question:
a) Do you have a lot of Network devices on the Network? (how many?)
b) What version of the Plugin are you running?
c) What version of the EVL Firmware are you running?
d) What “network bits” (Routers, Switches) and/or Brands are between Vera and the EVL?
We’ve seen issues in the past with failing components Network between Vera and the EVL, but also when there are a lot of Network devices on the system (and “lot” isn’t really that big a #)
Anyhow, it’s likely that someone looking to help will need the data to provide potential options.
Side-note: Where possible, attempt to reduce the number of Network components, and improve the reliability of each, in the hops between Vera and the EVL. If we disconnect due to a flakey Network, then it’s possible that we’ll drop events until we reconnect (which can take Vera some time to detect).
One additional consideration is it is neither the EVL3 or your Vera but the browser… You need may also need to look at this as well. When you see this what browser are you using and on what device (computer or phone) was the already opened etc and if you open a browser on another device is the same reflected.
Brientim, it is not the browser. The only way I know there is a problem is when my AC fails to start. I have a scene that monitors all my exterior doors and windows and if any of them are open, it prevents my AC from starting. It’s not a problem that the browser sees an erroneous state, Vera sees it and holds the AC off and prevents it from starting.
Guessed…the answers to your questions are as follows…
a) I have 12 statically assigned IP devices on my network. 5 of which are wireless smartphone/tablets, the Vera,the EV and a PC. The rest are TVs, a sling box, and Ps3
b) Version 0.38
c) Not sure of the firmware…I never upgraded it, but the EV3 was bought new about 3 months ago.
d) both the EV and the Vera are on a 2ft patch cord connected to the same 3COM switch. It is the main switch and only switch. Nothing else is in between the 2devices.
Are you suggesting that an intermittent network issue could cause the issue on a particular zone? When my problem is present, Vera still gets updates on other zones that are changing, it just refuses to update the problem one at the time. I would think that zone updates are done in batch like a binary string containing 8zones at a time as opposed to the bit level.
Lately, I have had Vera and the Envisalink not actually communicating. Vera thinks it is connected, the Envisalink things it is connect (TPI is shown as online), but nothing happens. I have had to reboot the Envisalink (from the local page), then restart LUUP, and it connects.
I think have the latest Vera firmware (1.5.622) and latest Envisalink firmware (01.09.114).
If you have the Envisalink connected to an Eyez-On account, it will autoupdate.
The Eye-On [free] subscription just means that the Firmware of the EVL will stay up to date automatically. Without it, the firmware it’s running will be “fixed” in time wrt the version that was on it when it was originally purchased (with whatever set of issues that FW version had)
In the opening statement, you indicated that some # of devices would get out of sync wrt the Panel, so that’s what I was running with (symptoms wise)
At any point in time, Vera maintains a connection to the EVL (or any other Ethernet/Serial attached device). In the past there have been cases where this link is severed and, when this happens, Vera will take some time to detect that, and then re-establish the connection.
During this “detect-and-reconnect” period, if a Zone changes state then that State-change will be lost. Most state changes are represented one-Zone at a time (no bit flags, a separate message per Zone state change, or Panel state change). Outwardly, which “Zones” get out of sync would thus appear “random” depending upon when the detect-and-reconnect occurs.
In the past, this period of time is “minutes” long (unless Vera itself is restarting and/or rebooting… where it can be longer).
Anyhow, Vera doesn’t actually notify the Plugin that a re-connect has occurred so we’d continue on as if nothing has changed… except we’re missing the state change on one-or-more Zones.
Think of this as if you’re having a phone call with someone, and the Telco drops out 10 seconds of conversation during a “quiet” moment in a discussion. There’s basically no way to tell that the line dropped, and what might have been said during that [short] dropout.
Anyhow, typically we look to work out why the link is being severed, and how often, and thus the questions about the bits of wiring tech holding the system together. If these are “many” and/or “unreliable” then there can be problems, but there’s nothing notable in the description of your stack components.
Only relatively new Vera FW’s have the detect-and-correct logic built in (Technically, it’s a TCP KeepAlive). Prior to that, it would never detect the problem… now it just takes time to detect it, with the problems outlined above.
If you’re technically inclined, you can do the following to see the port#'s used for the EVL TCP Connection:
[tt] root@MiOS_3000eieio:~# netstat -a | grep ESTA[/tt]
If the Port#'s are changing for the EVL’s IP address, over a period of time, then Vera is re-establishing the connection periodically.
guessed…Interesting, informative, and excellent description of how it works…thank you.
Ill try the port monitor thing you mentioned.
I am kind of shocked that it is by-zone-bit-level-type-updates. I am used to industrial PLC logic where io status is sent from device to device on a byte or word level based on time intervals. Bit level is okay and reduces overhead but it would appear to me that there should be a backup. Understandably, if I have a network issue, I should fix it but to not have a way for the system to recover in the event of an error is not ideal. Is there not a polling event initiated by Vera that refreshes all zones status’s? If not, is there a way to force that?
By your description, yes you could likely be correct that I could have an intermittent connection and if so, I should be able to find it, but for others not as technically inclined…and for environments with wiring environments not as ideal as mine, I am sure they must be plagued with this type of problem.
Yes, and no. The current plugin supports both UI4 users, and UI5 Vera users.
UI4 has a nasty concurrency bug where they’ll corrupt settings (etc) if two or more events occur at the same time. I had to push aggressively to get them to fix this for UI5.
By event, I mean say an INCOMING Data message from the EVL and, say, a Refresh TIMER to do a periodic refresh of the system just in case.
If these two occur at the same time then there’s a very high likelihood of putting the entire [UI4] Vera unit into a corrupt state (I had this with several other plugins) and there’s no way for a Plugin-author to know, and thus prevent, this from occurring.
As a result, I’ve avoided putting in any sort of poll-me logic. It could be added, but would have to be conditional (and by default, off) to avoid corrupting UI4 User machines.
The best option would be for MCV to add an event that formally notifies us when they Connect (or Reconnect). We have one then they STARTUP, and another when we get INCOMING Data, but there’s no event point representing when they CONNECT. If that were present, it would be the sweet spot for adding the code to re-establish the cache of settings (even if some of the locally derived data were a little stale, like the computed [tt]LastTrip[/tt] timestamps in some cases)
That said, it’s about 2% chance they would ever implement that… so I’ve never formally asked for it.
I’d still like to get to the bottom of what’s causing it though, but that might require the Envisacor Engineers to step in. They’ve done this in the past, and made a few fixes to address it. Ultimately they’re TCP-based, so they really should know if an event they’re trying to send out is not ACK’d, and they should keep it in a queue for some period waiting for the KeepAlive’s to restore the connection. This is also how they’d know the connection was dropped, and would update their TPI status. When the TPI reconnects, it would then get all the information that was waiting…
This is the main advantage of the IT100 over the EVL-3 units. They are truly “wired” together.
Best Home Automation shopping experience. Shop at Ezlo!