intval and variables

[nullx8]

somehow this does work

local lul_temp = luup.variable_get("urn:upnp-org:serviceId:TemperatureSensor1","CurrentTemperature", 60)
if (tonumber(lul_temp) > 26) then
  luup.call_action("urn:upnp-org:serviceId:SwitchPower1","SetTarget",{ newTargetValue="1" },132) -- fan on
end

but this doesn’t if (tonumber(luup.variable_get("urn:upnp-org:serviceId:TemperatureSensor1","CurrentTemperature", 60)) > 26) then luup.call_action("urn:upnp-org:serviceId:SwitchPower1","SetTarget",{ newTargetValue="1" },132) -- fan on end

any idea why that is ?
is it required to use variable containers … even if the information i just used once ?

i know. RTFM is not my friend

[a-lurker]

I fell for this one the other day:

luup.variable_get

can return more than one variable:

http://wiki.micasaverde.com/index.php/Luup_Lua_extensions#function:_variable_get

and tonumber() doesn’t like it, so you need to use an intermediate variable as per “lul_temp” in your case.

[nullx8]

thanks a-lurker

i understand what you saying, but it still makes zero sense to me, guess this is another lua “feature”

looks like a core-bug where the function tonumber() is not able to manage the returned items properly.

[garrettwp]

Vera’s luup code for variable_get will return multiple values. The returns the value as well as the last time the value was changed. I believe this returns as an array or map. So you essence you are trying to convert the array/map into a number which will not work. By retrieving the value first and putting into into a variable and than converting it will work. It is an odd issue, but you best to retrieve the value and store it into a variable and than due the conversion.

• Garrett

[a-lurker]

As above.

RTFM fails once again - once MCV decide I’m not a spammer; as I’ve been stopped from updating the documentation!! - I can put this in the FM.

[futzle]

Here is the reason why tonumber(luup.variable_get(…)) fails:

luup.variable_get() returns a list of two values. At index [1] is the variable’s value (a string). At index [2] is the Unix timestamp of when the variable last changed (an integer around 1.3 billion). If you assign this list to one variable, the timestamp is just discarded: that’s how Lua works.

tonumber() takes a list of two values. At index [1] is the string that contains the digits to be converted. At index [2] is the base to use when converting the string. The base can be any number >= 2 and <= 36. Typically it is 2 or 8 or 16 because in IT you tend to get numbers written out in binary or octal or hex. If the base is nil (or omitted entirely, which is the same as passing nil) then Lua assumes the human-centric base of 10.

A Unix timestamp of 1.3 billion is not in the range 2 to 36. So you get an unhelpful error.

Typical code like this:

local v = luup.variable_get(serviceID, name)
local i = tonumber(v)

is more explicitly written:

local v, t = luup.variable_get(serviceID, name)
local i = tonumber(v, 10)

where t is assigned to but never used, and the 10 pops up out of nowhere.

This wrong code:

-- Wrong!
local i = tonumber(luup.variable_get(serviceID, name))

is the same as this wrong code:

-- Wrong!
local v, t = luup.variable_get(serviceID, name)
local i = tonumber(v, t)

If you were desperate to avoid the temporary variable you could construct an anonymous table and then index it:

-- But don't.
local i = tonumber(({luup.variable_get(serviceID, name)})[1])

I bet that is quite a bit less efficient too.

[RexBeckett]

You can also just add another pair of parenthesis to eliminate the timestamp:

local i = tonumber((luup.variable_get(serviceID, name)))

[futzle]

@RexBeckett

You can also just add another pair of parenthesis to eliminate the timestamp:

Huh, I did not know that. It’s all explained in section 2.5 of the Lua manual. Turns out you can do this too, for obscure reasons:

local i = tonumber(luup.variable_get(serviceID, name), 10)

[a-lurker]

Mmmm - nice. I think it all went wrong at index[1], rather than at index[0].

[RexBeckett]

@futzle

[quote=“RexBeckett”]You can also just add another pair of parenthesis to eliminate the timestamp:

Huh, I did not know that. It’s all explained in section 2.5 of the Lua manual. Turns out you can do this too, for obscure reasons:

local i = tonumber(luup.variable_get(serviceID, name), 10)

Yes I discovered that this worked too. I guess it follows Lua’s handling of excess arguments and discards the timestamp. I think I used that form in most of my plugins until I decided that the additional two brackets were tidier and more likely to survive updates to Lua.

[nullx8]

@futzle

local i = tonumber(luup.variable_get(serviceID, name), 10)

it apears like the “bug/feature” is in tonumber where the defaulting simply not works.
well works but too much microsoft style assuming things instead of falling back to the default … whatever

just tested this … if always add the default base (10) it works just fine.

i guess that is the way to go … since tmp variables are somethings i dont really like for a 1 time shoot like this.

[a-lurker]

tostring() also suffers; this logs a serious error and halts the program:

luup.log(tostring(luup.variable_get('urn:I_Made_This_Up', 'Testing',1)))

This code with the extra brackets correctly logs nil, if the SID or ID are invalid or the string if they are valid.

luup.log(tostring((luup.variable_get('urn:I_Made_This_Up', 'Testing',1))))

In this case there is no second parameter like the “base” parm in tonumber() to override.

The danger with the double brackets is that; some other keen programmer may come along later and “clean them up”, so using temp variables may be more explicit.

[RexBeckett]

This is not a bug. luup.variable_get() returns two results: The string value and the timestamp of when it was last updated. This is a very useful feature. If you want to ignore the timestamp, use Lua’s handy mechanism for constraining the return to a single value by enclosing it in parenthesis.

Any keen programmer who goes around removing parenthesis without considering the consequences deserves everything they get. ;D

[a-lurker]

Yes - I understand it’s not a bug - although in the past I thought it was. It get’s back to explaining this clearly with an example here:

http://wiki.micasaverde.com/index.php/Luup_Lua_extensions#function:_variable_get

and I would do that but MCV have me black balled at the moment.

[RexBeckett]

MCV have me black balled at the moment.

Whatever did you do to deserve that? Did you mention [i]Fibaro HC2[/i] in complimentary terms? Did you infer that [i]UI7[/i] is all smoke and mirrors? Oh, wait, something just killed Vera...

[nullx8]

how do i actually print (somethings like print_r in php) the real output
for debugging reasons (of course)

a-lurker: my account was unlocked quite quickly by someone from MCV.
i can search the email of the person if you interested

[RexBeckett]

You can’t print directly from Vera but you can write to the log using luup.log(“string to be logged”)

ZeroBrane Studio allows the use of the print statement when in debug mode. This along with single-step execution, breakpoints and variable watch can be very helpful when debugging Lua for scenes or plugins.