Beta 7.31 seems to be the best around at the moment, and were I in your position, I would go there. You can work around the 7.30 Xmas Lights problem by enabling either or both WiFi bands–you don’t have to use it, it just has to be on.
20 days without luup reload (on a pretty quiet zwave network as I was out on honey moon). On the graph each jump corresponds to a cache memory dump which I run daily through a crontab. Seems to have reloaded only due to the disabled “reload on TimeJump” memory leak.
2 Likes
I do run a bunch of plugins but I’m finding a weekly reboot is still required under 7.31.
1 Like
Mine’s not typically making it a week…
C
Pretty good stability for me, haven’t had any random reboots have been running may 7-10 days between reloads.
I’m really happy with how 7.31 is performing also.
Only luup reloads from configuration changes lately but I will try to keep my hands of it to see how long it can go without any reload.
After putting a queue for calls coming from my own code to update virtual device, it seems to become stable for me as well. I’m now between 3 and 5 days. System is very stable.
Do you look at “memory Available” data or “Memory Free” (not available in the main panel, you need to go to variables to see that)?
There is a difference between both of them - “Available” parameter icludes so called “memory cached” which may extensively grow in some cases, while “free” is the real amount of memory which you can use at the time.
So you may see 150 000b of “available memory” when in fact it splits into 1 000b of “free” and 149 000b “cached” and your system is stuck until the “cached” would be cleared.
I created a routine scene on my Veras which checks amount of “free” memory from time to time and makes maintenance tasks if it drop below certain level. I’ve posted it on the old forum and you can adapt it for your own needs.
1 Like
Mine was saying 170 something but TBH I can’t recall which variable I checked.
I just wanted to post an update in regard to the Schlage BE469ZP lock and scheduling PINs.
I am able to program unrestricted pins and daily restrictions for the pins.
However, I am unable to program weekly restrictions. I don’t know why the lock will not accept weekly restrictions, but I have a belief it has to do with how the time of day is communicated. I can’t confirm that.
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
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…