We have moved at community.getvera.com

Author Topic: determine if running on openLuup and/or detecting json decoder  (Read 1515 times)

Offline reneboer

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1574
  • Karma: +110/-31
Re: determine if running on openLuup and/or detecting json decoder
« Reply #15 on: March 20, 2018, 07:42:25 am »
That's really worrying... what's in the table?
I have not looked. Let me try tonight. It might be that the call without device number (zero in this case) produces unpredictable results on a Vera.

Cheers Rene
2xVeraLite, VeraEdge, openLuup, ALTUI, 20 switches, 10 dimmers, 20 sensors, 10 scene controllers, 1 Harmony Hub, many plug-ins. Not enough time.

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 6387
  • Karma: +292/-70
  • "Less is more"
Re: determine if running on openLuup and/or detecting json decoder
« Reply #16 on: March 20, 2018, 07:59:14 am »
I'm very surprised, because attributes in Vera are only numbers or strings.  You're sure you weren't on openLuup by accident?!

None of my Veras (two on UI5, one on UI7, but not the latest) do this.
3x Vera Lite-UI5/Edge-UI7, 25x Fibaro, 23x TKB, 9x MiniMote, 2x NorthQ Power, 2x Netatmo, 1x Foscam FI9831P, 9x Philips Hue,
Razberry, MySensors Arduino, HomeWave, AltUI, AltHue, DataYours, Grafana, openLuup, ZWay, ZeroBrane Studio.

Offline reneboer

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1574
  • Karma: +110/-31
Re: determine if running on openLuup and/or detecting json decoder
« Reply #17 on: March 21, 2018, 05:59:21 am »
Hi akbooer,

No, not on openLuup. I first tested the code on a VeraEdge that has ALTUI as that makes testing snippets of code simpler in the LUA Test Code window. There it worked without specifying a device number as second parameter. Also tested it on openLuup the same way, also working. Then I put it in a plugin running on a VeraLite that does not have much on it as I use it as development box. There the code was returning a value for luup.attr_get("openLuup").

I just tried in the VeraLite LUA Test window and
Code: [Select]
return (luup.attr_get("openLuup") == nil) returns true as expected, so I am puzzled too why it fails in my plugin.
This is the code used in the plugin, and without the device number 0 it returns 99 on the VeraLite:
Code: [Select]
local function _getui()
if (luup.attr_get("openLuup",0) ~= nil) then
return 99
else
return luup.version_major
end
return 7
end

I just looked at the wiki and maybe this explains something:
function: attr_get
parameters: attribute (string), device (string or number)
returns: string or none (note: none means nothing at all. It does not mean 'nil')

Maybe I see the "nothing" and that throws off my code?
« Last Edit: March 21, 2018, 06:33:23 am by reneboer »
2xVeraLite, VeraEdge, openLuup, ALTUI, 20 switches, 10 dimmers, 20 sensors, 10 scene controllers, 1 Harmony Hub, many plug-ins. Not enough time.

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 6387
  • Karma: +292/-70
  • "Less is more"
Re: determine if running on openLuup and/or detecting json decoder
« Reply #18 on: March 21, 2018, 07:44:32 am »
I've ALWAYS wondered what that "nothing" meant in the documentation.  Certainly, I don't implement it that way.  I thought I tested this at the time (a long while ago) but would be loathe to change this now, though.
3x Vera Lite-UI5/Edge-UI7, 25x Fibaro, 23x TKB, 9x MiniMote, 2x NorthQ Power, 2x Netatmo, 1x Foscam FI9831P, 9x Philips Hue,
Razberry, MySensors Arduino, HomeWave, AltUI, AltHue, DataYours, Grafana, openLuup, ZWay, ZeroBrane Studio.

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 6387
  • Karma: +292/-70
  • "Less is more"
Re: determine if running on openLuup and/or detecting json decoder
« Reply #19 on: March 21, 2018, 01:37:09 pm »
I've been been investigating this effect...

I run this test program:
Code: [Select]
print ("no device", luup.attr_get "openLuup")
print ("device 0", luup.attr_get ("openLuup",0))
print ("no device", nil == luup.attr_get "openLuup")
print ("device 0", nil == luup.attr_get ("openLuup",0))
if luup.attr_get "openLuup" then print "exists" else  print "doesn't exist" end
if luup.attr_get ("openLuup",0) then print "exists" else  print "doesn't exist" end

which gives this output:
Code: [Select]
no device
device 0
no device true
device 0 true
doesn't exist
doesn't exist

for both my UI5 machines. 

There is no difference between specifying device 0 and not doing so.
In each and every case, it gives the result I would expect.

BUT...

Code: [Select]
print (type(luup.attr_get "openLuup"))

gives the error
Code: [Select]
[string "ALTUI - LuaRunHandler"]:8: bad argument #1 to 'type' (value expected)

...as does the call with the device number.

HOWEVER...
Code: [Select]
print (type((luup.attr_get "openLuup")))

prints
Code: [Select]
nil

So, AMAZINGLY, the documentation is actually correct and the failed call returns NOTHING.

AFAIK, this is completely invalid Lua, and a stunning example of the crass implementation of MiOS.  There simply is no native Lua representation of 'nothing' - function calls with no return evaluate to nil.

I still can't explain your result, since my test code above seems to cover that case?
3x Vera Lite-UI5/Edge-UI7, 25x Fibaro, 23x TKB, 9x MiniMote, 2x NorthQ Power, 2x Netatmo, 1x Foscam FI9831P, 9x Philips Hue,
Razberry, MySensors Arduino, HomeWave, AltUI, AltHue, DataYours, Grafana, openLuup, ZWay, ZeroBrane Studio.

Offline reneboer

  • Beta Testers
  • Hero Member
  • *****
  • Posts: 1574
  • Karma: +110/-31
Re: determine if running on openLuup and/or detecting json decoder
« Reply #20 on: March 22, 2018, 06:02:46 am »
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
2xVeraLite, VeraEdge, openLuup, ALTUI, 20 switches, 10 dimmers, 20 sensors, 10 scene controllers, 1 Harmony Hub, many plug-ins. Not enough time.

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 6387
  • Karma: +292/-70
  • "Less is more"
Re: determine if running on openLuup and/or detecting json decoder
« Reply #21 on: March 22, 2018, 06:37:11 am »
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.

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
3x Vera Lite-UI5/Edge-UI7, 25x Fibaro, 23x TKB, 9x MiniMote, 2x NorthQ Power, 2x Netatmo, 1x Foscam FI9831P, 9x Philips Hue,
Razberry, MySensors Arduino, HomeWave, AltUI, AltHue, DataYours, Grafana, openLuup, ZWay, ZeroBrane Studio.

Offline a-lurker

  • Hero Member
  • *****
  • Posts: 872
  • Karma: +66/-8
Re: determine if running on openLuup and/or detecting json decoder
« Reply #22 on: March 24, 2018, 02:53:53 am »
Quote
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: [Select]
local theDeviceNumber = 987  -- an invalid device number in my Vera

local ok, result = pcall(luup.attr_get, 'name', theDeviceNumber)

luup.log(result)

return true

Gives in the log:

Code: [Select]
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. ;)

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 6387
  • Karma: +292/-70
  • "Less is more"
Re: determine if running on openLuup and/or detecting json decoder
« Reply #23 on: March 24, 2018, 07:32:14 am »
Well perhaps I could have expressed it better in the documentation but it was five years ago 8)

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...

Quote
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:
  • nil - that's what I'd expect, but, in extremis, then...
  • userdata - but that really should be just at the level of the C API.

Quote
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:

  • directly assigned to a variable, and then tested, or...
  • evaluated in place by the use of additional parentheses.

Code: [Select]
local x = luup.attr_get "foo"
print (type(x))

print (type ((luup.attr_get "foo")))

print (type (luup.attr_get "foo"))

produces...
Code: [Select]
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.
3x Vera Lite-UI5/Edge-UI7, 25x Fibaro, 23x TKB, 9x MiniMote, 2x NorthQ Power, 2x Netatmo, 1x Foscam FI9831P, 9x Philips Hue,
Razberry, MySensors Arduino, HomeWave, AltUI, AltHue, DataYours, Grafana, openLuup, ZWay, ZeroBrane Studio.

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 6387
  • Karma: +292/-70
  • "Less is more"
Re: determine if running on openLuup and/or detecting json decoder
« Reply #24 on: June 22, 2018, 07:00:45 pm »
Further to this discussion, @amg0 has just pointed this out to me...

Quote
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: [Select]
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.

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!)
« Last Edit: June 22, 2018, 07:03:07 pm by akbooer »
3x Vera Lite-UI5/Edge-UI7, 25x Fibaro, 23x TKB, 9x MiniMote, 2x NorthQ Power, 2x Netatmo, 1x Foscam FI9831P, 9x Philips Hue,
Razberry, MySensors Arduino, HomeWave, AltUI, AltHue, DataYours, Grafana, openLuup, ZWay, ZeroBrane Studio.

Offline a-lurker

  • Hero Member
  • *****
  • Posts: 872
  • Karma: +66/-8
Re: determine if running on openLuup and/or detecting json decoder
« Reply #25 on: June 22, 2018, 10:13:05 pm »
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:

Code: [Select]
luup.log(luup.attr_get "foo")
luup.log()
return true

Code: [Select]
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.

Offline a-lurker

  • Hero Member
  • *****
  • Posts: 872
  • Karma: +66/-8
Re: determine if running on openLuup and/or detecting json decoder
« Reply #26 on: June 22, 2018, 10:19:01 pm »
On the json decoder detection, I ended up with this unsightly arrangement:

Code: [Select]
-- 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

I'm also not clear on why a L_ALTUIjson was needed. @amg0 says this in the file:

Code: [Select]
--modified version which works with module declaration. reason is probably because of deployment in mios store options (lua) which I cannot change now

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 6387
  • Karma: +292/-70
  • "Less is more"
Re: determine if running on openLuup and/or detecting json decoder
« Reply #27 on: June 23, 2018, 03:30:26 am »
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

Code: [Select]
luup.openLuup == true   -- true for openLuup, nil for MiOS/Vera

Unless Vera becomes truly vindictive, this should be bulletproof.
« Last Edit: June 25, 2018, 06:18:08 am by akbooer »
3x Vera Lite-UI5/Edge-UI7, 25x Fibaro, 23x TKB, 9x MiniMote, 2x NorthQ Power, 2x Netatmo, 1x Foscam FI9831P, 9x Philips Hue,
Razberry, MySensors Arduino, HomeWave, AltUI, AltHue, DataYours, Grafana, openLuup, ZWay, ZeroBrane Studio.