Unresponsive Vera Plus

Tue Oct 1 09:57:02 EDT 2019

The "device is not responding" followed 30 seconds later by the operation
also happens occasionally with my Vera Plus getting commands from Amazon
Echo.

It's a problem with the Vera.  Try doing a power cycle to clear out garbage
and the cache.

--Mike

On Tue, Oct 1, 2019, 8:04 AM James Sentman <james at sentman.com> wrote:

> I don’t THINK that this is related to the other problem. But it’s always
> possible. There are many things to experiment with if the Vera is just
> being slow though.
>
> You can narrow down where this is happening by turning debug mode on.
> (control click on the interface instance in the interface list window to
> find the toggle) that will spam the log a bit but it will also tell you the
> exact time it took for the Vera to ack any command that we send to it. Once
> the Vera has accepted our command it goes into their job queue for actual
> processing. So if it goes quickly to the Vera, but doesn’t happen for some
> time there are a lot of potential reasons. The most likely is that the Vera
> is trying to query a node that is not responsive. I THINK that when a query
> is outstanding on the network it won’t make any other requests on it until
> that either times out or finishes. You can test that for sure by unplugging
> a module somewhere, then in an XTension script sending a query for it and
> immediately trying to control another light. There are other reasons why
> the network might be busy at any given moment as well but thats probably
> the most common. If you can figure out what device is not available you can
> either fix it, remove it from the network or just turn off Veras automatic
> poll to it. That might solve the problem.
>
> Another reason why it might be slow to send a command can be due to
> plugins on the Vera itself. I’ve seen some 3rd party plugins that seem to
> create a huge amount of CPU load slowing everything down until they are
> removed. If you’ve got any Vera plugins installed i’d experiment with
> turning them off and see if that makes a difference.
>
> Lastly it can just be interference or poor routing to the specific device,
> but it might also be a device that it is routed through that is causing the
> problem. The Vera should update the routing when such a thing happens, but
> you can force it to for any node that is often a problem by going into the
> advanced, or one of those control tabs in the vera interface and asking it
> to reconfigure and/or update it’s neighbor nodes. You can do that from the
> Vera interface or from within XTension via the  verbs I added to the UI7
> interface for that like:
>
> tell xUnit “the unit with a problem” to reconfigure()
>
> and then
>
> tell xUnit “the unit with a problem” to updateNeighbors()
>
> you shouldn’t do them both at the same time I dont think and I would not
> issue them for every node on the network at once as the Vera will timeout
> on such things after a while and just give up ending up having done
> nothing. But doing this for a specific unit or 2 that are having a problem
> is not a bad idea. There used to be a “heal network” command in the older
> Vera versions but that is gone and while you can technically still force it
> to run people have reported that it can actually break networks on the
> newer systems rather than help them. So I would stick to updateNeighbors on
> the specific units that are a problem and possibly a few units that are
> physically close to the problem units to force all those routes to update.
>
> There is a way in the Vera settings to see how many routes it thinks it
> has to a specific device and to see if there have been many other failed
> ones but it’s all by node ID and not very easy to figure out. A better way
> to see if a unit is being reliable or not is to use the Veras own
> reliability numbers. If you have the regular background polling turned on
> for units then they will have a unit property set in XTension of a number
> between 0 and 5 that corresponds to how reliable that node has been in
> returning a poll. The best way to display that for everything in XTension
> is by creating a “custom column” in the Vera Units list. Open the Vera
> Units list and control click on the headers of the list. Select “Insert
> Custom Column” in the drop down enter “PollRating” as the Unit Property
> Name and call the column Reliability or something similar. I would also
> click the Draw centered in column checkbox but thats up to your own
> aesthetic ;) Most of mine are either at 0 because they are no longer in the
> network and I’ve failed to remove them (which is something else you should
> do, don’t let devices you’ve physically removed stick in the list as the
> Vera will keep trying to poll them which can hang up the network) or are at
> 5 meaning they are returning all the polls. I have a few that are between
> 4.5 and 5 which are OK too. My worst unit that is working is an older
> appliance module in my bedroom that controls an air filter thing which
> shows a 1.67 and it does indeed take a lot longer to respond sometimes.
> Don’t know why it doesn’t respond, it’s in the same room with several other
> devices and switches it should see all of them, but it doesn’t. I’ll try to
> update it’s neighbor nodes right now as a matter of fact and see if it
> makes any difference.
>
>
>
> On Sep 30, 2019, at 12:57 PM, William R Vogel <hightrailrider at icloud.com>
> wrote:
>
> FWIW. I’ve been following the thread re: Unresponsive Vera. Occasionally,
> when I send commands from XT to Vera devices, XT reports that the action
> has taken place but the device does not respond right away. The device does
> change state within a minute of two. No errors appear in the log.
>
>
> Thanks,
>  James
>
>
> James Sentman                       http://www.PlanetaryGear.org
> http://MacHomeAutomation.com
>
>
>
>
> _______________________________________________
> XTensionList mailing list
> XTensionList at machomeautomation.com
> http://mail.machomeautomation.com/mailman/listinfo/xtensionlist
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.machomeautomation.com/pipermail/xtensionlist/attachments/20191001/e0d5e711/attachment.html>