openLuup: Tips & Tricks

Plugins & Plugin Development openLuup
#1

openLuup saves performance data as attributes in the user_data.json file, which is updated every 6 minutes. You can configure ALTUI to run a command to give you a glimpse of this under the Misc > OS Command page. Save this command line with the label “Stats” or such like:

cat user_data.json | grep Stats_

Running it gives output like this:

  "Stats_CpuLoad":"4.15%",
  "Stats_Memory":"9.2Mb",
  "Stats_Uptime":"3.96 days",

The same data is accessible with the [tt]luup.attr_get[/tt] call.

#2

The Misc > Lua Startup Code page of ALTUI shows, unsurprisingly, the startup code executed by the system on each reload (this is not to be confused with the startup.lua file used for initialising an new system.)

Sadly, though, under openLuup, editing this window does not save any changes made (it’s another port 49451 problem.)

Happily enough, you shouldn’t really have to do that… if you define it just once to have this code…

require "my_restart_file"

… then you can simply use an external editor to put whatever you like into the contents of [tt]my_restart_file.lua[/tt] and it will be executed on every restart.

Alternatively, you can use code like this executed in the Lua Test window to change the startup code:

luup.attr_set ("StartupCode",  [[

-- just write any Lua code here which will be put into the new Startup code
-- the good thing here is that you don't have to quote quotation marks - any sort will do...

luup.log ("This message is made from " .. 'two differently quoted strings')

]])
#3

Whilst you can (now, in Release 5.5) happily create a local device interactively on openLuup using either a bit of test code with [tt]luup.create_device()[/tt] or using the +Create button on the AltUI interface, I’d also recommend that you maintain a [tt]startup.lua[/tt] script which does the same for all your local devices and plugins.

That way if, for whatever reason, you can’t reload your system configuration from the [tt]user_data.json[/tt] file, you can always recreate most of it on a fresh system by running the [tt]startup.lua[/tt] file.

Equally, since the [tt]user_data.json[/tt] file is not encoded but it is pretty-printed, it’s actually really easy to edit this, for example, to remove an unwanted variable from a device.

#4

If, for some reason, you want to revert to any other version of AltUI, you can use this HTTP request:

http://<VeraIP>:3480/data_request?id=action&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&action=CreatePlugin&PluginNum=8246&TracRev=859

…replacing the ‘859’ with whatever build version you like (note that this is NOT the same as the MiOS App store version number, but it is the last part of the version number which AltUI reports at the bottom of the page.)

#5

Remote scenes are assigned to the new room created specifically for the remote Vera, so simply selecting ‘No Room’ rather than ‘All’ will remove them from the display.

#6

You can add a favicon in /etc/cmh-ludl by copying (for example) the file https://vera-eu-oem-relay12.mios.com/www/1.7.1707-en/favicon.ico

#7

Since openLuup now searches the directory etc/cmh-lu/ in addition to /etc/cmh-ludl/ for device and program files, you can define a symbolic link in /etc/ called cmh-lu which points to the /etc/cmh-ludl/files/ directory where the getfiles utility has downloaded them from the remote Vera. This means you don’t have to move any files manually, and it leaves the /etc/cmh-ludl/ directory relatively clear for logfiles and any development files you might be working on.

#8

I’ll add this to the images and guide moving forward.

#9

An easy way to access the whole of the current log file is simply to make this HTTP request in your browser:

http://VeraIP:3480/LuaUPnP.log

or, of course, you can use the AltUI OS Command

tail -n 50 /var/log/cmh/LuaUPnP.log

…although this only shows device variable changes and scene executions.

For the tail of the complete current log, define a new OS command like this:

tail -n 100 LuaUPnP.log
#10

[quote=“akbooer, post:9, topic:189397”]An easy way to access the whole of the current log file is simply to make this HTTP request in your browser:

http://VeraIP:3480/LuaUPnP.log

or, of course, you can use the AltUI OS Command

tail -n 50 /var/log/cmh/LuaUPnP.log

…although this only shows device variable changes and scene executions.

For the tail of the complete current log, define a new OS command like this:

tail -n 100 LuaUPnP.log [/quote]

just in case, you can edit OS commands of ALTUI and add your prefered ones. click on the pencil

#11

Using AltUI to back up your user_data.json file

The latest build of AltUI (1608) adds a ‘backup’ button to the Controllers page. On Vera, this backs up your configuration to a file on your browsing machine by running a CGI file. Under openLuup, you can make this do anything you want by writing the appropriate WSAPI CGI Lua script.

The script file should go into [tt]/etc/cmh-ludl/cgi-bin/cmh/backup.sh[/tt] and here’s an example which simply backs up to a file in [tt]/etc/cmh-ludl/backups/[/tt]. The filename has the format [tt]backup.openLuup-00000000-2016-05-01[/tt], so only unique once a day. The “00000000” is replaced by whatever [tt]PK_AccessPoint[/tt] you’ve given your machine.

#!/usr/bin/env wsapi.cgi

module(..., package.seeall)

ABOUT = {
  NAME          = "backup.sh",
  VERSION       = "2016.04.30",
  DESCRIPTION   = "user_data backup script /etc/cmh-ludl/cgi-bin/cmh/backup.sh",
  AUTHOR        = "@akbooer",
  DOCUMENTATION = "https://github.com/akbooer/openLuup/tree/master/Documentation",
}

local DIRECTORY     = "backup"      -- change this if you want to backup elsewhere

-- WSAPI Lua implementation of backup.sh
-- backup written to ./backups/backup.openLuup-00000000-2015-01-21

local userdata = require "openLuup.userdata"
local lfs = require "lfs"

local _log    -- defined from WSAPI environment as wsapi.error:write(...) in run() method.


-- global entry point called by WSAPI connector

--[[

The environment is a Lua table containing the CGI metavariables (at minimum the RFC3875 ones) plus any 
server-specific metainformation. It also contains an input field, a stream for the request's data, 
and an error field, a stream for the server's error log. 

The input field answers to the read([n]) method, where n is the number
of bytes you want to read (or nil if you want the whole input). 

The error field answers to the write(...) method.

return values: the HTTP status code, a table with headers, and the output iterator. 

--]]

function run (wsapi_env)
  _log = function (...) wsapi_env.error:write(...) end      -- set up the log output, note colon syntax -- 2016.02.26
  
  lfs.mkdir (DIRECTORY)
   
  local PK = userdata.attributes.PK_AccessPoint or "XXXXXXXX"
  local DATE = os.date "%Y-%m-%d" or "0000-00-00"
  local fmt = "%s/backup.openLuup-%s-%s"
  local fname = fmt: format (DIRECTORY, PK, DATE)  
  _log ("Backing up user_data to " .. fname)
  
  local ok, msg = userdata.save (nil, fname)   -- save current luup environment
  
  local status, return_content
  if ok then 
    status, return_content  = 200, "backup completed"
  else
    status, return_content  = 500, "backup failed: " .. msg
  end
  
  local headers = {["Content-Type"] = "text/plain"}
  
  local function iterator ()     -- one-shot iterator, returns content, then nil
    local x = return_content
    return_content = nil 
    return x
  end

  return status, headers, iterator
end

-----

You’ll also need the latest commit from the openLuup GitHub development branch to make this work.

#12

[quote=“akbooer, post:11, topic:189397”]Using AltUI to back up your user_data.json file

The latest build of AltUI (1608) adds a ‘backup’ button to the Controllers page. On Vera, this backs up your configuration to a file on your browsing machine by running a CGI file. Under openLuup, you can make this do anything you want by writing the appropriate WSAPI CGI Lua script.

The script file should go into [tt]/etc/cmh-ludl/cgi-bin/cmh/backup.sh[/tt] and here’s an example which simply backs up to a file in [tt]/etc/cmh-ludl/backups/[/tt]. The filename has the format [tt]backup.openLuup-00000000-2016-05-01[/tt], so only unique once a day. The “00000000” is replaced by whatever [tt]PK_AccessPoint[/tt] you’ve given your machine.

#!/usr/bin/env wsapi.cgi

module(..., package.seeall)

ABOUT = {
  NAME          = "backup.sh",
  VERSION       = "2016.04.30",
  DESCRIPTION   = "user_data backup script /etc/cmh-ludl/cgi-bin/cmh/backup.sh",
  AUTHOR        = "@akbooer",
  DOCUMENTATION = "https://github.com/akbooer/openLuup/tree/master/Documentation",
}

local DIRECTORY     = "backup"      -- change this if you want to backup elsewhere

-- WSAPI Lua implementation of backup.sh
-- backup written to ./backups/backup.openLuup-00000000-2015-01-21

local userdata = require "openLuup.userdata"
local lfs = require "lfs"

local _log    -- defined from WSAPI environment as wsapi.error:write(...) in run() method.


-- global entry point called by WSAPI connector

--[[

The environment is a Lua table containing the CGI metavariables (at minimum the RFC3875 ones) plus any 
server-specific metainformation. It also contains an input field, a stream for the request's data, 
and an error field, a stream for the server's error log. 

The input field answers to the read([n]) method, where n is the number
of bytes you want to read (or nil if you want the whole input). 

The error field answers to the write(...) method.

return values: the HTTP status code, a table with headers, and the output iterator. 

--]]

function run (wsapi_env)
  _log = function (...) wsapi_env.error:write(...) end      -- set up the log output, note colon syntax -- 2016.02.26
  
  lfs.mkdir (DIRECTORY)
   
  local PK = userdata.attributes.PK_AccessPoint or "XXXXXXXX"
  local DATE = os.date "%Y-%m-%d" or "0000-00-00"
  local fmt = "%s/backup.openLuup-%s-%s"
  local fname = fmt: format (DIRECTORY, PK, DATE)  
  _log ("Backing up user_data to " .. fname)
  
  local ok, msg = userdata.save (nil, fname)   -- save current luup environment
  
  local status, return_content
  if ok then 
    status, return_content  = 200, "backup completed"
  else
    status, return_content  = 500, "backup failed: " .. msg
  end
  
  local headers = {["Content-Type"] = "text/plain"}
  
  local function iterator ()     -- one-shot iterator, returns content, then nil
    local x = return_content
    return_content = nil 
    return x
  end

  return status, headers, iterator
end

-----

You’ll also need the latest commit from the openLuup GitHub development branch to make this work.[/quote]

What needs to be done make this run daily?

#13

To run a backup, you just need to issue the HTTP request:

http://openLuupIP:3480/cgi-bin/cmh/backup.sh

So if you schedule a daily scene with the following Luup code:

luup.inet.wget "http://127.0.0.1:3480/cgi-bin/cmh/backup.sh"

…that should do the trick.

#14

thanks!

#15

You can always add useful global variable or function definitions to your Lua Startup code, and then they’re available for use within you Lua Test code or Scene Lua without further ado.

For example, I include in my Startup Lua:

json = require "openLuup.json"

and then in Test Lua or scenes I can simply use it…

local x = json.decode (y)
#16

Hi akbooer,

sorry if this is not the correct thread but I’d ask you if there’s any problem to run Openluup on a 64 bit Unix Operating System.

tnks

donato

#17

openLuup runs on any system that supports Lua. That’s no problem at all.

#18

On an RPi you can use shared memory to store openLuup logs with the following Lua Startup code:

-- openLuup logs in RAM
local lfs = require "lfs"
local logs = "/dev/shm/logs"
if not lfs.attributes (logs) then lfs.mkdir (logs) end
luup.attr_set ("openLuup.Logfile.Name", logs .. "/LuaUPnP.log")

-- /var/log/cmh/  ensure it's there for AltUI logs
-- won't work the first time it's created
local altlog = logs .. "/altui"
lfs.mkdir (altlog)
lfs.link (altlog, "/var/log/cmh", true)     -- true for symbolic link

…you’ll need to reload twice after editing Lua Startup to make this effective.

It’s a good way to be kind to your RPi non-volatile memory, since it’s stored in RAM.

#19

when I add your ram drive code to lua startup I get

	Lua Startup can only be modified on controller 0
#20

Your AltUI version amd openLuup version don’t match. There have been recent security changes. you need to update to the latest openLuup development version and the latest AltUI.