DSC Alarm Add On Lost IP of EVL4

Thought I would bring this to your attention in case you have similar symptoms.
One of my customers had a problem with their Vera that had stopped arming and disarming their system.
Turns out their brand new Vera Plus LOST the EVL’s IP address in the settings of the DSC’s add on.
This kind of thing does not happen with other systems I use.
Entered the IP address again and things were back to normal.
In case you are wondering, this systems was locked down with no updates allowed as I know how they can screw things up, especially with Vera.

Anyone else had this problem?

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:

  1. Make sure the EVL4 is on a fixed IP address (static or DHCP reservation);
  2. 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. “”). 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.

1 Like

@rigpapa and @Jamr I use IP reservation in the routers. I found this to be the best for the evl4, it as @rigpapa stated creates a static ip based on an assigned MAC address in the router so when power is lost or an IP refresh occurs any IP reservation will maintain the connection when all is powered back up and running.

Thanks for the details. I was assuming that Vera is using cheap memory that somehow fails.
Yes, I always make sure the IP is static through the device itself. Since this is a client, most of the time I do not have access or do not own the router so I can not change the IP reservation settings there.
Seems that Lua bit is the thing to do since it seems Vera is creating software created chaos.
I assume I can do this over and over for every network device I use with Vera?
Where do you find this stuff Rigpapa?

Yes, you can force assign the IP address the device attribute as often as needed, no problem. If you need a port number as well for a device, don’t forget to include that.

This particular issue, as I said, is from observation of behavior on some devices I work with. Not everything in the Vera world is fully documented, so some things are left to be discovered. I’m a big believer in sharing accumulated knowledge… good karma.

1 Like

You can log in to the EVL4 and assign static there also. It will keep even if power is lost. Once logged into the EVL4 go to the network page. (just in case you were unaware of this).

Yes, thanks.

OK, I Added your recommended code to the Vera and after clicking OK it restarted the Lua, as indicated by the blue status bar at the top but nothing to say is was complete or that it was successful. Is this normal?
Also if I have to change the EVL4 IP, will this Lua bit override the IP I put in the add on? If so I am assuming I will have to remove or change the Lua bit to the new IP?

No news is good news, where Startup Lua is concerned, usually. If it doesn’t work, you see an error message that startup lua failed, but just to be safe, you should check the LuaUPnP log file for messages as well.