I have been having uncommanded house mode changes for a long time, but it’s not related to the latest update. It happened today again.
Fortunately I do not have sirens. When I see unintended lights off / heating off when home, I log in to Vera Plus and always see something like this on top of the screen on blue highlighted background:
“Error in LUA scenes or events”
I just manually reload the engine, the error goes away, and I manually change the house mode to home.
I have a scene that switches house mode to away when all variables in the multiswitch plugin are zeros (each person has its own variable in the multiswitch). I verified that the miltiswitch still shows everyone home, but Vera sometimes randomly enters this “Error in LUA scenes or events” mode and every variable returns as zero during that time, so all scenes break. A reload solves this issue.
I don’t know why Vera sometimes shows “Error in LUA scenes or events” which breaks everything. There are no actual errors, and a reload clears this up.
I have not seen this in quite some time and used to be something which would pop up after after a luup reload gone wrong. It looked to me like it was something mistimed between the different functions during the reload which would lead to either some of the scenes or the lua code to not be read properly and at the time I suspected that the engine was trying to read these while the lua interpreter was not ready.
That being said I have also seen a rash of other oddities ranging from the ghost sensor trips to this:
On one of battery operated devices, you can see here that this device wakeup time is 2 days before the last poll success. How could this ever happen? This caused the device to be flagged “cannot detect” even though it was just tripped 2min prior. The reason why this is impossible is because, on a battery operated device, a poll occurs only upon wakeup. I looked at the logs and indeed I see a “wakeup did a poll” at that time. So… the luup engine just did not update the lastwakeup variable and it has been this way for several days because this isn’t the first time this device is showing up as “can’t detect” and I had to manually change the lastwakeup value 2 days ago. This is indeed the mechanism used by the vera to tag a device being “can’t detect”. It needs to have it’s current os time - lastwakeup> 2x wakeupinterval. And it checks it every minute or so with a routine scrubbing the entire user-data devices for battery operated devices.
It brought to my memory the frequent messages from ALTUI that the user-data have overlapping variable IDs. So either we have some serious bug in the engine, which mixes up devices variable in the RAM or we have some data corruption issues.
Did you just modify the L_PhilipsHue2.lua and change anywhere manufacturer is set = to ‘Philips’ to 'Signify?
i.e
current lua
if v.manufacturer == ‘philips’ then
local manufacturer = “philips”
if manufacturer == “philips” then
new lua
if v.manufacturer == ‘signify’ then
local manufacturer = “signify”
if manufacturer == “signify” then
But my old problem is back - as with every update!
The remote connection is instable and every time I do an update I have to reset the controller several times to get it back stable. It’s getting annoying. What can that be?
Will remove and swap to AltHue as suggested. Thanks!
UPDATE: Yeah, that’s the ticket! Of course, then I had to go add all my Hue lights back to whatever Scene they had been included in. At least with Reactor, since whatever devices go “(missing)” mercifully show their old Dev_ID #, I was able to change a few of them back to their old ID # manually. :-/
Did the update on vera edge 2 days ago. Brick.
Power light off, internet slowly blinking, other two lights on.
Can’t see device from network. No scenes working of course.
Still waiting for support to answer my email. (…)
My main concern is to not lose code I had written in the scenes that took me ages to get right.
My update went quite smooth on my both Pluses, except that I had to power off and on again after recommended 15 minutes of waiting. That was first time when I had to do such procedure, usually controller gets up and running again by itself.
The off/on procedure was needed for both controllers.