Anyone have any links to a plugin example that only provides simple Radio Button entry (for a “mode” to be used)? Concept being LUUP code will then utilise the current “mode” the user has set the mode to…
MultiSwitch has eight buttons. Any or all of them can be configured as Radio buttons. See MultiSwitch.
thanks Rex - I’d actually loaded that one in but not realised it could be set for radio buttons - sounds good - I’ll look into it
[ as soon as I get my VeraLite working again after constant Luup resetting after a LUA error, per my post [url=http://forum.micasaverde.com/index.php/topic,28391.0.html]http://forum.micasaverde.com/index.php/topic,28391.0.html[/url] 
]
Once you get up and running again, I have a couple of suggestions for checking Lua code before committing it to Vera scenes or Startup Lua. It may help prevent a recurrence.
ZeroBrane Studio for Vera is a fully-featured IDE and debugging tool for Lua on Vera. It runs on a PC but executes the Lua directly on Vera. There is a licence fee but, for me, it has been worth the money.
I created a tool specifically for checking code for Vera scenes. It is nowhere near as powerful as ZeroBrane but it runs the code in protected mode in the same context as scenes and Startup Lua so can help spot problems without crashing Vera. See LuaTest.
that sounds good Rex re ZeroBrane Studio. I’ve actually already been using LuaTest which is great. Many thanks. I just in this case took only a line of two of what I thought was simple code (but forgot to initialise a variable) and scheduled it’s running against a scene & whamm.
So I guess the learning is not to schedule any LUA code to run unless you’ve run it once (unscheduled) without issue then? Still seems a little hash that one little bug in a line of LUA that you put into the LUA window of a scene could cause the system to come crashing down with no way out no?
By the way, what do you recommend for persistent variables you want to use across scheduled runs of some LUA code? Do you have to say, set them up as globals in the startup script first?
So I guess the learning is not to schedule any LUA code to run unless you've run it once (unscheduled) without issue then?
I usually run it once through LuaTest before sticking it in a scene. I’ve been coding for more years than I care to remember but I still make dumb mistakes. ;D
Still seems a little hash that one little bug in a line of LUA that you put into the LUA window of a scene could cause the system to come crashing down with no way out no?
I think you were unlucky with that one. You must have found one of Vera’s weak-spots (there are quite a few). A syntax error in scene Lua will get you an error message and, if you search through the log, some slight diagnostic help. LuaTest does a better job! Lua’s approach to undefined variables is both a blessing and a curse. It is good practice to code such that a nil value is handled appropriately.
By the way, what do you recommend for persistent variables you want to use across scheduled runs of some LUA code? Do you have to say, set them up as globals in the startup script first?
Global variables are lost when Vera restarts. You can, as you say, initialize them in Startup Lua. I usually just write code that recognizes a nil value and auto initializes it.
local LastUpdateTime = SavedUpdateTime or 0
...
SavedUpdateTime = LastUpdateTime
If you want persistence across restarts, there are a couple of approaches:
Use one of the variables in the VariableContainer plugin. These can contain any string - remember to convert to a number before using it in calculations.
Add a State Variable to any device. This is done simply by writing a new variable. It will be saved and restored along with all the other device variables when Vera restarts. It is good practice to use a custom service ID to avoid any contention with existing variables. This will also be saved as a string.
luup.variable_set("urn:mixedup-com:serviceId:Persistent","SavedUpdateTime",LastUpdateTime,123)[quote=“RexBeckett, post:6, topic:184169”]If you want persistence across restarts[/quote]thanks. Hadn’t come across this plugin yet. Actually to confirm, when I said “restarts” I guess I was referring to each time a scheduled piece of code runs I want it to access a persistent variable (e.g. totalTime = totalTime + X). Not really a restart then. But I guess my question is whether VariableContainer plugin approach is required for both (a) a true veralite restart as well as (b) persisting variable data across different scheduled instances of the code running? Or is there a more straight forward approach for the latter?
Or is there a more straight forward approach for the latter?
If you just need persistence across multiple executions of a scene then a global variable is the simplest approach. Just make sure that you replace a nil value with something sensible so that it self-initializes. I’m sure you already know that all scenes, Startup Lua and LuaTest run in the same context so make your global names unique. Plugins have their own contexts.
Actually I didn’t know so thanks for pointing this out.
[quote=“RexBeckett, post:6, topic:184169”]If you want persistence across restarts, there are a couple of approaches:
Use one of the variables in the VariableContainer plugin. These can contain any string - remember to convert to a number before using it in calculations.
Add a State Variable to any device. This is done simply by writing a new variable. It will be saved and restored along with all the other device variables when Vera restarts. It is good practice to use a custom service ID to avoid any contention with existing variables. This will also be saved as a string.[/quote]
What about writing to file yourself, or sqlite? Less tied to a plugins installation, however would there be Vera specific disadvantages that I may not aware of?