Hi akbooer,
Have you run all your tests in the test windows, or also in a plugin? In a plugin is the only place I see the difference. Thanks for your testing. I will try a bit more as part of a plugin later this week.
Cheers rene
No, just in a test window… life is too short for me to investigate all of Vera’s vagaries!
I’d be really interested to know what might be in that returned table, although perhaps it’s just empty. Good luck!
AK
So, AMAZINGLY, the documentation is actually correct and the failed call returns NOTHING.
Well perhaps I could have expressed it better in the documentation but it was five years ago 8)
http://wiki.micasaverde.com/index.php?title=Luup_Lua_extensions&diff=4941&oldid=4939
It certainly doesn’t return anything that’s Lua like. Using a pcall:
[code]local theDeviceNumber = 987 – an invalid device number in my Vera
local ok, result = pcall(luup.attr_get, ‘name’, theDeviceNumber)
luup.log(result)
return true[/code]
Gives in the log:
01 03/24/18 17:43:10.036 GetLuaInterface can't find device type: 3/0x11601d0 str: 987 <0x2f9dc680>
01 03/24/18 17:43:10.036 luup_attr_get interface 0x1161440 args 2 bad device 987 <0x2f9dc680>
50 03/24/18 17:43:10.037 luup_log:0: (null) <0x2f9dc680>
50 03/24/18 17:43:10.038 luup_log:0: ALTUI: Evaluation of lua code returned: true
So presumably there is some coding problem whereby a ‘C’ null is returned. If you want the doco changed, please provide some clearer prose. My grasp of the English language tends to be a bit tenuous. 
Sincere apologies, if I have caused any offense. My amazement stems from the fact that I didn’t originally understand what “nothing” could possibly be, since there simply is no such thing in Lua…
It certainly doesn't return anything that's Lua like.
… exactly! This is truly unforgivable on behalf of the MiOS developers. It’s not as though there are not valid alternatives:
[ul][li]nil - that’s what I’d expect, but, in extremis, then…[/li]
[li]userdata - but that really should be just at the level of the C API.[/li][/ul]
If you want the doco changed, please provide some clearer prose. My grasp of the English language tends to be a bit tenuous. ;)
There is nothing wrong with your English! However, it’s such a bizarre circumstance that perhaps it’s worth highlighting this even more by saying that the result should either be:
[ol][li]directly assigned to a variable, and then tested, or…[/li]
[li]evaluated in place by the use of additional parentheses.[/li][/ol]
local x = luup.attr_get "foo"
print (type(x))
print (type ((luup.attr_get "foo")))
print (type (luup.attr_get "foo"))produces…
nil
nil
bad argument #1 to 'type' (value expected)The developers of Lua itself went to extreme lengths to ensure consistency and simplicity. The developers of MiOS have, here, completely obfuscated what should be a trivially simple conditional test. It is, I repeat, unforgivable.
Further to this discussion, @amg0 has just pointed this out to me…
http://wiki.micasaverde.com/index.php/Luup_Lua_extensions#function:_attr_get documents this as a change in march 2018. ( this is the root cause of the blank open page issue in fact ) [code] If the device (string or number) is invalid and due to a MIOS coding problem, the expected 'nil' is not returned (as of March 2018). Instead '(null)' is returned. [/code]
I wonder if it was a result of this thread?
It would have been nice to be told.
The upshot is that luup.attr_get() does NOT now return ‘nothing’, but, instead, a string… which is, at least, a valid Lua construct, but means that the test for openLuup outlined below will not now work. You have to test for a string.
This is likely to break a few plugins. It already broke AltUI (but, as usual, quickly fixed by @amg0!)
It was me again trying to express the problem more clearly than saying it returned ‘nothing’ but perhaps I should have expressed (null) without the quotes ie not a string. Below you see that the logging function believes it has rx’ed no argument ie nothing:
luup.log(luup.attr_get "foo")
luup.log()
return true
01 06/23/18 12:04:07.011 GetLuaInterface can't find device type: -1/0x1313220 str: (null) <0x302ed680>
01 06/23/18 12:04:07.012 luup_log interface 0x1315410 args 0 <0x302ed680>
01 06/23/18 12:04:07.012 luup_log interface 0x1315410 args 0 <0x302ed680>
50 06/23/18 12:04:07.013 luup_log:0: ALTUI: Evaluation of lua code returned: true
If you would like to compose some alternate text for the Wiki, I will gladly put it in.
On the json decoder detection, I ended up with this unsightly arrangement:
[code]-- If possible, get a JSON parser. If none available, returns nil. Note that typically UI5 may not have a parser available.
local function loadJsonModule()
local jsonModules = {
‘dkjson’, – UI7 firmware
‘openLuup.json’, – http://forum.micasaverde.com/index.php?topic=29989.0
‘akb-json’, – http://forum.micasaverde.com/index.php?topic=29989.0
‘json’, – OWServer plugin
‘json-dm2’, – dataMine plugin
‘dropbox_json_parser’, – dropbox plugin
‘hue_json’, – hue plugin
‘L_ALTUIjson’ – AltUI plugin
}
local ptr = nil
local json = nil
for n = 1, #jsonModules do
-- require does not load the module, if it's already loaded
-- Vera has overloaded require to suit their requirements, so it works differently from openLuup
-- openLuup:
-- ok: returns true or false indicating if the module was loaded successfully or not
-- result: contains the ptr to the module or an error string showing the path(s) searched for the module
-- Vera:
-- ok: returns true or false indicating the require function executed but require may have or may not have loaded the module
-- result: contains the ptr to the module or an error string showing the path(s) searched for the module
-- log: log reports 'luup_require can't find xyz.json'
local ok, result = pcall(require, jsonModules[n])
ptr = package.loaded[jsonModules[n]]
if (ptr) then
json = ptr
debug('Using: '..jsonModules[n])
break
end
end
if (not json) then debug('No JSON library found') return json end
return json
end
[/code]
I’m also not clear on why a L_ALTUIjson was needed. @amg0 says this in the file:
--modified version which works with module declaration. reason is probably because of deployment in mios store options (lua) which I cannot change now
Ah, OK, so nothing has actually changed on the luup.attr_get() front?
Whilst it doesn’t solve the problem for other uses, I am (reluctantly) going to put a flag into openLuup such that
luup.openLuup == true -- true for openLuup, nil for MiOS/VeraUnless Vera becomes truly vindictive, this should be bulletproof.