(Last Updated: June 28, 2020)

openLuup: Suggestion



  • As @akbooer said in another thread...

    I suppose I should also be setting out a roadmap. At the risk of it becoming a commitment, let's just say that, for the moment, it's just a list of incremental development ideas and some blue sky thinking:

    ZWay plugin integrated in openLuup distribution (as are AltAppStore and VeraBridge)* native scene triggers – not the same as Vera, not the same as AltUI variable watches, but definable in the openLuup console.
    utilities for managing Data Historian archives
    better task & job messages

    and then...

    fully asynchronous I/O
    enhanced HTTP server with data compression (perhaps using third-party web server?)
    Ajax calls for asynchronous updates of some console pages (Devices, Scenes, ...)
    ...

    Ideas always welcomed!



  • @akbooer
    if you need help, I can help with the 3rd party web server like nginx or apache!

    In this case I will prefer nginx for sure!

    We can use nginx for all "static" files and pass_proxy the other part to openLuup!



  • I had been thinking of apache, but it looked cumbersome. Lighttpd, of course, was another Vera-inspired option (openWRT.). I must look up more about nginx.

    How easy is this to install on any system? Does it support WSAPI CGIs?

    —————————

    Edit: after a little homework, I think that the answer is yes, for WSAPI. Not that I know how I’ll use it, just that some of openLuup is implemented like that.



  • nginx is awesome for "reverse proxy" too. Like on this forum. We can use nginx to serve all files for example in /img or /static/ and send the other part to the reverse proxy config to openLuup directly!



  • Yup, I at one point at one such proxy running to force going through login before being able to openLuup by blocking the port 3480 to any access except for nginx from my firewall. This has always been an odd thing missing from the vera which deems blocking the local access and forcing going through their server being their secure mode. Nginx reverse proxy could then act as the local authentication server.



  • An idea: (prompted by @CatmanV2 ’s mammoth code development in Lua Test windows) ...

    ...there could be a version of the require() statement which includes code from one of the other openLuup Lua Test windows (currently a total of three, but could be more) to aid in modularity when testing.



  • @akbooer said in openLuup: Suggestion:

    An idea: (prompted by @CatmanV2 ’s mammoth code development in Lua Test windows) ...

    Well, it turns out that this is already easy to do!

    If the Lua Test Code window #3 contains, for example:

    local function foo ()
        return "this function is in Lua Test Code #3"
    end
    
    return {foo = foo}
    

    (in other words, a standard module declaration) and then in another test window you write:

    local T3 = loadstring (luup.attr_get "LuaTestCode3") ()
    
    print (T3.foo())
    
    

    then you will get the expected result:

    ––– 1 line ––– 0.5 ms –––

    this function is in Lua Test Code #3

    Job done!!



  • Not sure if this is the "Official" openLuup suggestion thread but: in the Lua test code windows in the console. It would be good if they were cleared when you hit the code Submit button. That way you see all your old print statement outputs disappear and affirms you have actually clicked the button.



  • @a-lurker said in openLuup: Suggestion:

    Not sure if this is the "Official" openLuup suggestion thread

    Yes, it is.

    @a-lurker said in openLuup: Suggestion:

    It would be good if they were cleared when you hit the code Submit button.

    Not sure I’m understanding this. You press the button, the code is run, the results are in the output window. It usually happens quite quickly... I did think of adding a time stamp to the header to show when it was run.



  • I was recently playing around with some AES ECB encoding/decoding and I'm looking at changes amongst a myriad of same other info that's coming in over a link over a period of time. On thinking about this further: I don't see anything printed at all, until the program is finished (that's the actual problem). Whereas the log can spit out debug info as the code proceeds. If the code takes time to run (lots of seconds) decoding incoming data; then I'm unsure if it is executing till it finishes or has indeed crashed.

    Doesn't need a time stamp. Just a blank output screen when the Submit button is operated; ready for new the output to be shown immediately the program finishes..



  • @akbooer said in openLuup: Suggestion:

    An idea: (prompted by @CatmanV2 ’s mammoth code development in Lua Test windows) ...

    That seems somehow unlikely! 😄

    C



  • @a-lurker said in openLuup: Suggestion:

    I don't see anything printed at all, until the program is finished

    Slippery slope, this. Next you’d be wanting to interact with a running program...

    Ajax requests are the answer to this – and for real time updates of the devices page – so it’s on the list (actually I must write the list down, sometime) and the basic infrastructure is there.

    I’ll see what can be done sooner re. clearing the output window.



  • I had a quick go at this... and failed.

    My motto (for openLuup engine and console) is "no JavaScript". Actually, there is a teeny tiny bit, in order to be able to hook into the indispensible Ace editor.

    I was willing to break the rule if it solved a problem, but the obvious bit of JS to clear the output window before submit does not work since it is, in fact, an iframe, not a div. I'm no expert in this, and don't really want to be one, believing that server-side pages are inifinitely preferable. (the speed of the openLuup console, cf., say, AltUI, or, God forbid, UI7, is testament to this mantra.)

    It will be solved in due course, but the quick fix approach will not do it. I am a bit busy with a different, exciting, project (that, one day, may surface as an openLuup plugin as one of its guises.)

    Sorry. Tried. Failed. 😞

    AK



  • AK - thanks for your efforts. I think I will survive without it. What with three test windows and UI output with pretty() versus watching the log file go past: I think I'm doing pretty well (pun intended).

    Here is another possible suggestion/query. As you may have noted I've been disappearing down and reappearing up at various rabbit holes re: luup.call_delay(). I fully appreciate that the openLuup code is busy doing stuff and a requested delay may blossom into something longer than requested. You mentioned AltUI may hit the system a bit hard but I didn't note any difference with it running or not - that's one rabbit hole of many. So is it possible to somehow profile openLuup to see what is really holding it up. It could possibly be the Vera connection; another rabbit hole or indeed all my own plugins. I'm unsure how this would be done. May be an auxiliary test program that could be run for ten minutes or so? Lua has some debug library built in that may be useful. Anyway may be in the too hard basket as profiling can be a can of worms.

    Another query - the openLuup console has System-->All_Gobals, which is great for finding vars that should have been declared as local. So question - is there some code that you can write that you execute with your other test code in the Lua test window, that will list globals in the code running in the Lua test window, so errant vars can be found and made local, as needed? Could also apply to functions.



  • @a-lurker said in openLuup: Suggestion:

    So is it possible to somehow profile openLuup to see what is really holding it up.

    How strange... for the other project I am currently working on, I’ve started using the Lua debug library to profile the code. As warned in the docs, the library can be slow, so timing is not really possible at the Lua level. Counting procedure calls, however, is faster, but I’m not sure it will give you what you need. On the plus side, it’s trivial to add the profiler to any running code with no changes required. I’ve not tried this on openLuup, yet...

    @a-lurker said in openLuup: Suggestion:

    is there some code that you can write that you execute with your other test code in the Lua test window, that will list globals in the code running in the Lua test window

    Well, yes, of course! Ah, you want to know what that is... I just need to try this on my development system, and not an iPad. Perhaps after breakfast...



  • @a-lurker said in openLuup: Suggestion:

    is there some code [...] that will list globals in the code running in the Lua test window

    So here's a little function that shows you all the globals in the Lua Test Code area (shared with scenes / Startup Lua / Shutdown Lua.)

    local function globals ()
      local G = {}
      local name_type = "([^/]+)/(.+)"
      local gnames = "%-20s %s"
      for g, x in pairs (_G) do
        G[#G+1] = g .. '/' .. type(x)
      end
      table.sort (G)
      for _, g in ipairs(G) do
        print (gnames: format (g: match (name_type)))
      end
    end
    
    globals()
    

    Running that in one of my test windows shows:

      ––– 58 lines ––– 0.2 ms –––
    
    ALTUI                table
    ALTUI_LuaRunHandler  function
    LuaTestCode3         function
    _G                   table
    _KEY                 function
    _NAME                string
    _VERSION             string
    assert               function
    bit                  table
    collectgarbage       function
    coroutine            table
    debug                table
    dofile               function
    error                function
    gcinfo               function
    getfenv              function
    getmetatable         function
    io                   table
    ipairs               function
    jit                  table
    json                 table
    lfs                  table
    load                 function
    loadfile             function
    loadstring           function
    luup                 table
    math                 table
    module               function
    newproxy             function
    next                 function
    os                   table
    package              table
    pairs                function
    pcall                function
    pretty               function
    pretty_old           function
    print                function
    rawequal             function
    rawget               function
    rawlen               function
    rawset               function
    require              function
    scene_1              function
    scene_10001          function
    scene_10002          function
    scene_2              function
    scene_3              function
    scene_4              function
    select               function
    setfenv              function
    setmetatable         function
    string               table
    table                table
    tonumber             function
    tostring             function
    type                 function
    unpack               function
    xpcall               function
    

    Notice that, unlike the openLuup console's System > All Globals menu, this simple code does not winnow out the standard Lua globals.



  • @akbooer said in openLuup: Suggestion:

    Perhaps after breakfast...

    What's for breakfast - bangers & mash?

    That's helpful. Quickly identified four vars that were global, when they shouldn't have been, in the test code. It's amazing how they can slip through a manual visual check of the code.



  • Glad that did the trick...

    ...I’ve just thought of an easier way – I could just add the Lua Test Code environment to the System > All Globals page!

    (Breakfast was, in fact, crumpets and maple syrup.)



  • @akbooer said in openLuup: Suggestion:

    just add the Lua Test Code environment

    If possible that would be good.



  • @a-lurker said in openLuup: Suggestion:

    If possible that would be good.

    Done!


Log in to reply