LuaTest - A Tool for Testing Scene Lua Code

LuaTest is a tool for editing and testing scene Lua code. It runs on Vera as an http request handler and provides several advantages over Test Luup code (Lua):

[ul][li]Allows code to be saved in files on Vera[/li]
[li]Displays the return value from your code[/li]
[li]Reports code errors directly[/li]
[li]Indicates code execution time[/li]
[li]Shows output from print statements[/li]
[li]Provides values of local variables after a runtime error[/li]
[li]Creates lists of variables and actions for your system[/li]
[li]Includes option to display all variables for any device[/li][/ul]

To install LuaTest, upload the attached file RBLuaTest.lua using APPS → Develop Apps → Luup files → Choose file → GO and then restart Vera.

Enter the following code into APPS → Develop Apps → Test Luup code (Lua) and click GO:

local rblt = require("RBLuaTest") rbLuaTest = rblt.rbLuaTest luup.register_handler("rbLuaTest","LuaTest")

When used this way, the handler will work until Vera is restarted. The three lines can, alternatively, be added to Startup Lua for permanent availability.

To open a new or existing Lua file on Vera, enter:

<veraip>:3480/data_request?id=lr_LuaTest&file=<filename.lua>

Where is the IP address of your Vera (without the <>). If <filename.lua> starts with a / it is assumed to be a full pathname otherwise it will be located in /etc/cmh-ludl/. If you do not provide a filename, the default luatest.lua will be used. If the file does not exist, it will be created when you save your code.

The following command will open LuaTest to edit the default file luatest.lua in the default folder /etc/cmh-ludl/:

<veraip>:3480/data_request?id=lr_LuaTest

Now enter your Lua code in the Code box. You can use simple copy/cut/paste commands by clicking the right mouse button.

You can use the buttons provided to create lists of the variables and actions for all the devices on your system. These are presented in a form that allows simple copy/paste into the luup.variable_get(…) and luup.call_action(…) calls in your code.

The Show Device Status button will open a new browser tab and display all variables for the specified Device Number. The values will be updated whenever the browser page is refreshed (usually F5 key). You may use the button to open pages for multiple devices.

When you have finished editing your code, click Save Code to create or update the file. Now you can click Test Code to have your code run as if it was in a scene. A new browser tab will open to show the results of the test.

Lua’s print statements can be very useful when testing and debugging. With a few strategically placed in your code, you can quickly determine which sections are being executed and the value of key variables. You can leave the print statements in your code, if you wish, as Vera usually sends the output to a black hole.

There is now a LuaTest User Guide initiated by Tim Brien.

Edit: 18/03/2014 19:05 Version 1.1 Added edit and save functions.
Edit: 21/03/2014 11:24 Version 1.2 Minor tweaks and cleanup.
Edit: 22/03/2014 13:38 Version 1.2.1 Simplified runtime/code error messages.
Edit: 23/03/2014 14:08 Version 1.3 Added Device Variable List and Value buttons.
Edit: 24/03/2014 09:03 Version 1.4 Added Device Actions List.
Edit: 26/03/2014 09:39 Version 1.5 Added Device Status button.
Edit: 03/04/2014 13:16 Added link to User Guide.
Edit: 03/04/2014 14:26 Version 1.5.2 Allows use of pretty(…) function. See here.
Edit: 20/08/2014 09:08 Version 1.6 Fixed Device Actions List for UI7.
Edit: 12/01/2018 14:00 Version 1.7 Updated for security enhancements in Vera 7.27.

LuaTest 1.1 now allows you to create, edit and save Lua code as well as providing a useful test facility. See the first post for the code and instructions.

LuaTest 1.2 uploaded. This is just some minor clean-up of the UI. If you modify the code, the Test Code button will not work until you have saved it. This helps to avoid the now why didn’t that change fix the problem, problem. :wink:

See the first post for the code and instructions.

Nice job … do you trap/capture errors ? That’s what noobs need help with.
If you don’t already you can wrap the code in pcall and print the error.

[quote=“RichardTSchaefer, post:4, topic:180205”]Nice job … do you trap/capture errors ? That’s what noobs need help with.
If you don’t already you can wrap the code in pcall and print the error.[/quote]

Thanks, Richard. Yes I am trapping errors using xpcall so I can use my own error-handler to dump the local variables from the stack.

If any of the MCV forum admins are reading this, I like to propose this be made a pinned item on this board.

Anything that helps people to test lua/Luup code has to be a good thing, especially when the current way via the browser is so cumbersome.

I for one love it !! :slight_smile:

LuaTest 1.3 uploaded. I have added a couple of additional buttons:

Device Variable List opens a new browser tab and produces a list of existing variables for each device on your Vera. The serviceId and variable name are formatted as required for luup.variable_get(…) calls so may be copy/pasted straight into your code. Incorrect serviceId and variable names are one of the most common reasons why scene code fails. This should help to avoid the usual pitfalls.

Note that, just because a variable exists, it doesn’t mean it is useful. Some are rarely, if ever, updated by Vera and/or plugins.

Device Variable Values is as above but also includes the current value of the variables. This can be helpful to see what your code should receive from a luup.variable_get(…) call. I made this a separate button because some device variables can have very long values which can make the listing hard to follow.

It will take a few seconds for these lists to appear after you click the buttons. The code has to run through a fairly long list of data to extract the relevant items.

See the first post for the code and instructions.

LuaTest 1.4 uploaded. I have added a button:

Device Action List opens a new browser tab and produces a list of possible actions for each device on your Vera. The serviceId, action name and argument list are formatted as required for the luup.call_action(…) function so may be copy/pasted straight into your code. Using an incorrect serviceId is one of the most common reasons why scene code fails. This should help to avoid that.

Note that, just because an action exists, doesn’t mean it will actually do anything. The list is produced by reference to Vera’s invoke function. Not all devices support the full range of actions that Vera thinks that they should. :wink:

It will take a few seconds for this list to appear after you click the button. The code has to run through a fairly long list of data to extract the relevant items.

See the first post for the code and instructions.

@RexBeckett
Just to let you know how much I appreciate this tool, although I did not have the time yet to try it. This will definitely help me learn (a little) LUA/LUUP. I do have some ideas I want to try it for: SendData to a Danfoss LC13 to send it a schedule.

Thank you!

Thanks @C4Vette. Let us know how you get on with it.

I recommend sprinkling print statements through your code so you can see which parts are working and which are not.

... print("Initialisation done.") ... print("Status is " .. status) ...

LuaTest 1.5 uploaded. I have added another button:

Show Device Status opens a new browser tab and shows the values of all the variables for the device specified in the Device Number field. The displayed values may be updated at any time by refreshing the browser page (usually the F5 key). You can use the button to open status pages for multiple devices. You can also open a second page for the same device so you can compare before and after results.

To use this function directly (without needing to edit or run Lua code), enter the following in your browser:

<veraIP>:3480/data_request?id=lr_LuaTest&list=values&device=123

Replace with the IP address of your Vera and 123 with the number of the device to be displayed.

See the first post for the code and instructions.

OK, I’m a noob, but this is amazing! I agree with parkerc that it should be pinned, and i also think it should be make a permanent addition to Vera. (with a nice royalty paid to RexBeckett

I’ve been reading and playing and trying to code some things, but it’s SO difficult to know what is going on (or what I’m doing wrong). I’ve been able to accomplish things in other languages, but it helps to “see” my mistakes. This tool allows that. I spent most of yesterday trying things, and came back today to find a bunch of enhancements!

This is just to say THANK YOU to RexBeckett.

There is now a LuaTest User Guide. Credit to @Brientim for much of the preparation.

LuaTest 1.5.2 uploaded. This is a minor change to make LuaTest’s pretty(…) function available to your code.

If you use Lua’s print function on a table , it just shows that it is a table - which isn’t much help. The function pretty(…) will expand the table and expose every element. It can be used with any type of variable but it does not expose the contents of a function, userdata or thread.

print(pretty(variable)) will print the contents of variable.
print(pretty(variable,“Name”)) will print the contents of variable prefixed by Name=

See attached example.

See the first post for the code and instructions.

Hi @Rex

I’m using 1.5.2 and store my test files on my NAS (so I can update them via TextTastic on the iPad)

When I click on my test URLs (e.g.) …

http://192.168.1.234:3480/data_request?id=lr_LuaTest&file=/nas/luatest/test.lua

it brings up the LuaTest code window with the code populated very quickly, however when I click on the Test Code button, it can freezes for a while and then not return the results page?

I’m doing some test but wanted to make you aware just in case there was something you could think of I could look for?

I'm doing some test but wanted to make you aware just in case there was something you could think of I could look for?

Your code is not ending. This could be an infinite loop or a socket call without a timeout that does not get a response. Default timeout for sockets is 0 (which means forever).

This is a brilliant addition to the Lua-user’s toolbox.

I do seem to have run into trouble, though, and have narrowed it down to this one-liner example:

print (pretty {[table] = "a table index"})

…which causes a Luup restart (memory problem?)

I know that a circular structure will also break [tt]pretty[/tt], but this is not one of those.

Sounds great and will certainly help debug. This is the kind of tool vera needs to provide to really jumpstart development.

Sent from my iPad using Tapatalk

This is a brilliant addition to the Lua-user's toolbox.

Thank you, sir. I appreciate your kind words.

I do seem to have run into trouble, though, and have narrowed it down to this one-liner example:
print (pretty {[table] = "a table index"})

…which causes a Luup restart (memory problem?)

That’s an interesting example. The variable table is of course an existing table that contains Lua’s table manipulation functions. I would imagine that Lua is trying to tell you that you cannot use it as a table index but when LuaTest tries to dump the locals off the stack for the error diagnostics, it shoots itself in the foot again. On my system (LuaTest 1.5.2) it is reported as error in error handling but it does not crash Vera. I shall have to add some logic to catch recursive errors…

print (pretty {[“table”] = “a table index”}) works just fine.

I know that a circular structure will also break pretty, but this is not one of those.

pretty attempts to spot circular structures (cycles) and avoid endless loops. It works fine on sockets which contain references to themselves.

I cannot find the file “L_DataWatcher” being required in the LUUP files list. I have Vera2 with UI5 and wonder how many files are missing like this since average consumer doesn’t plan to be developer. I did upload the RBLuaTest.lua file and permanently install it. A nudge in the right direct please?