I was in a similar situation relying on GE/CADDX security panel plugin which hasn’t been supported for years. This capability was the sole reason I got my first Vera many years back and without it working, I would need to move on.
I went ahead with the 7.0.31 upgrade on my VeraPlus and it’s working fine as a Z-Wave hub + security plugin with all else (UI, scenes, etc) being handled by Home Assistant on a RasPi.
The only issue I had was a ZCombo smoke/CO detector was showing “waiting on wakeup to configure device”. To clear this, I pushed the test button on the detector to wake it then selected “configure node right now” in the Vera UI. This worked to clear the message but had the ill effect of removing the daughter CO device!
Vera Support was contacted and they first suggested restoring the Z-Wave backup. This worked to restore the missing CO device, but the “waiting on wakeup…” message returned. To confirm this wasn’t a one off issue, I tried to wake/reconfigure again and the CO device went away again. Support then said I needed to exclude/include it again, which I hoped to avoid.
All in all, not a big deal. just restore the Z-Wave network and ignore the message.
@Sorin, I know that there is probably nothing you can do and it is a fundamental design issue with the way the engine is built. I also know that it isn’t the focus of the management and this has been a problem for many years. I sense from the few interactions I had with some of the devs that there is also a great amount of pride holding this flawed design and little motivation to revert flawed implementations but I will ask it again:
Please eliminate all data manipulation routines run during the luup engine loading. I mean all of them. Do not set devices as unconfigured, Do not delete children devices even if they are orphan, Do not create devices. Nothing. This needs to stop. The loading should be a plain reading of the user-data.json and should be done within 1s or 2s. Not 1 minute.
Move all of these user-data.json manipulations into a dedicated menu screen where errors and warning in the configurations are listed and allow users to either ignore them or suggest a course of action instead of doing them without user authorization.
Stop trying to reconfigure the devices when there is nothing to do and the changes are only on the controller side. Example? Changing polling rate of a device or upgrading firmware of any kind. These are also a source of data corruption.
This is what I mean by treating user data as sacred. As it is the firmware is corrupting user data by design and as a side effect makes the luup reloading taking much too long to be (ab)used the way you are (ab)using it.
That is possible and then you can assign the child devices to another room but first you have to check what the vera-nr of this room is and change it in the child device by going to advanced and change the field “room”.
So you still can change the room number of child devices but it is extra work so not user friendly
With what browser do you get that issue? I have several controllers running at 7.0.31 but not having the issue you have (I tried; Firefox, Chrome, Edge).
(yes I am screaming). I have 4 vera units and have been a loyal customer for over 5 years. I went through the firmware bugs in past, rebuilt from scratch, downgraded and restored backups. Been there. I get bugs what I can’t understand is the lack of response and nonsense I’m currently receiving from support. Case is 217686 been open since Sunday.
Vera Plus firmware upgrade went ok but noticed sluggishness. I have Gcal3 plugin and it triggered for no reason at 6am the next day - causing a scene to execute that includes setting the house alarm… not good. Investigating I discovered that the upgraded Vera Plus now has LuaUPnP engine crashing every 10 minutes. Nothing in logs about it, not related to a specific scene, plugin, device - nada. just “LuaUPnP Terminated with Exit Code:0” I have now had 2 vera support personnel, today a Lvl2 engineer, tell me there is nothing wrong with this. The system was stable before the upgrade.
I was hopeful that a downgrade to prior firmware level and a restore would help but I noticed the partitions are now remapped. Why was there not a MAJOR warning that this particular upgrade would cause incompatibility and an inability to revert? These warnings were provided previously.
This particular Vera services a vacation rental, i have guests coming soon and rely heavily on the automation provided by Vera. Delay timers, plugins and scenes are now unpredictable since the engineer might crash in the middle. Please Sorin or someone at Vera, I can’t take the one email per day support response telling me it’s fine - I NEED HELP NOW
Though elsewhere in the forums others have noted these entries are harmless. the CommitToDatabase and subsequent errors occur on these 10 minute intervals and shortly thereafter the unit reloads.
For whatever it’s worth, I have posted about this even during the beta phase of 7.30 and all along through several posts. It isn’t just the drive being remapped, the kernel partition is also changed and that change is not reversible. Yes this should have come with a major warning as not every one reads the forum. Yes they should never spam users with forced upgrade page on the UI. Yes they should never modify your configuration and user data without your knowledge and yes they should never reload luup every time any small thing goes wrong. I compared this to power-cycling (in case you don’t know this takes several minutes) an airliner in mid hair because somebody sneezed and expecting to have no casualties. The design flaws are so elementary and trivial that it really takes all of us a lot of endurance and persistence to stick around. Well I don’t regret spending all the time I did on investigating troubleshooting the vera as I learned a lot in process. Much beyond what I would have ever imagined but I have come to the point where I found myself wasting my time and floored by how absurd and grossly incompetent some the decisions were made. Home automation is unfortunately not quite at the point of being just like an appliance purchase. It requires investing some time and developing a minimum skillset which can become a time consuming hobby. Caving in and spending the time to migrate my setup away from vera has been the most productive time I have invested in this yet.
Enough of my diatribe … I wish I could help more and indeed these log entries look very normal. Maybe the few lines before the exit code 0 would be more helpful. Exit code 0 indicates that the reload was triggered by the luup engine itself but there are many mechanism which abuse this reload process so we need a little bit more logs.
We can only hope that the all new and overdue platform from ezlo will be a game changer.
Devices that have a “Parent” other than Z-wave/Zigbee/BLE do not have an option to be moved to a different room unless the Parent is moved all together.
You can skip this by setting the Variable: ChildrenSameRoom to 0 (on the parent device) as it should be 1 by default.
Then you can adjust each Child device based on your Room Preference.
You can open the Advanced Device Menu of each device and edit the field called “room” to the respective ID of each room you wish to have the device moved into.
This will only happen for devices that are created by a different device than the Z-wave/Zigbee or BLE network.
Hi @ionut.s ,
It is the other way around.
As I wrote I have no problems at all with the non zwave devices. Zigbee and BLE devices I don’t use at all because they simply not work or very bad as you know for a long time already. On top of that it’s a Vera Edge where I have this problem. The majority of my non zwave devices on this Edge are some very popular and well maintained plugins and they still work flawlessly since the update.
So I see this problem exclusively on ALL Zwave devices with child devices. And I never seen this before I upgraded my edge to this most recent hotfix 1.7.4969
And I see it both when using browsers Chrome (desktop and tablet) and MS Edge.
It seems till now I am the only one seeing this, but still I would like some attention to solve this. It is not urgent, my edge still works but it is annoying
I’m having massive problems with 1.7.4969. My Vera Edge is crashing every day to the point that I need to power cycle it. I’ve opened a support request. Any assistance in downgrading would be much appreciated.
updated from 7.0.29 to 7.0.31 on VeraEdge and got messages from our client that some actors developped an own life switching on and off lights several times a day, especially fibaro RGBW modules do that, but also some recently added fibaro dimmer 2.
Any experiences with that issue? Is a downgrade possible or could anybody help me investigating this?
As OF TODAY aUGUST 23 - WHAT IS THE RISK OF UPGRADING FROM 1.7.4453 TO 1.7.4970
I use PLEG extensively as well as DataYours and over 100 ZWave devices.
