I’m getting this error “ERROR : Error in lua for scenes and events”, and noticed that some triggers and schedules are very unreliable lately. I have not changed any LUA scripts lately but some plugins got updated.
If I SSH into the Vera Plus, where can I find the logs for this?
Thanks
You likely recently updated your firmware, right…? This is a known bug in the last three firmware updates and Vera does not seem to want to address it. I even contacted Vera and they said I needed to down-grade.
Yes, the firmware is up to date. I didn’t notice this error before though
This is getting a big issue because the LUA code embedded in scenes is not working, however the same code that I have been using for years works fine on the “Test Luup code” editor.
I recall I uninstalled Ergy (because it doesn’t work) and that might’ve been when the problems started. Reinstalled the plugin, and I see on /tmp/log/cmh/LuaUPnP.log that it created a virtual device (78) that I cannot see on the devices list but it’s indeed doing something.
Other apps seem to work but I don’t have that many apps and I rely on LUA scripts instead, which are not working. So now the house modes are not triggering and heat control isn’t working, which is a major issue.
Firmware version 7.19 should solve the problem with LUA in scenes and notifications for Vera Alerts, because these are just scenes anyway.
You will have to renter the LUA code when the release comes out.
I am also hoping this will increase the reliability of saving data.
Like a number of contributors to this forum I have been suffering with this problem, in my case for a couple of years at least. Mine is a heating application and when the message comes my Vera closes down and we start to get cold. However, I seem to have finally cracked it. Here?s how I discovered the solution which I offer in the hope it will assist others.
I was seeing the error message once every few hours and sometimes once every 1 or 2 weeks meaning that I could not babysit it to see what was going on. In order to gain more data I decided to put a counter in my Start up Lua Code and display it using the Multistring Plugin (this also provided persistence across start ups). To my surprise the Lua engine was restarting several hundred times a day. I could witness the count increasing every couple of minutes or so.
So I now had 2 problems. Why all the restarts and why did only a small number of these result in the Errors message? I raised a ticket with MCV who were helpful up to a point. They advised me that there was something wrong with my Lua code in 4 scenes which were failing by attempting to operate on variables with nil values (uninitialised) although they did not say which variables were causing the problem.
The problem was that I could see nothing wrong with my code. All the variables in question had been declared as global in my startup Lua and the code was giving no syntax errors at start up.
It then occurred to me that the variables in question might emanate from my devices. I have several early design power switches (HomePro ZRP210) causing me to wonder if they were still being supported given the new chipset in the Vera Edge. When I examined the variables in these devices I saw that many of them were empty suggesting that they had not been initialised during the include process so I excluded and re-included the device. This made no difference except that now the devices will not configure. However they still work fine.
I then zeroed all the empty variables in the devices via the UI. The restarts stopped immediately. The restart counter has now remained at zero for several days now and I have not seen the Errors message since.
Which leaves the question as to why the error message was appearing far less frequently than the restarts and here I must resort to a bit of speculation. All the scenes in question (and several more) are time triggered by interval. I have noted that a restart of the Lua engine does not reset these timers. This raises the possibility that one or more scenes may trigger after a restart but before the start up Lua code has been fully executed.
In my case I have several functions declared in my start up Lua which are called from my scenes. It raises the possibility that on rare occasions a scene will have been triggered before the function it calls has been declared. This will give a syntax error - hence the message and the engine stopping.
Since I now have a working system back I have not taken the trouble to prove this but it is at least a plausible answer.
I hope the foregoing helps.
Over the weekend, opened a support case, to follow-up on this.
In the meantime, found that somehow Vera changed the LUUP scripts embedded in scenes so that ‘+’ signs were replaced by spaces, so of course a bunch of scripts went down the drain.
Plugins run fine, so I think this is related to work on the last firmware to address encoding of special characters. Not sure how this slipped from their QA, but regardless, the workaround is to go through every single embedded LUUP script and proof it.
The Vera Plus is running firmware 1.7.2138
[quote=“terencec”]To my surprise the Lua engine was restarting several hundred times a day. I could witness the count increasing every couple of minutes or so.[/quote]Every 6 minutes in my case. There is a userdata save (but I’ve got a red line : UserData::WriteUserData saved–before move File Size: 71373 save size 71373). It is (for me) a root problem for all those restarts.
[quote=“terencec”]In my case I have several functions declared in my start up Lua which are called from my scenes. It raises the possibility that on rare occasions a scene will have been triggered before the function it calls has been declared. This will give a syntax error - hence the message and the engine stopping.[/quote]I’ve got exactly the same conclusion. In some case, the engine starts the scene before the startup. So the fonctions are not declared and the engine crashes.
To prevent scenes triggering before the start up Lua has been fully executed I had it in mind to set a switch as the first instruction in the start up Lua and reset it with the last instruction. This can then be tested in time triggered scenes before the scenes is allowed to execute.
It’s not pretty but I would expect it to work.
As it stands I am now no longer seeing the error message so have no plans to do this for now at least.
Nope. The lua engine crashes. No more luup testing will be possible after a crash.
I believe MCV currently has a design bug (introduced a few versions back) that cause the LUA code entered into the browser to have an extra level of URL decoding of data on the Server, data that was NOT URL encoded in the first place… and that’s why things like “+” symbols were lost (same as % characters).
I believe (but can’t prove) that they screwed up something on one of their mobile apps … And they were seeing some data that looked like it was URL encoded …
so they put an extra call to URL decode on the server side … now they have an asymmetrical use of URL Encode/URL Decode between the clients and the Vera Server.
MCV will be base64 encoding the LUA code in the 7.19 firmware version.
This is a GOOD thing. Because your LUA code is saved in an ascii file (user_data.json) … and certain character sequences can compromise the JSON encode/decode process. If you base64 encode the LUA info there is no way that any LUA code could compromise the integrity of the user_data.json file.
The design bug I described above is what is causing these character sequences in the user_data.json in the current firmware version and consequently causing problems saving/restoring the user_data.json file.
But even without the MCV bug, users could enter LUA code that that would corrupt the user_data.json file. Base64 encoding the data should make it impossible.
But if they do not fix the asymmetrically use of URL encode/decode that they have recently introduced they will still have a problem.
Base64 encoded data still has a “+” character in the data stream. If they do an extra URL Decode … this will be converted to a space character and corrupt the base64 encoded data.
If I am correct … it will fix the save/restore problem … but LUA code could still be corrupted and cause LUA errors.
@Shaigan
Every 6 minutes is when MCV writes the current state of your Vera to the user_data.json file that I was describing above.
[hr]
My analysis is based on my observations of corrupted data in the current firmware version. (An extra level of url decode) … that did not go so far as corrupting the user_data.json. But the corruption is consistent with my thesis.
[quote=“RichardTSchaefer”]@Shaigan
Every 6 minutes is when MCV writes the current state of your Vera to the user_data.json file that I was describing above.[/quote]I understand. This is a probable cause of the restarts. But, I don’t understand the link between this problem and the fact the startup is loaded after the scene luup codes.
That certainly explains a lot.
... and certain character sequences can compromise the JSON encode/decode process.
…but this can’t be true. JSON has no problem encoding any character string, including ones with embedded zeros.
If you base64 encode the LUA info there is no way that any LUA code could compromise the integrity of the user_data.json file.
It can’t anyway (per above comment) but the only thing that this will ensure is that encoded strings are longer. I’m wondering how this might affect compatibility with other apps?
It’s true, of course, that Lua code has caused MCV problems, but that’s usually for hand-encoded Lua in XML files (a heinous practice!)
But if they do not fix the asymmetrically use of URL encode/decode that they have recently introduced they will still have a problem. Base64 encoded data still has a "+" character in the data stream. If they do an extra URL Decode ... this will be converted to a space character and corrupt the base64 encoded data.
I can see that sending JSON, or any other string, unencoded (or doubly-encoded) on a URL GET request could cause problems, and this seems to be more of what you’re describing here?
JSON can encode anything that is properly escaped … I.e. if you have a string that I s URL encoded … Then JSON can encode it.
If you Accidentally URL decode it and it contains single and double quotes it will screw up the JSON file.
If the JSON file contains BASE64 encoded string and it is Accidentally URL decoded the + character for the base64 encoded string will get converted to a space. This will screw up the interpretation of the base64 stream.
The important design principal is that a transfer API needs to be symmetric about its USE of encoding and decoding.
When you violate that you run in spaghetti code trying to work around it and often have lots of bugs … Kind of where the current firmware version is at.
Sent from my SAMSUNG-SM-G935A using Tapatalk
OK, that makes much more sense. Thanks.
I also had the problem of getting “Error in lua for scenes and events”
1 simple mail to Vera support - resulted in a quick answer - telling me what scene triggered the error. problem solved!
[quote=“Shaigan, post:8, topic:193970”][quote=“terencec”]To my surprise the Lua engine was restarting several hundred times a day. I could witness the count increasing every couple of minutes or so.[/quote]Every 6 minutes in my case. There is a userdata save (but I’ve got a red line : UserData::WriteUserData saved–before move File Size: 71373 save size 71373). It is (for me) a root problem for all those restarts.
I’m seeing the “Error in lua for scenes and events” error as well as this UserData::WriteUserData saved–before move File Size: 73791 save size 73791 as well about every 10-15 minutes
does this red message mean lua is rebooting every 10 to 15 minutes?
I followed this from Sorin and I don’t see any incorrect code
[quote=“Sorin”]Hi guys,
Just to ping in. If you are referring to the status bar error "Error in lua for scenes and event ". then you can look in user_data with the following command:
[font=arial][size=13px]VERALOCALIP/port_3480/data_request?id=user_data&output_format=xml[/size][/font]
[font=arial][size=13px]and search for: lua= [/size][/font]
[font=arial][size=13px]And if you see luup code that is NOT encoded and is shown in clear, then, that scene is the issue. Due to latest changes, LUA code in user_data data will show encoded in and it will show something like this : [/size][/font]
lua="aWYgKGx1dXAuaXNfbmlnaHQoKSkgdGhlbgogICAgIHJldHVybiB0cnVlCiAgZWxzZQogICAgIHJldHVybiBmYWxzZQogIGVuZA==" encoded_lua="1"So in user_data.xml …
Correct:
lua="aWYgKGx1dXAuaXNfbmlnaHQoKSkgdGhlbgogICAgIHJldHVybiB0cnVlCiAgZWxzZQogICAgIHJldHVybiBmYWxzZQogIGVuZA==" encoded_lua="1"NOT Correct
if (luup.is_night()) then
return true
else
return false
end
However, on Vera graphical user interface, the luup code will still be shown in clear. The mentioned change is for user_data only.
Also, XA44Owq26HxCq88 - you mention that you Deactivate scene from the mobile app. - We have discovered a recent bug in the iOS mobile app, which is conjunction with scenes that contain luup code, causes the scene to break, by removing the encoding from user_data,. We have reported this and it will be fixed with the upcoming update of the mobile app. So for the moment, avoid Deactivating the lua containing scenes, from the mobile app.
Solution:
Copy the code, somewhere safe → delete it from the scene → Save scene without code → edit the scene again → add the luup code again → double check user data, to make sure it shows encoded.
Hope this info is of help, and makes sense 
but feel free to ask, is something is unclear.[/quote]
Best Home Automation shopping experience. Shop at Ezlo!
© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules