openweather plugin ?

[therealdb]

@buxton sorry, I’ve moved to MSR and mostly far from *luup.

[Buxton]

@therealdb Well that's a shame. One more nail in the coffin. I'll probably move to HA as soon as the various versions of the software are consolidated. It's a great platform, but for my needs, it is still too subject to breaking structural changes.

[toggledbits]

I suspect it's trying to delete variables it no longer needs. Newer versions of Vera Luup will delete a state variable if you pass nil for the value, but I'm not sure if openLuup does that or not.

[therealdb]

@buxton my strategy at the moment is to use my Vera as a Zwave server, with some minor code automations still running on it because moving 4 years of code and scenes is not trivial. But the logic is in MSR and I’m using home assistant to get what I’m missing (ecovacs, nest, bmw, energy dashboard). Honestly, if used liked I’m doing, HASS is very stable, my Vera too and the rest is done by my own system written in C#, that it’s able to talk to them all and orchestrate complex things when in MSR it’s not possible at the moment (ie intercept mqtt messages and parse them to execute complex actions). But I’m confident Patrick will further evolve it.

[Buxton]

@toggledbits Yes, I think that's a large part of the problem as I'm seeing the same behavior with deleted groups in various sensors. The sensor groups flop between nil and empty in the attempt of trying to delete the variable.

There seems to be a separate issue of the openLuup log not picking up on variables for your various plugins log entries.

I'm guessing this has to do with assigning the luup log function to a table and then calling a truncated name ie L(...) when writing to the log. So there is some scope issue going on that is different on openLuup from that of a Vera, brought about by a level of abstraction.

[Buxton]

@therealdb Yes, that's where I'm headed too. Agreed that Hass is very stable. It's just that there are real structural changes being made all the time, and before I sink my time into learning the details of the software, I want to be sure that pretty much everything is final in the engine.

[akbooer]

@toggledbits said in Reactor scope issues:

I suspect it's trying to delete variables it no longer needs. Newer versions of Vera Luup will delete a state variable if you pass nil for the value, but I'm not sure if openLuup does that or not.

No, it doesn’t.

You can, of course, delete them manually from the console, or just delete the whole device.

[akbooer]

@buxton said in Reactor scope issues:

I'm guessing this has to do with assigning the luup log function to a table and then calling a truncated name ie L(...) when writing to the log. So there is some scope issue going on that is different on openLuup from that of a Vera, brought about by a level of abstraction.

Sorry, but I have absolutely no idea what this means.

[toggledbits]

@buxton said in Reactor scope issues:

There seems to be a separate issue of the openLuup log not picking up on variables for your various plugins log entries.
I'm guessing this has to do with assigning the luup log function to a table and then calling a truncated name ie L(...) when writing to the log

I'm with @akbooer on this; I have no idea what it means. I don't know what "picking up on variables" means or what it has to do with the log, as these are completely separate concepts that are only connected through intentional coding, nothing implicit. I don't know what "assigning the luup log function to a table" means... I don't think I do that; certainly not in the Reactor plugin. The L() function, which is a first-class function definition, calls luup.log() directly.

I'm not at all clear what your expectations are or what problem you are reporting. The nil issue will be an openLuup peculiarity but will likely only happen when the ReactorSensor starts/restarts (that's when it attempts that cleanup) and is completely benign (although it would be nice if openLuup implemented Vera Luup's functionality here). You can probably make those messages go away yourself by just deleting those variables with nil using openLuup's UI/control panel (delete icons are shown in your screen shot) since Reactor isn't able to on openLuup, but the effect should be the same. If there's another issue you're worried about, I'm not seeing it, at least, not based on what you've explained and posted so far.

[akbooer]

@toggledbits said in Reactor scope issues:

although it would be nice if openLuup implemented Vera Luup's functionality here

I can easily do this. I didn’t previously because, originally, Vera didn’t do this, and then, later, it was an undocumented side effect. Finally, IIRC, it was actually endorsed.

[Buxton]

@toggledbits @akbooer Sorry, I will try to be clearer.
" I don't know what "assigning the luup log function to a table" means"

In many of Patrick's plugins, he uses a global lua table to hold plugin data and functions. He assigns shorthand names that call common luup functions, then stores those truncated names in the table. Then the first class functions are called from the table. I believe it is this abstraction that is contributing to log entries that show nil values, as direct calls of "luup.log" do not show nil values. The technique should work in openluup, and most often it does, but sometimes it doesn't.

Here's an example from the log where it does not work:

2022-01-15 14:13:12.551   luup.variable_set:: 258.urn:micasaverde-com:serviceId:HaDevice1.CommFailure was: 0 now: 0 #hooks:0
2022-01-15 14:13:12.551   luup.variable_set:: 258.urn:micasaverde-com:serviceId:HaDevice1.CommFailureTime was: 0 now: 0 #hooks:0
2022-01-15 14:13:12.551   luup_log:149: Reactor: Starting nil (#nil)
2022-01-15 14:13:12.551   luup.variable_set:: 149.urn:toggledbits-com:serviceId:Reactor.Message was: Starting Unused1 now: Starting Basic Functions #hooks:0
2022-01-15 14:13:12.552   luup.variable_set:: 265.urn:toggledbits-com:serviceId:ReactorSensor.Invert was: nil now:  #hooks:0
2022-01-15 14:13:12.552   luup.variable_set:: 265.urn:toggledbits-com:serviceId:ReactorSensor.Invert was:  now: nil #hooks:0

In the log entry "luup_log:149: Reactor: Starting nil (#nil)" the text of the log entry is there "Reactor: Starting", but the variable following the text is nil. This is what I meant by "picking up on variables". The log entries are being displayed, but anything that is a variable is showing as nil. The variables themselves are not actually nil because I can see from program execution that they are doing the job that they're supposed to be doing. It is only in the log entries that they show as nil, at least insofar as what is visible to me.

As for using nil to delete a variable, that seems to be understood and is separate from the log problem.

I believe that this is a scope problem, thus the title of the post. But I don't believe this is a reactor scope problem in that the same issue does not occur on the Vera itself. So for whatever reason, in openLuup, the scope of the variable being displayed in the log is different from the scope of the log function--that the value of the variable is somehow hidden from the function.

This is a problem as it relates to the readability of the log, an annoyance more than anything, so I have no expectations to have it fixed. In my original screenshots, you can see multiple log entries that display as nil, so that's why I brought this to your attention as I felt that if there are scope issues at work with the logging function, then it could be happening elsewhere as well.

The only other thing that I would add is that in my startup lua, I call a module in the _G space so that I can access functions in the lua section of Reactor activities. My call is _G.myStartUpLua = require("myStartUpLua") I don't believe that this should have an effect on the log, but perhaps it does.

[toggledbits]

@buxton said in Reactor scope issues:

In many of Patrick's plugins, he uses a global lua table to hold plugin data and functions. He assigns shorthand names that call common luup functions, then stores those truncated names in the table.

Umm... no, I don't think I do. That actually sounds like something I would very specifically not do. Not a big fan of globals; I only use them where Luup forces me to.

Can you post some code that shows what you think that is?

Here, for example, is the definition of the log function L() commonly used in Reactor, which is a model/function I use frequently...

local function L(msg, ...) -- luacheck: ignore 212
    local str
    local level = defaultLogLevel or 50
    if type(msg) == "table" then
        str = tostring(msg.prefix or _PLUGIN_NAME) .. ": " .. tostring(msg.msg or msg[1])
        level = msg.level or level
    else
        str = _PLUGIN_NAME .. ": " .. tostring(msg)
    end
    str = string.gsub(str, "%%(%d+)", function( n )
            n = tonumber(n, 10)
            if n < 1 or n > #arg then return "nil" end
            local val = arg[n]
            if type(val) == "table" then
                return dump(val)
            elseif type(val) == "string" then
                return string.format("%q", val)
            elseif type(val) == "number" and math.abs(val-os.time()) <= 86400 then
                return tostring(val) .. "(" .. os.date("%Y-%m-%d.%X", val) .. ")"
            end
            return tostring(val)
        end
    )
    luup.log(str, math.max(1,level))
--[[ ???dev if level <= 2 then local f = io.open( "/etc/cmh-ludl/Reactor.log", "a" ) if f then f:write( str .. "\n" ) f:close() end end --]]
    if level == 0 then if debug and debug.traceback then luup.log( debug.traceback(), 1 ) end error(str, 2) end
end

It's just a plain local function. No global in a table Luup function reassignment magic anything, just a straight function that gets use in a vanilla way:

L("Sensor %1 (%2) first run, setting up new instance...", tdev, luup.devices[tdev].description)