One item to look out for is that the 2DS, and presumably the 3DS, had “issues” with large number of devices on the Network (their ARP cache was v.small, and they weren’t pinning critical devices into it).
In some cases, such as @oTi’s home network, this led to problems that the 2DS struggled with. In the past, these were partially addressed, at least for the more common cases, in a firmware patch… but people had to register their devices to pick this up. Presumably these patches were bundled into the 3DS when it was made, since it’s newer and has more resources (memory)
We had Vera modified to partially handle these “stale” connection situations by heartbeating the target device. In these cases, Vera should “reconnect” if the TPI is listening…
This should be evidence of this in Vera’s logs, if Verbose logging is enabled.
I hope Eyez-On has solved the problem Guessed just mentioned. That would be highly unfortunate if having a busy LAN could cause a problem like that… Regardless, I’ve got a 2DS in my house, and this problem went away seemingly on it’s own. I’ve got about 20 DHCP leases in my home at any given time. (I’m a gear head) I also know that these devices have new firmware pushed to them without any need of intervention by the user anymore. Chances are good that if you are using a 3DS, you have the best possible scenario.
Some things to check:
Go into the envisalink’s internal web site. username/password default: user/user
Hit the network tab at the top right, and verify it says “EnvisaLink TPI Status” as “Online”. That would mean the Vera is actually logged in. If it says Offline, then either the Vera is dropping the connection, or the envisalink is. You might want to make sure you do not have the “Disable TPI Session Alerts” checked.
In the myconnect2go portal for the envisalink, check out Recent Activity. Look for “TPI Login” or “TPI Session Closed”. If TPI session alerts are on, you should see this fairly routinely in this log.
Not sure what to do if any of these are off, but it might help show how it works, and get you on the right track with your own thinking. You might also try the Eyez-On forums for this. It could be you’d get someone who can help more from the envisalink side of things.
I haven’t re-commissioned a system as yet but my last system I went through similiar with the help @guessed and eyes-on we got to the bottom of it.
I also had issues on a large LAN and it had me stomped because all test were positive. I contacted eyes-on and we they loaded a custom firmware to conduct traces. We identified there was a problem with one of the managed Cisco switches and later on the Cisco router… They both functioned for everything else but was causing the 2DS to drop locally. Removed both from service and no issues.
Hi Brentim,
I’ve noticed that whatever happens with alarm system when Vera is off (like power shortage) is not sensed when Vera is back (door sensors stays on when doors actually are closed) - is there a possibility to “scan” or poll DSC for actual state?
Could it be implemented if possible ? or it’s my system problem only?
If I understand your request, I’m not sure this is possible.
When the power is up and everything is online, state is achieved automatically. This is done through the Envisalink’s TPI, and should be very quick.
The problem is when the TPI link is broken for one reason or another, the DSC nor the Envisalink store a log of tripped sensors and arming states. The DSC panel itself has an event log, but that’s entirely internal and the Envisalink doesn’t have access to it. It’s incomplete in terms of sensor trips anyways. The Eyez-ON cloud service also has a log which is much more comprehensive, generated by the Envisalink when it happens to be online, but that’s behind their secure servers and I don’t think you can play with that either. This information is not stored within the Envisalink itself, it’s just passed on and forgotten.
Polling isn’t done via the Vera, but seems to be updates provided to it by the Envisalink. I don’t think it goes the other way around. I think you’d be stuck having the DSC/Envisalink update the Vera manually with state changes. open and then close the door, and it ought to reset itself in the Vera. If there is some DSC combus command deep in there to query the system for it’s state, then maybe, but we’d need input and a plugin addition from the plugin author for that.
Code 001 is what the Plugin issues at [tt][/tt]. The issue is that if Vera becomes disconnected from any Network-attached entity then it will automatically, and without notification, reconnect.
ie. Vera’s plugin framework lacks any form of [tt][/tt] entry point, to notify Plugins of this significant event
As a result, there’s a chance of missing data whilst we were “disconnected”.
Then, you combine this with a data corruption bug in UI4 that can completely hose a User’s Vera unit, when two or more events occur “simultaneously”, and you start to understand why we don’t automatically/periodically do an 001 on behalf of the user.
If you’re on UI5, and you’re experiencing this issue, then you can always issue the [tt]SendCommand(001)[/tt] yourself, at a time of your choosing, since there’s a Luup ACTION hook for that.
NOTE: DO NOT do this on UI4, it will almost guarantee to corrupt your overall Vera configuration.
That said, if you’re seeing this on a regular basis, then it would be worthwhile diagnosing why it’s getting disconnected so often… because something else is amiss in the overall deployment.
or the Advanced-Scene declarative equivalent.[/quote]
Just a note, that you can’t do this via Advanced Scene, because while the SendCommand option is there, it does not create a text box for you to put in the 001…
I had a situation today where two doors closed at the same time, and while the alarm panel recognized both, Vera only saw one close. I issued the above Luup command to sync and it worked to sync Vera with the alarm. I am planning to schedule it at something like 15 minute intervals. I am (still) on UI5.
Best Home Automation shopping experience. Shop at Ezlo!