Vera 7.31 Core Firmware BETA Release

The weekly restrictions are implemented in a different way on Schlage GEN5 door locks. We will need to add support in the firmware for these restrictions.

1 Like

After a couple of Weeks with 7:31 beta i must say its very stabile and fast ( exept scenes that still has the Never ending lag).

Good work Dev team!

/ Mattias

Thanks for the reply. I’m glad that you all have added what you have up to this point. I hope you will make this (weekly restrictions) one of the priorities for the next update (at least).

A $200+ lock is an important investment to me.

-LeeTXJD

Progress made yes. I still had to reload luup myself yesterday because of the exact exception you refer to above.

Essentially my entire system is work pretty much flawlessly between openLuup and Home Assistant working in harmony. All of my problems are from the vera “tardiness” which most of the time it is able to recover from and is what is being observed as a lag in command executions. It is a massive annoyance because it often is accompanied with missed sensor untrip signals but occasionally, once every week or so, it is not able to recover. In such a case a luup reload occurs unless the “reload on time jump” is disabled. If luup does not reload then the vera hangs pretty much for ever delaying commands for hours. My analysis of the logs indicate that it is caused by a combination of poor handling of “got CAN” and “NONCE Get Flood” messages with some very weird timeouts in the luup engine, all within the zwave implementation. This was much much worse all the silly maintenance like NNU and absurd nightly heal flooding but is still here at a lower frequency. The delay occurrence has significantly decreased and the frequency of unrecoverable delays/luup reloads only by a little. Both are correlated with network chattiness but I there seem to be much deeper problems at the root. I validated that it is not because the cpu capability (I am seeing the exact same thing with my emulator running a CPU 4x faster) and am never seeing any problem with zigbee. It is in the zwave implementation. It is a problem in the zwave chip firmware either as I have tested various versions and have never seen this on other platforms (Openzwave, HomeSeer, Hubitat). The luup engine is not hanging, it continues to log things but I discovered that it won’t even change housemode or toggle armed/disarmed states when it is in the “tardy” mode. The recovery seems to occur when the number of these weird 20s timeouts all expire and then suddenly all the commands get processed at once and it fails to recover when too many of these timeouts are stacked on top of one another making me suspect that there is some gross problems in the command queue handling but I could be wrong as the logs are not very explicit as to what is happening. Any devs has some inputs/ideas? A number of us have reported these problems for years…

4 Likes

Well the scene lag has been from day one with vera (4 years for me). Its very annoying and back then I was told on the forum that its the popcorn effect that comes with zwave…

But since you can manually turn on say 10 lights almost instant now since 7:31beta I believe in you theory… I am novice in coding but I can figure ut that some kind of que is making the vera tardy…

Im quite surprised that its not something dev has fixed on all this years…

Keep up the good investigateing Rafale!!

/Mattias

1 Like

@Sorin
When is this beta going to be a real release ( GA level )?

2 Likes

It’s not trivial for sure. I’m suffering from the same thing and have coded a couple of fail safe scripts, but I truly hope it’d fixed in the future.

1 Like

when they fix and confirm the couple of issues that require a new beta - eg auto-update flag set to off being ignored and plugins being upgraded against the owners wishes.

There is also a random bug that prevents state change commands from making it to the relevant target device.

There was a lack of understanding back then and some of it is true… you should and will see some lag but of the order of 1-2s even for a large number of commands. Not the crazy random lag we are seeing. Shoving the problem reports under the rug with this excuse has probably contributed to the lack of focus from mios. And indeed as @therealdb says, I don’t think this is trivial. I think a lot of things in the vera have become dependent on this bug but I at least wish that there was some acknowledgement and explanation of it.

1 Like

I still have no issues with lag on 7.31, but I have no scenes though. All automation is in Reactor…

The only issue i’ve seen is that the z-wave inclusion is a bit weird. Some times the devices pop in without the wizard noticing… I exit the wizard thinking it didn’t come in, and there it is…

The issue is not about the scene execution per say but is about the zwave command handling and to potentially the zwave triggers. Even with scenes in Reactor if input and outputs are through zwave, they are exposed to the zwave command queuing problems which is what this lag is about. The major factor is how busy your network is and is a therefore a function of how large it is.

I see. I currently have about 25 z-wave units, where 5 is sensors, so i suppose its not that big (yet)…

I have to admit, since 7.30 my vera edge is more solid than ever before (might also have to do with additions from @rafale77). Only thing nasty is that some device do not return their status back to Vera anymore…

nirgal

19h

@Sorin
When is this beta going to be a real release ( GA level )?

Yes, I would like to know this as well, since I haven’t updated the firmware on my Vera Plus for over a year and would like to do so. Thanks

Same, I’ve now configured Reactor to bounce my Plus twice a week - the main symptom is devices not receiving commands (doesnt matter if it’s Wifi or Z-wave).

I’m not sure how to check why it’s reloading…

C

For kicks, this is what I run on the current unrotated log to see what is going on, based on my analysis of logs, I am able to practically identify the cause of all of my problems:

cat /tmp/log/cmh/LuaUPnP.log | grep "poll\|CAN\|tardy\|flood\| time\|Exit"

If I can’t figure out what is happening then I actually go and open the log to look for additional keywords.

Long explanation:
This command filters the log and only displays line containing the words poll, CAN, tardy, time, Exit.
“poll” can be the source of vera freeze when too many of them are present. It helps me verify that my polling interval and wakeup interval settings change are working by looking at frequency and timing.
“CAN” is the dreaded “got CAN” event which is very frequent on my network and seems to correspond to transmission from my zooz ZSE040/vision ZP5111 4in1 secure class sensors and can be source of…
tardy call backs indicating that the vera has frozen
“flood” shows me the NONCE_Get Flood events at the source of the timeout below.
“time”, I noticed shows me the timeout which also is often a source of tardiness.
“Exit” gives me the line showing the Exit code of the luup reload.

Note that I am rotating my logs only once a day. I have also modified my rotate logs script to do that so it gives me some time to review them.

6 Likes

are you using vera’s scene controller for anything?

That explains a lot! I see quite a few of these:

ZWaveSerial::Send m_iFrameID 2277 got a CAN -- Dongle is in a bad state. Wait 1 second before continuing to let it try to recover. <0x77112520>

I had a reload last night. Will try this

C