Jump to content

Welcome to Smart Home Forum by FIBARO

Dear Guest,

 

as you can notice parts of Smart Home Forum by FIBARO is not available for you. You have to register in order to view all content and post in our community. Don't worry! Registration is a simple free process that requires minimal information for you to sign up. Become a part of of Smart Home Forum by FIBARO by creating an account.

 

As a member you can:

  •     Start new topics and reply to others
  •     Follow topics and users to get email updates
  •     Get your own profile page and make new friends
  •     Send personal messages
  •     ... and learn a lot about our system!

 

Regards,

Smart Home Forum by FIBARO Team


  • 0

Lua getValue and Debug returns wrong value


snowflakes

Question

Hi,

 

HC2 Scene:

 

--[[
%% properties
%% events
%% globals
--]]

local deviceWallPlug = 200

local currentStateOfWallPlug

 

fibaro:debug("Initial state of WallPlug")
currentStateOfWallPlug = fibaro:get(deviceWallPlug, 'value')
fibaro:debug("currentStateOfWallPlug: " .. currentStateOfWallPlug)

 

fibaro:debug("Turn On")
fibaro:call(deviceWallPlug, 'turnOn')

 

currentStateOfWallPlug = fibaro:get(deviceWallPlug, 'value')
fibaro:debug("currentStateOfWallPlug: " .. currentStateOfWallPlug)

 

fibaro:sleep(2 * 1000)

 

fibaro:debug("Turn Off")
fibaro:call(deviceWallPlug, 'turnOff')

 

currentStateOfWallPlug = fibaro:get(deviceWallPlug, 'value')
fibaro:debug("currentStateOfWallPlug: " .. currentStateOfWallPlug)
 

Actual output:

[DEBUG] 22:54:08: Initial state of WallPlug
[DEBUG] 22:54:08: currentStateOfWallPlug: 0
[DEBUG] 22:54:08: Turn On
[DEBUG] 22:54:08: currentStateOfWallPlug: 0
[DEBUG] 22:54:10: Turn Off
[DEBUG] 22:54:10: currentStateOfWallPlug: 1

 

Expected output:

[DEBUG] 22:54:08: Initial state of WallPlug
[DEBUG] 22:54:08: currentStateOfWallPlug: 0
[DEBUG] 22:54:08: Turn On
[DEBUG] 22:54:08: currentStateOfWallPlug: 1
[DEBUG] 22:54:10: Turn Off
[DEBUG] 22:54:10: currentStateOfWallPlug: 0

 

 

Why is this? It seems to be returning its previous value.

 

Can someone please explain?

Edited by snowflakes
Link to comment
Share on other sites

10 answers to this question

Recommended Posts

  • 1

fibaro:get(deviceWallPlug, 'value') returns 2 values, the  state and the time of change.

to number takes an optional  second value that is the number base for conversion.

So tonumber(fibaro:get(deviceWallPlug, 'value')) sends the time of change as second arg to to number - and time is in epoc - seconds since January 1971  which is interpreted as a very large number base.

 

fibaro:getValue returns only  one value, the state. Also, if you wrap a Lua function returning multiple values in parenthesis it will only return the first  value.

tonumber((fibaro:get(deviceWallPlug, 'value'))) will work.

 

The state for "binary" devices on the HC2 is "0" and  "1" if I remember correctly, it  became true/false in the HC3 - so your code is ok in that respect.

 

However, I admit the behaviour of your example  is  strange.

 

What happens if you do a small sleep just after the turnOn and before you read the value?

 

 

 

Link to comment
Share on other sites

  • 0

As far as I know the value has true/false state and not a number.

please try like that (at all lines where you request the value)

currentStateOfWallPlug = tonumber(fibaro:get(deviceWallPlug, 'value'))

Edited by cag014
Link to comment
Share on other sites

  • 0
  • Inquirer
  • Thank you for trying to help me!

    I need more help, please.

     

    Unfortunately

    currentStateOfWallPlug = tonumber(fibaro:get(deviceWallPlug, 'value'))

    resulted in:

    [ fatal] Unknown exception: /opt/fibaro/scenes/91.lua:13: bad argument #2 to 'tonumber' (base out of range)

     

     

    So I tried to split it up and research the variable types:

    local currentStateOfWallPlug
    local currentStateOfWallPlugNumber

     

    fibaro:debug("Initial state of WallPlug")
    currentStateOfWallPlug = fibaro:get(deviceWallPlug, 'value')
    --currentStateOfWallPlug = tonumber(fibaro:get(deviceWallPlug, 'value'))

     

    fibaro:debug("TYPE currentStateOfWallPlug: " .. type(currentStateOfWallPlug))
    fibaro:debug("currentStateOfWallPlug: " .. currentStateOfWallPlug)

     

    currentStateOfWallPlugNumber = tonumber(currentStateOfWallPlug)
    fibaro:debug("TYPE currentStateOfWallPlugNumber: " .. type(currentStateOfWallPlugNumber))
    fibaro:debug("currentStateOfWallPlugNumber: " .. currentStateOfWallPlugNumber)

     

    Output:

    [DEBUG] 08:35:30: Initial state of WallPlug
    [DEBUG] 08:35:30: TYPE currentStateOfWallPlug: string
    [DEBUG] 08:35:30: currentStateOfWallPlug: 0
    [DEBUG] 08:35:30: TYPE currentStateOfWallPlugNumber: number
    [DEBUG] 08:35:30: currentStateOfWallPlugNumber: 0

     

    I still get:

    currentStateOfWallPlugNumber: 0

    after:

    fibaro:call(deviceWallPlug, 'turnOn')

    Link to comment
    Share on other sites

    • 0
  • Inquirer
  • Hi again,

     

    @jgab

    Thank you! ❤️

     

    fibaro:sleep(40)

    after:

    fibaro:call(deviceWallPlug, 'turnOn')

    makes:

    currentStateOfWallPlug = fibaro:getValue(deviceWallPlug, 'value')

    return the correct value, of 1.

     

    fibaro:sleep(35)

    was not enough, in some cases, i.e. some of my test runs.

     

    Strange that this is needed! But thank you SO MUCH for that suggestion and for all the information about the functions get(), getValue() and tonumber() and that "wraping a Lua function only returns the first value"! :D

    You have been very helpful!!!

     

    HC2 still use 1/0 not True/False.

     

    @Sjakie 

    According to:

    Please login or register to see this link.

    The defined devices in the header only enables what should trigger (automatically run) the scene.

    Adding your suggestion:

    value=200

    or

    200 value

    according to the manual,

    did not solve the problem, but thank you for your attempt to help me! ❤️

     

     

    A workaround has been found. I wouldn't call this a real solution to the problem. To me, this seems more like a bug in the Fibaro OS. I am running the latest version, 4.620 (no updates are available under Configuration).

    Edited by snowflakes
    Link to comment
    Share on other sites

    • 0

     

    26 minutes ago, snowflakes said:

    A workaround has been found. I wouldn't call this a real solution to the problem. To me, this seems more like a bug in the Fibaro OS. I am running the latest version, 4.620 (no updates are available under Configuration).

     

    Some of the z-wave experts  may correct  me ( @petergebruers) but  turnOff sends the command to the device and then the device reports back, first then is the value in the HC2 (or HC3) updated - which makes sense but make fibaro:call  asynchronous (returns immediately  without waiting for the result)

    The way  to fix  that  would be to make the fibaro:call synchronous  so that it hanged until the device reported back (or timed out).

    The side-effect of doing it synchronous would also be to allow fibaro:call to return values or  more detailed error  codes.

     

    I have complained about that extensively here

     

    If we needed a asynchronous fibaro:call there could  be a special command for that - but we have setTimeout to allow us to do other stuff while we wait.

    In general, an asynchronous version (where we have no way of  synching anyway) is not helpful for the average developer  and  only a source of "strange bugs"...

     

    Searching for  "coroutines" in the forum I seem to be almost the only one asking for them...

    Edited by jgab
    Link to comment
    Share on other sites

    • 0
  • Inquirer
  • @jgab

    Thank you again! Very insightful!

    I didn't think of the two-way communication of the z-wave protocol and the delay it naturally results in. Nor did I think of synchronous and asynchronous functions / programming. Of course you are right! Not a bug.

     

    The Fibaro products, hardware wise, are very sleek and well designed. The software and documentation, however, manuals and especially tutorials (in which you would expect more explanations of why something is a certain way) are atrocious. The English used is grammatically incorrect and the sentences are often illogical and incomplete, which makes the documentation unprofessional. You would think a company of this size would hire someone whose native language is English.

     

    Software wise, I think it is ridiculous to represent time in a user interface in just seconds, not divided into fields of hours, minutes and seconds, just to give the the user the option of the full range of 2^16 = 65536, just to give an example. User interfaces should not be designed based on the underlying technology. I have seen surveys and other applications for user input, where the field layouts were designed based on the tables and fields of the database, not with the fields ordered by how a user logically would enter the information. This thinking, of technology before usefulness, obviously has permeated the rest (no pun intended) of the Fibaro Lua API.

     

    The workaround for this is to, at least, accompany the products with proper documentation.

     

    So, not a stab at you personally jgab, this critique is aimed at Fibaro. 

    Edited by snowflakes
    Link to comment
    Share on other sites

    • 0

    @snowflakes I think you jump to conclusions a bit fast with some of your critique.

     

    To give one example, the use of the "seconds" is quite common, look on the internet for Epoch or Unix Timestamp. That gives us some features to deal with for example summer/winter time or timezones. 

    Link to comment
    Share on other sites

    • 0
  • Inquirer
  • @SmartHomeEddy

     

    This field of just seconds in the Fibaro user interface is intended for non-programmer users. How the time is represented is what is important to the HC user, not if it is stored in an int or bigint or whatever. How the programmer then re-formats, stores and uses this data of hours, minutes and seconds is up to him/her and his/her employer. I am fully aware of Epoch and Unix Timestamps, that's beside the point. The distinction and separation of interface and technology is my concern.

     

    Again, documentation and tutorials written by Fibaro should include information about the potential delay some function calls can suffer from.

     

    My definition of a software developer is someone who hides complexity for the end user. I just wish more programmers would see it that way.

    Edited by snowflakes
    Link to comment
    Share on other sites

    • -1

    You want a human readable time format? There is no consensus but IMHO this comes close

     

    Please login or register to see this link.

     

    If you have read that rfc3339 you'll have a reasonable understanding about "complications with time and its representation"

     

    Please login or register to see this code.

    If you've read that ... Yes... there are 61 seconds in a minute, sometimes...

     

    And........... Hehehehe, we haven't event talked about what is time, and which clock you want to use?

     

    Posix defines... Especially the CLOCK_MONOTONIC is an important one, if you want to measure time and not get shot in the foot by doing some add/subtract on the CLOCK_REALTIME aka WALL clock.

     

    Please login or register to see this link.

    Please login or register to see this code.

    Edited by petergebruers
    • Like 1
    Link to comment
    Share on other sites

    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.

    Guest
    Answer this question...

    ×   Pasted as rich text.   Paste as plain text instead

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.

    ×
    ×
    • Create New...