Getting started on the Plugboard
1 July, 2010 - 15:32
I've been frying my brains trying to get started on the Lua scripts to bring some intelligence to my HAH.
I just don't seem to be able to get anything going.
- I have enabled the plugboard in the xap-livebox.ini.
- I have added scipt(s) to the /etc/plugboard folder.
- I am assuming that if I run the script it should have some effect.
- I have tested the RF socket from the WebGui.
My first script is a somewhat confused attempt to turn on an RF socket if the temp get's above 33c.
-- Script to turn fan 1 on via RF when temp hits 33
-- Rev 0.1
--
function init()
register_source('dbzoo.livebox.Controller:1wire.1', "gettemp")
-- register_source('dbzoo.livebox.Controller:rf.2', "getstate")
end
-- This is the xap header for turning RF on function cmd(action)
xap_send(string.format("xap-header\
{\
target=dbzoo.livebox.Controller:rf.2\
class=xAPBSC.cmd\
}\
output.state.1\
{\
id=*\
state=%s\
}", action))
end
-- Get state of RF.2
-- function getstate()
-- state = xapmsg_getvalue("output.state", "state")
-- end
-- Get valid info from sensor
function gettemp()
if xAPMsg.class == "xAPBSC.event" then
if xapmsg_getvalue("input.state", "text") > 33 then
-- state == "off" then
cmd("on")
end
end
end
I know there maybe be a couple of fumbles in this script but at the moment I just want to see the RF switch activate.
I run the script by typing 'lua temp_high.lua' from the console. I'm expecting the RF switch to activate when the temp is above 33(which it is)? Nothing happens! Grr!
Please provide clip round ear, condescending tut and a handy answer to put me out of my misery!
Thanks
Gary
2 July, 2010 - 08:18
#3
What do you mean view the
What do you mean view the plugboard? The C source code is available on google projects.
If you run the xap-plugboard from the command line, you can put in "print" statement in your functions to help you debug what is going on. Of course once you get it sorted its best to removed these as when plugboard is started by the init scripts all output is sent to /dev/null.
If running from the command line you can start it up in debug mode. This will tell you from a C point of view then various things are being executed, it may or may not help.
# xap-plugboard -d 9
Also from the command line if any scripts are crashing you will get STACK TRACE output, even without supplying any debug (-d) option.
Don't forget you should only have 1 xap-plugboard running on the system at a time.
I'm not sure what build you are on - but build 250 made some BSC compliance changes to the 1wire events. Otherwise the key will be "level" not "text". Do check with xFx viewer what you are seeing on the xap bus.
function gettemp()
if xAPMsg.class == "xAPBSC.event" then
if xapmsg_getvalue("input.state", "text") > 33 then
-- state == "off" then
cmd("on")
end
end
end
Quote types in LUA are interchangable, I should santized the wiki docs.
There is also an LUA command line interpretter on the HAH too, this is very useful for testing out bits of code. For example: Let say you aren't sure if the STRING comparison with a NUMBER is automatically performing a cast. You can check this out like this:
# lua
Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio
> value="30"
> print(value>33)
stdin:1: attempt to compare number with string
stack traceback:
stdin:1: in main chunk
[C]: ?
> print(value>"33")
false
>
So now do you see why your code is breaking?
As this is a standalone interpretter the XAP functions are not available to you however all other LUA commands are.
2 July, 2010 - 18:24
#6
Back to basics
Hi Gary,
I've added a 'getting started' section to the plugboard wiki page (at the end of the page). Do try disabling your script for now & try the step by step approach to see if you get the same results as I do. Then gradually build up your script.
Also, email your script to Brett & me and we can debug it locally. If you don't specify filters carefully, you can write a script that becomes recursive - this might explain what you are seeing ...
Cheers,
Derek
2 July, 2010 - 19:33
#8
Stability rules
Good. Sounds like things are a bit more sorted.
Yes, the plugboard does need lots more support by way of tutorials and tools. Early days for the 'getting started' wiki page. If there are any things that you would want added to this, do let me know. Your perseverance has paid off & others might benefit from knowing what you found to be 'difficult' along the way.
The reason the Lua reported "was expecting a string and got 'nil'" is because in Lua, you create a new variable just by using it. Lua initialises all variables to a special value called 'nil'. So when you passed the parameter 'on' (without the quotes), Lua created a variable called 'on', assigned it the value 'nil' and passed it as the parameter to your function.
Email should be possible directly from a Lua script - Brett would know the best way to do this. If we ask nicely, he might knock out an example :-)
2 July, 2010 - 21:34
#10
Don't panic, don't panic!
Well, the difficulty with the embedded Lua is that it's relatively easy to mess up. We must always remember that we don't have much RAM or CPU grunt on the HAH platform. Everything must be "squeezed in". The rewards are that we don't suffer the Windoze tendancy for hangups and random blue screens (and we only burn 6 Watts of power).
This is fine for the tightly controlled C code that Brett engineers so nicely. When we 'open up the door' via Lua, it's a double edged sword. With great power comes great responsibility.
I don't think that there is much that we can really do to sandbox the Lua interpreter and prevent it from causing a panic if a script is just plain wrong. At the end of the day, if somebody can't hack the Lua, they might just want to stick to what the HAH does 'out of the box'. You've bitten this bullet & are now 'Lua aware'.
Script repository, a good "howto get started" and timely online support is IMHO the best way to go. I've had plugboard scripts running smoothly for extended periods (weeks). Even then, I schedule a periodic automatic reboot of the HAH - just to keep things 'clean'.
Thanks for all the observations. Do send any content (scripts, writeup, whatever) that you would be happy to have published.
Cheers,
Derek.
Hi Gary,
Well it's great to see somebody giving this a try. The best way to get up to speed with this stuff is to give it a try, get it wrong and then learn by fixing it. Brett is the scripting guru (I'm still learning), he will correct anything that I've got wrong here. Good that you have the Plugboard enabled in the .ini file.
I've never invoked a script directly from the command line. The whole idea of the Plugboard is that it watches for xAP messages on the bus and automatically calls a script (or scripts) when a message of interest is found. The 'watching for messages' bit is the complex part, but Plugboard (written in C) does all this for you - your script is like the 'event handler'. Plugboard also sets up some important variables that your script can access e.g. xAPMsg.class - if you invoke the script manually, these won't be set properly.
In the init() function you bind the Plugboard 'watcher' to a function inside your script. Note that you can 'register' an interest in as many messages as you like with multiple 'register_source/_target/_class' calls. In fact you could put all your logic into a single, large, script. However, in practice, it's better organised to have lots of small scripts.
So, rather then invoking your script by running this yourself from the command line, start by writing a script that will be called when an xAP message, that you can easily generate, is found. e.g. you could use the UI to send 'RF 1 on' xAP messages. Then in your handler code, put in the code to turn on another relay. This will get you going. Then you can tweak the code to watch instead for the 1-Wire temperature event.
As for your actual code...
The main thing that I don't understand in your script is your declaration of the 'cmd' function. The first line of this seems to be commented out?
Hope this helps. Do let me know how you get on.