So I have decided to upgraded my Vera Edge to 7.30, I have around 80 Scenes (lots of them time triggered), then I have around 180 devices (virtual/physical - AC powered, battery powered) and 8 plugins (Netatmo, Althue, Harmony Control, System Monitor, PLEG, Countown, Virtual Switch. …). Upgrade process took around 15 minutes, I have logged into and except Fibaro Wall plug which has been renamed to S1 Switch I cant observe any issues. Reloading the pages is quite faster and after creating new Scenes/Modifying Devices I dont observe any blue bar informing me about Reload of LUA/Z-wave network starting etc. I have disabled nightly heal so lets see if I will hit some issue in future. Memory available after update 81 MB (83 MB before) and CPU Usage 0.3-0.4.
I am posting in the hope that Vera staff seems it. I know the update for the VeraPlus has been pulled for improvement (and fixing). I have purchased a new Schlage lock and the beta update does fix the inability to add PIN codes. However, unlike my older Schlage lock on another door, the new lock will not accept restrictions to the PIN code validity.
I don’t know if that is in the work for the fixed update, but I am hoping that will be the case.
I unfortunately updated my VeraPlus to 7.0.30 a few days ago. Remote access is very unstable and my Imperihome app (which I use as my interface) constantly loses its connection now for long periods (and thus control) and randomly reconnects. The Imperihome app has 3 pref settings for connecting: ‘force local’, ‘force remote’ and ‘automatic’. When I choose ‘force local’ all is fine and connection is rock solid. The other 2 settings are flaky. Thus confirming its an issue between VeraPlus remote network negotiations with Mios servers. I logged a help request with Vera who came back to me next day (credit due there) with the following suggestions to try which unfortunately haven’t made any difference or improvement. I am posting their suggestions to let others on the forum try them and evaluate etc.
Vera’s suggestion:
"Click on the tab: Apps> Develop apps> and on the option: Test Luup code (Lua) please paste the following codes one by one and click on: Go, once You have a positive confirmation message, continue with the next line, once You finish all the lines, the controller will reboot, please wait till You have all the lights on solid on the controller and do the log in one more time.
os.execute(“rm -r /overlay/etc/mios_backup.info.old”)
os.execute(“rm -r /overlay/etc/cmh-zwfw/z*”)
os.execute(“rm -rf /overlay/etc/cmh/ergy && rm -rf /overlay/etc/cmh-firmware/mios && reboot”)
After this, the controller will reboot by itself, please let me know if your unit behaves better after this"
Hi @rafale77 , sorry for the question, but, even being used to IT and software, I am totally new to the VERA internals.
My question before to execute the lua codes you developed:
Once there are executed, both the poll to non battery devices and the wakeup nnu will be disabled forever? Or if a value is put in the apropiate parameter again will they work again? Or, if one need to have the poll and/or the wakeup nnu again working should the codes be executed again with some changes in the parameters?
Thanks again for your work and help
Javier
Hi rafale77,
Sorry but I didn’t develop or come up with these lines of code, they were part of the Vera support reply email. Even though I’m reasonably familiar with Vera, I don’t know much about the coding apart from being able to set up SSH keys in Vera and SSH from Vera into a Mac to play sounds. I’ve no clear idea to be honest what those commands are doing. I ran them twice and nothing improved. Polling Battery devices isn’t recommended anymore since they are always asleep so its a waste. A battery device will wake and report any change in its sensor value. Polling permanently powered devices is needed. I’d be surprised if the Vera code could wreak anymore havoc than their update already did.
The lua codes add or edit a couple of variables in your user data. They are completely reversible.
These commands you posted delete some files which are used either only during the first initial factory setup of your vera or during an old firmware which has long been performed and are therefore superfluous and clutter the flash drive of the vera. Support is advising you to delete them in order to free up some space because one of the failure modes of the vera is to run out storage space and crash or otherwise wearing out the few memory cells it has available by overwriting user data to it constantly because the storage is too full. They will do nothing to your zwave network for speed or reliability.
If you desire to look into details, you can read up on the following threads about “storage” and my post about “zwave explained”
Nothing worrying about the commands support have given, but can’t see how it’ll improve your connection stability, as Rafale says
C
@rafale77 thanks for your answer. Going a bit further. I was able to find parameters “PollSettings” and “PollNoReply” in the non-battery devices, so, I feel it would be easy to reverse them to the current value they have.
BUT I wasn’t able to find parameter “DisableWakeupARR_NNU” in the battery devices. Is it a new one that will be added to the variables tag of advanced settings of the device? for reversing it (in the case it is needed), will be enough to put it at value “0”?
Same question for “EnableNightlyHeal”, the reversing process will be to put it a value of “1”?
Finally, if the night heal is disabled, that I fully understand your point and explanation, but a heal is needed, which is the way to do it manually (sorry for this surely basic question coming from a newbie in this products).
Thanks again and regards.
Javier
Yes these are new for 7.0.30. They are listed as such in the release note in the first post of this thread and even have a wiki associated. You will also not see controller attributes (these are special variables which are for the controller and not the device) on UI7 for reasons which escape me but this is by design.
A manual heal can be lauched by going to the settings/z-wave settingds/advanced menu and clicking “update neighbor nodes”.
@rafale77 Again, thanks so much for your fast answer.
I will try them tonight or maybe tomorrow.
Best regards.
Javier
Hi, I’m lost about why these aspects ‘DisableWakeupARR_NNU’ and ‘EnableNightlyHeal’ are coming up in the current context. Why are people concerned about the nightly heal? Doesn’t it take place automatically? Re my situation of constant vera mios-network dropouts and crashes, Vera support have emailed to say they will try to downgrade my Firmware to 7.29 as it seems the current one is going to take ages to fix…I opened up the usual SSH tunnel for them but my system is crashing so often I don’t think they will be successful. BTW, when is crashes the ‘internet LED’ and the ‘wifi LED’ flash alternately. I have to power down the Vera to get it back online for another while. Question: Does anybody on the forums have a link to 7.29 so we could all try to factory reset and downgrade to the allegedly stable 7.29?
regards, Denis
I succesfully updated my Vera Edge to 7.0.30. It took about 7-8 minutes. No issues.
With one of my Vera Plus, I was having stability issues through the Mios servers. The specific Vera was constantly flipping between available and not-connected within the launch portal. For some reason, that specific Vera had “Failsafe Tunnels” selected in Net&Wifi settings . Unselecting that stabilized that Vera connection to Mios servers.
They are current because in 7.30 they can now be modified. People are concerned because it’s not necessary and causes all sorts of issues. There’s a great piece of in depth analysis:
C
Folks, apparently the Vera Edge, according the earlier posts, has NOT been adversely affected by the update, only the VeraPlus. Vera support recognise there is a major issue and have admitted (to me anyway) they are working away on a new upgrade. ‘Niharmehta’ is having the exact problems I’m having. I’ll try his solution but I would have thought one should leave those ‘failsafe’ tunnels ACTIVE precisely because they are meant to avoid loss of remote control & access to your Vera. In this case of 7.30 there must be some kernel/network monitor problem which is going berserk and cutting off the connection. Once again, does anyone have a link to 7.29 cos I’m losing patience with Vera and want to try my own downgrade option to 7.29. regards, Denis
Network monitor issues are know if you read deeply throu the thread.
Also, if you look at rafele77 posta, downgrade is not working because you won’t restare the old kernel.
@niharmehta, @Catman and @Domoworking are correct.
Let’s take this one step at a time:
You are reporting a low level crash very similar to the X-mas light mode on the vera plus which @rigpapa has dug very deep into he has reported higher on this thread to be related to a recovery mode the vera gets into under some connection failures detected by the network monitor program running in the background of the vera. On my production unit I have killed that program for years because I never understood what good it does besides crashing my vera at very inopportune times until someone told me here that it is needed for the mios connection. I have disabled that connection also for years.
Now in your case you may have an extreme case on the edge which is pretty rare and from my tests, I found out that it is triggered by the new kernel installed by 7.30. That kernel change is much less extensive on the edge but it is not easily reversible. A downgrade to 7.29 will not revert the kernel upgrade… You can only upgrade. I managed to revert mine by doing a factory firmware flash which is very risky and I won’t recommend to anyone unless their unit is already bricked.
The other things about wakeupNNU etc are about zwave network management and should not be confused with.
Hi, thanks for the clear explanation, well laid out. Just to clarify I have a VERAPLUS NOT a VeraEdge. So it looks like I’m experiencing the ‘X-mas’ light mode as rigpapa has reported. It’s worrying if what you say is true that a downgrade to 7.29 will NOT fix my /9and everyone else’s) problem. It’s worrying that Vera Support even suggested it would fix it! Does anyone really understand the finer details of all this…?
Furthermore, if you ‘killed’ the network monitor and the mios connection, then how do you access your Vera remotely? Are you using a VPN tunnel?? The mios server remote access seem spretty elegant to me and has always been stable for years until now… regards,
To clarify, I HAD the problem regarding connection stability which has been resolved since clearing that setting on the specific Vera. My other Vera running 7.0.30 did not exhibit this issue (and did not have Failsafe Tunnels enabled). My understanding has always been that Failsafe Tunnels should not be enabled other than very unusual circumstances. It was not a failover to secondary tunnel in case MIOS tunnels are down. This issue may be one in both the Plus and the Edge, but since I only have 2 Plus units, no way for me to know. I probably enabled it in some past troubleshooting on that Vera and forgot about it until the problem is caused with the beta.
Thanks Niharmehta, a very clear explanation of the real role of the ‘failsafe’ tunnels. I had the wrong idea.
I assume you do still use the mios servers so I will try your suggestion of disabling those failsafe tunnels and report back soon.