We have moved at community.getvera.com

Author Topic: openLuup vs Vera luup.sunrise()  (Read 448 times)

Offline a-lurker

  • Hero Member
  • *****
  • Posts: 872
  • Karma: +66/-8
openLuup vs Vera luup.sunrise()
« on: April 10, 2017, 05:06:58 am »
Encountered a slight problem with one of my plugins. Vera returns an integer whereas openLuup returns a float for luup.sunrise(). Noting that the underlying representations are almost certainly floats.

A problem crops up when you convert the openLuup luup.sunrise() value to a string and then back to a number as you might do when storing and retrieving a plugin variable. The precision is probably not maintained during these two conversion processes, so you end up with a number ever so slightly different from what you started with. So in my case and with my hardware openLuup prints TRUE and Vera prints FALSE for the code below. Importantly, the printed outcome may depend on the sunrise value. Sometimes the code may work and other times it may not depending on the conversions. The code can be put in the Lua test boxes to see the result in the log files.

This can be fixed in my case by adding some biasing to the values before testing them but that's a bit of hack. Should openLuup return a float or an integer value?

Code: [Select]
local PLUGIN_NAME  = 'TEST_float_compare'

local DEBUG_MODE = true

local function debug(textParm, logLevel)
    if DEBUG_MODE then
        local text = ''
        local theType = type(textParm)
        if (theType == 'string') then
            text = textParm
        else
            text = 'type = '..theType..', value = '..tostring(textParm)
        end
        luup.log(PLUGIN_NAME..' debug: '..text,50)

    elseif (logLevel) then
        local text = ''
        if (type(textParm) == 'string') then text = textParm end
        luup.log(PLUGIN_NAME..' debug: '..text, logLevel)
    end
end


local function testFloatCompare()
    local nextReset = luup.sunrise()
   
    -- this imitates a Luup plugin variable being stored and retrieved
    local countersNextReset = tostring(nextReset)
    countersNextReset = tonumber(countersNextReset)

    -- if dawn has just occurred then luup.sunrise() will leap ahead by approx 24 hours
    -- reset the resettable kWh counters in the meter
    debug(nextReset)
    debug(countersNextReset)
     
    if (nextReset > countersNextReset) then
        debug('TRUE')
    else
        debug('FALSE')
    end 

     debug(nextReset)
     debug(countersNextReset)
end

testFloatCompare()

return true

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 6387
  • Karma: +290/-70
  • "Less is more"
Re: openLuup vs Vera luup.sunrise()
« Reply #1 on: April 10, 2017, 05:15:49 am »
openLuup should, on the whole, be compatible with Vera.  So it should return an integer.

Are you saying that simply truncating the returned result is not adequate?  That would be the fix I would put into the openLuup code if it works as expected.

Your real problem, IMHO, is testing for equality between two floating point numbers which is never a good idea.
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: +290/-70
  • "Less is more"
Re: openLuup vs Vera luup.sunrise()
« Reply #2 on: April 12, 2017, 06:49:00 am »
The latest development branch update (2017.04.12) has a fix to return integer values for luup.sunrise() and luup.sunset().
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.