DSC with EVL-3

Guys,

I had occasional LUA failures and the way I fixed it was:

A) Go into my Netgear router and assign a unique IP address to the MAC address from Vera
B) Go into my Netgear router and assign a unique IP address to the MAC address from EVL
C) Connect Vera and EVL via a small hub so they have direct communication and nothing in between
D) Reboot Vera
E) Reboot EVL

I only had 2 or 3 red LUA failures since then (1 month now) but they cleared themselves after a couple of minutes.

Definitely no other device getting that IP. I would only know how to ping the EVL from command prompt. Don’t know how to ping it from Vera

SSH into Vera. Instructions are in this forum how to SSH in.

http://wiki.micasaverde.com/index.php/Logon_Vera_SSH

On windows you will need to download Putty and ssh using it.

If you on a Veralite… You root password is available in /etc/cmh/cmh.conf

Just grab one of you backups and unzip and open that file

I’ve used Putty and WinSCP for datamine setup. Can I just use WinSCP, Open Terminal and ping IP address there? I pinged it from Putty and it never stops…

[quote=“Aegis, post:26, topic:179439”]I’ve used Putty and WinSCP for datamine setup. Can I just use WinSCP, Open Terminal and ping IP address there? I pinged it from Putty and it never stops…[/quote]You can cancel the ping with CTRL C

Great. Pings fine. Thank you. By the way, you are one of the two people (other is Mr Guessed) who Envisacor sites as being a contact on the EVL3. Interfaced with a customer service guy, Michael, who was completely unhelpful who even said people on the forums “aren’t always truthful” instead of offering to do any diagnostics or giving the slightest bit of consideration to what I was telling him. Michael put the blame squarely on the plugin and he doesn’t want to hear any more; apparently he is psychic. I have both devices direct into the router now and so far (only 1 day), no Lua failure message.

@Aegis… Thats tech support 101

it’s the guy who isn’t here’s fault

There are two services support one behind the scenes. Eyez-on Technical Support their services and there are also Envisacor Technical Support who support the hardware and the TPI which Vera interfaces through. I have always received excellent support for their products so do not be discouraged.

If the issues continues, I would suggest the you email support@envisacor.com - see next post

Hey folks, don’t even bother going to eyezon tech-support with any Vera issues. They don’t know anything about our API (TPI) or third-party applications. They are supposed to forward all enquiries to the DSC Plug-in owner whom I work with well. If you want you can get me at support@envisacor.com but really I only handle issuses from developers, not end users. That being said, if you have some good network captures or other data then I will certainly try and help out.

@Aegis, the two issues described in this thread can be summarised as such:

  1. Cascading Ethernet Switches are bad in any environment. Cheap routers/switches that don’t have a dedicated uplink port should not be cascaded. This is because they don’t have enough memory depth on any one leg to remember multiple MACs on any given leg. This results in dropped packets or even complete blanking of a single MAC. Keep your network as “flat” as possible.

  2. Envisalink firmware < 1.8.88 suffered from an ARP table overflow in high broadcast traffic environments. With the help of the good people on this forum we found occasions where the TPI could lock-up due to the Envisalink’s ARP table being overflowed by too much ethernet broadcast packets. This was fixed in July 2012 and hasn’t been an issue since.

Your problem may be related to #1 which might explain why making your network “flatter” has helped. It is hard to say what is going on without a network capture.

Lua failure today after only 3 days of both devices direct into router.

[quote=“Aegis, post:32, topic:179439”]Lua failure today after only 3 days of both devices direct into router.[/quote]Let us know if it fails similarly when both Devices (Vera3, EVL3) are hanging off the same Switch device that you have, as the counterpart to the above Router-attached that you’ve run.

If that fails, then we’ll need some very detailed information on the setup you have running, what make/model the components are, how they’re inter-connected (wired, wireless, etc) to try and narrow it down somewhat.

If you haven’t already, it may pay to switch out the cabling, I had one fail on me the other day, and didn’t realize that the cable had been busted up by the rack moves I’d recently performed. I also found out that some of my AV Gear doesn’t like my [Netgear] switches (sometimes), resulting in all sorts of fun with DHCP (but, in this case, I suspect it’s dodgy Ethernet implementations at the AV Gear end, given the vendor involved)

Hopefully it won’t come to that.

[quote=“guessed, post:33, topic:179439”][quote=“Aegis, post:32, topic:179439”]Lua failure today after only 3 days of both devices direct into router.[/quote]Let us know if it fails similarly when both Devices (Vera3, EVL3) are hanging off the same Switch device that you have, as the counterpart to the above Router-attached that you’ve run.

If that fails, then we’ll need some very detailed information on the setup you have running, what make/model the components are, how they’re inter-connected (wired, wireless, etc) to try and narrow it down somewhat.

If you haven’t already, it may pay to switch out the cabling, I had one fail on me the other day, and didn’t realize that the cable had been busted up by the rack moves I’d recently performed. I also found out that some of my AV Gear doesn’t like my [Netgear] switches (sometimes), resulting in all sorts of fun with DHCP (but, in this case, I suspect it’s dodgy Ethernet implementations at the AV Gear end, given the vendor involved)

Hopefully it won’t come to that.[/quote]

I just put them both into the same Netgear 16 port GbE switch and rebooted Vera. I have another 4 port of the same switch that I had the Vera direct in prior to going direct into the router for the last go round. Everything in my network is Ethernet. Wifi is only used for cell phones, iPad etc. The cable on the EVL3 is a new Cat 5e patch cable and the cable for the Vera can’t be bad since everything else is working fine. Router is a MI424WR-GEN3I. As far as I can tell, when I get the Lua Failure error, everything continues to work fine in Vera and in the alarm, so maybe it is the plugin…

Lua Failure Lua Failure

Aegis,
I’ve setup the following components/versions to do a longer run test:

[ul][li]a) Netgear ProSafe 16 Port Gigabit Switch (model# GS116v1)[/li]
[li]b) DSC Plugin (Latest, from source control)[/li]
[li]c) EnvisaLink 2DS (firmware 01.10.120)[/li]
[li]d) Vera 3 (running UI6, but no material changes otherwise)[/li]
[li]e) My upstream router, and DHCP server, is DD-WRT[/li]
[li]f) An automated pulse-device that’s causing Zone 2 to cycle on/off every 5 seconds. (to simulate events quickly)[/li][/ul]

I’ll let this run for 24hrs and see if there are any issues. If that doesn’t cause any, then I’ll turn off the pulse-device.

Other than that, as indicated before, I’ll need a copy of your log file(s):
a) With Verbose Logging enabled AND;
b) Containing full coverage before AND after the Lua-error appears on your UI.

Without a set of logs covering the transition from the working state to the non-working state, we won’t be able to diagnose this.

That said, I suspect the issue is environmental and caused by some component in your network itself. Given the problems you’re having with DHCP allocations, that’s where you should look heavily first (look at the Lease times/expiry if you have access to that part of the UI’s).

The alternative place I’d look would be something transient on the network that “has” the same IP Address allocated to it (probably statically, but if you’ve set the EnvisaLink module to static, then it’s possible that your Router is doing a dynamic allocation for the same address to something)

Unfortunately, detailed debugging of Networking issues will require you to have a strong knowledge of standard network tools (tcpdump, WireShark et-al) and is likely beyond the scope of what can be done.

[quote=“guessed, post:36, topic:179439”]Aegis,
I’ve setup the following components/versions to do a longer run test:

[ul][li]a) Netgear ProSafe 16 Port Gigabit Switch (model# GS116v1)[/li]
[li]b) DSC Plugin (Latest, from source control)[/li]
[li]c) EnvisaLink 2DS (firmware 01.10.120)[/li]
[li]d) Vera 3 (running UI6, but no material changes otherwise)[/li]
[li]e) My upstream router, and DHCP server, is DD-WRT[/li]
[li]f) An automated pulse-device that’s causing Zone 2 to cycle on/off every 5 seconds. (to simulate events quickly)[/li][/ul]

I’ll let this run for 24hrs and see if there are any issues. If that doesn’t cause any, then I’ll turn off the pulse-device.

Other than that, as indicated before, I’ll need a copy of your log file(s):
a) With Verbose Logging enabled AND; Will this be problematic if I am not logging to USB?
b) Containing full coverage before AND after the Lua-error appears on your UI.

Without a set of logs covering the transition from the working state to the non-working state, we won’t be able to diagnose this.

That said, I suspect the issue is environmental and caused by some component in your network itself. Given the problems you’re having with DHCP allocations, that’s where you should look heavily first (look at the Lease times/expiry if you have access to that part of the UI’s). I don’t really understand lease times/expiry; with static IP, they all just renew, except for Vera I guess

The alternative place I’d look would be something transient on the network that “has” the same IP Address allocated to it (probably statically, but if you’ve set the EnvisaLink module to static, then it’s possible that your Router is doing a dynamic allocation for the same address to something) I definitely do not have an IP address conflict. I have almost all static IPs and no duplicates. I look at my router connections all the time. All static IPs are set from the router. I have no idea if there is even the capability to set the EVL with static IP from the device itself; I don’t see it in the settings. Support has told me to put Vera back in DHCP and see how that goes.

Unfortunately, detailed debugging of Networking issues will require you to have a strong knowledge of standard network tools (tcpdump, WireShark et-al) and is likely beyond the scope of what can be done. I know Wireshark[/quote]

Aegis,

I would also log on to your EVL and disable (uncheck) Disable TPI Session Alerts and this will then send you alert when the drop out is occurring.

Firmware Version: 01.11.127 is due for release soon which will result in it going offline when it is pushed out ( it includes Thermostat support for the 3m/50 and maybe this weekend)

You can disable DCHP on the EVL3 and this will enable you to set it to static IP outside of the DCHP range.

It depends upon how much extra stuff you have running on your Vera. In general, once you’re in the Alarm-system class of user, I’d guess you’d want USB Logging anyhow, but I ran my [Vera2] for a long time without it … but eventually I ran out of runway…and moved to a Vera3… at which point, I had a lot more Devices & Plugins going on, so it’s perm now.

My Vera is currently detached from MCV-Net, with USB logs. As a result, logs aren’t being uploaded to MCV’s servers, and it seems to keep them a lot longer on the box… Barring MCV adding correct, system-wide, support for syslog this is going to be your best bet.

I don't really understand lease times/expiry; with static IP, they all just renew, except for Vera I guess
It depends upon your terminology. Some people use "[i]Static IP[/i]" to mean "[i][Static]DHCP Reservation[/i]", others (like me) use it to mean configured Statically within the Device itself.

The former will undergo the DHCP Lease process, but simply get the same address back. It’s still technically a change, and the exact behavior that you’ll see is up to each attached TCP Device (do they drop connections on renewal?)

The latter will never be involved in the DHCP process, but can certainly confuse the hell out of it if their “Static” address happens to be in the middle of a Dynamically Allocated DHCP set of addresses (which, as you say, you don’t have)

I definitely do not have an IP address conflict. I have almost all static IPs and no duplicates. I look at my router connections all the time. All static IPs are set from the router. I have no idea if there is even the capability to set the EVL with static IP from the device itself; I don't see it in the settings. Support has told me to put Vera back in DHCP and see how that goes.
The EnvisaLink modules can be configured with Static IP (as in, on the Device itself). My test module is set to obtain it's address over DHCP, but it's got a DHCP Reservation in place on my RTR.

Under DD-WRT, DHCP Reservations are given IP addresses that never expire. Again, how the Device actually handles that will vary from device to device. If you can, it would be handy to find out what expiry is being given out by your RTR (as an extra data point)

I know Wireshark
Ok, great. In that case, you can get [tt]tcpdump[/tt] onto Vera using this process(*): http://forum.micasaverde.com/index.php/topic,9156.msg67557.html#msg67557

Then you can grab a binary file of the exact interaction between Vera and the EnvisaLink module using the “host” pcap filter.

On a Vera3, you’ll want something like:

    tcpdump -i eth0.2 -w /var/log/cmh/broken.pcap host <ipOfEnvisaLink>

and it’ll capture packets of the interaction, from Vera’s perspective at least(**). You’ll want to put “[tt]broken.pcap[/tt]” on the USB stick location also, so it has some room to grow.

Anyhow, a binary transfer of this file to the machine running Wireshark, and you can analyze it at the crash periods :wink:

[sup]*[/sup] In UI6 Machines, the process is just to run:
[tt]# opkg update

opkg install tcpdump

[/tt]

I haven’t had a clean UI5 machine, so it’s possible that it’s now available more directly there also.

[sup]**[/sup] Unless you happen to have a SPAN port somewhere :wink: