openLuup: Suggestions

Glad to hear that the latest is working well for you.

Good idea! Because the openLuup.json module is not dependent on any other openLuup modules, it doesn’t report its presence in the logs, so the version info doesn’t appear in the startup log.

It’s easy to do an explicit check:

if json.C then print "using Cjson" end

so I’ll put that in the log and perhaps on a console page.

Thanks for the suggestion.

AK

OK - looks like cjson did install OK. AltUI didn’t find it, because it’s command is looking for json Lua files but cjson is not Lua. I tried your test but that failed but this indicated it was available:

local ok, result = pcall(require, 'cjson')
local json = package.loaded['cjson']
if (json) then
    print('Found cjson')
else
    print('cjson not found')
end

return true
1 Like

Had you restarted openLuup after installing Cjson?

Yep and this is the response:

"[string "ALTUI - LuaRunHandler"]:39: attempt to index global 'json' (a nil value)"

Wondering if this is a version of Cjson which adds a global to the Lua environment, rather than returning a module.

Is the result of

local j = require "cjson"

true or a table ?

…or, possibly, you ran this code on Vera, not on openLuup?

Definitely on openLuup; err Vera? :upside_down_face:

local j = require "cjson"
print(j)

for k,v in pairs(j) do
    print(k)
    print(v)
end

return true

It returns a table and the contents are:

table: 0x105ad28

_NAME
cjson
encode
function: 0x105b470
decode_max_depth
function: 0x105b620
_VERSION
2.1.0
decode_invalid_numbers
function: 0x104bad0
encode_keep_buffer
function: 0x104ba40
null
userdata: (nil)
encode_number_precision
function: 0x105b570
new
function: 0x104b938
encode_max_depth
function: 0x105b4f8
encode_invalid_numbers
function: 0x104ba70
decode
function: 0x105b4c8
encode_sparse_array
function: 0x105b540

Then I have absolutely no idea what is going on.

Hi,

I installed cjson on a PI and works just fine running the latest openLuup development branch.

I am also using it in one of my plugins in a way that works on openLuup (with cjson) and Vera (without). It is based on what AK did in openLuup, with some changes as Vera would not take that for some reason. The cjson.decode only works on a perfect json string, else it trows an exception. You can use cjson.safe.decode then it will not throw the exceptions.

local cjson 	= require("cjson")
local dkjson 	= require("dkjson")
local json

-- Wrapper for more solid handling for cjson as it trows a bit more errors that I'd like.
local function jsonAPI()
local is_cj, is_dk

	local function _init()
		is_cj = type(cjson) == "table"
		is_dk = type(dkson) == "table"
	end
	
	local function _decode(data)
		if is_cj then
			local ok, res = pcall(cjson.decode, data)
			if ok then return res end
		end
		local res, pos, msg = dkjson.decode(data)
		return res, msg
	end
	
	local function _encode(data)
		-- No special chekcing required as we must pass valid data our selfs
		if is_cj then
			return cjson.encode(data)
		else
			return dkjson.encode(data)
		end
	end
	
	return {
		Initialize = _init,
		decode = _decode,
		encode = _encode
	}
end

json = jsonAPI()
json.Initialize()

local res = json.decode("{some json}")

Maybe it helps finding the problem.

Note, the instructions say this: Import Lua CJSON via the Lua require function. Lua CJSON does not register a global module table. https://www.kyne.com.au/~mark/software/lua-cjson-manual.html

Cheers Rene

2 Likes

@a-lurker

My suggestion here would have worked but for the fact that in my Lua Startup I have the line

json = require "openLuup.json"

which makes my json module globally available in the startup / scene / Lua Test context.

The latest releases of openLuup have the new json module which should now be working for you.

Apologies for my confusion.

AK