I see this message via the Vera portal (and from AutHomation) - any idea what it is referring to and how to fix?
Trouble Status LED Off 841
The Plugin presents the “last” message received on the bus. In your case, it’s a “841” Message, which is indicating that the Trouble-Status LED is restored (unset/cleared, etc)
You’d need to look through your logs to work out what the “Trouble” was, since I only keep the last one. Typically this is more like “Zone Restored” (or similar)
So this issue went away and now its back. It just seems like the envisalink and plugin aren’t talking:
02 09/25/13 23:26:44.621 IOPort::Run RecvFailed 131 close 12 <0x2e4f4680>
02 09/25/13 23:26:49.626 IOPort::Run RecvFailed 131 close 12 <0x2e4f4680>
08 09/25/13 23:26:54.494 JobHandler_LuaUPnP::HandleActionRequest device: 12 service: urn:micasaverde-com:serviceId:DSCAlarmPanel1 action: SetInterfaceType <0x2e0b1680>
08 09/25/13 23:26:54.494 JobHandler_LuaUPnP::HandleActionRequest argument DeviceNum=12 <0x2e0b1680>
08 09/25/13 23:26:54.494 JobHandler_LuaUPnP::HandleActionRequest argument serviceId=urn:micasaverde-com:serviceId:DSCAlarmPanel1 <0x2e0b1680>
08 09/25/13 23:26:54.495 JobHandler_LuaUPnP::HandleActionRequest argument action=SetInterfaceType <0x2e0b1680>
08 09/25/13 23:26:54.495 JobHandler_LuaUPnP::HandleActionRequest argument InterfaceType=2DS <0x2e0b1680>
08 09/25/13 23:26:54.495 JobHandler_LuaUPnP::HandleActionRequest argument rand=0.8822700389445932 <0x2e0b1680>
02 09/25/13 23:26:54.495 Device_LuaUPnP::HandleActionRequest 12 comm failure <0x2e0b1680>
02 09/25/13 23:26:54.495 JobHandler_LuaUPnP::RunAction device 12 action urn:micasaverde-com:serviceId:DSCAlarmPanel1/SetInterfaceType failed with -911/Device communication failure <0x2e0b1680>
The vera is reporting the partition unarmed while it is armed, however from the envisalink website everything looks fine.
Yup, some sort of comms failure.
Anytime you get this type of thing, you’ll want to:
a) Ensure that your EVL is registered with Envisalink in order to get automatic firmware updates
b) Double check ALL of the Wiring & Components between Vera and the EVL.
Item (b) has been cropping up as a failure point more and more, so ensure that you have the absolute minimum number of Network cables, connections points (routers, switches, etc) between them and that these are all “healthy”.
The more things between the endpoints, the more likelihood of a component failure causing a system failure.
Past that, you’ll need to engage the Envisalink team to diagnose the disconnections. They’ve done it for a few people now.
The issue seemed to rectify itself after a few restarts so I dont think its wiring.
Also, when the issue was occurring the Envisalink interface was working properly so I wasn’t sure if contacting them would work.
At one point they had a problem where they’d be impacted by the # of TCP devices on your network. They were keeping an ARP Cache, and this would “overflow” in larger networks.
When it overflow’d, some entries would be thrown out and, if this happened to be Vera’s IP, then they had no way of talking to Vera again. Low level debug on their end showed this, and they made some changes to kinda-sorta fix the problem, but it was still possible.
In these cases, the “regular” logging would always show a healthy EVL, it was only when they put on a diag firmware that they saw the real issue.
Vera will automatically reconnect, when it detects an issue, but it takes a LONG time to do that (minutes). In the meantime, all sorts of state changes can occur in the Panel, and Vera will get out of sync.
BTW: We’ve seen flakey switches and routers cause exactly this problem in some of the Vera setups, so I wouldn’t rule that out even though it looks “ok” when you restart (at that moment in time)