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(*):
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
[sup]*[/sup] In UI6 Machines, the process is just to run:
[tt]# opkg update
opkg install tcpdump
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