Based solely on empirical evidence, it is my belief that when Vera’s native connection/socket communication method is used and the connection to the device is lost and cannot be immediately re-established, Vera launches into a search for the device by using the MAC address to try to find its new IP address–the assumption being that DHCP dynamic addressing has simply allowed the device to move to another address, so Vera needs to find it. The MAC address doesn’t change, so it’s a good way to search.
Sometimes, that process fails (e.g. if the system reboots/reloads during the processing before locating the new address, or the EVL4 is offline for too long, cable disconnected or switch it’s connected to loses power, etc.). When it does, the IP address field is left blank, and the device won’t work again until the IP address is restored (since it’s now not going to be restored on its own).
You might help yourself and your customers by doing this:
- Make sure the EVL4 is on a fixed IP address (static or DHCP reservation);
- In the system’s Startup Lua, you can
luup.attr_set( 'ip', 'xxx.xxx.xxx.xxx', evl_device_num ) to force that fixed IP address onto the device every time the Vera restarts, thus (hopefully) automatically recovering from lost IP problems without a “truck roll” on your part.
BTW, this is the same process/mechanism, I believe, that also causes the port number to be lost when it is added in the “ip” attribute field (e.g. “192.168.0.2:3199”). Vera may find the device, but it seems to just rewrite the new IP without considering that the port number is in there too, so then the new IP is correct but the port number is lost and the device can’t connect anyway.