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


setTimeout beyond 74 days...


jgab

Recommended Posts

It seems like setTimeout can only handle ms values less than or equal to 2147483648-1 (~24 days)

Try

Please login or register to see this code.

If you need to set timers further into the future you need to patch setTimeout and clearTimeout

Please login or register to see this code.

Updated with correct values thanks to @petergebruers

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

so max is 6 * 2^30, set Timeout is based on boost:asio, posix time overflow?

Link to comment
Share on other sites

  • Topic Author
  • 1 hour ago, tinman said:

    so max is 6 * 2^30, set Timeout is based on boost:asio, posix time overflow?

    Maybe, but why 6 * ... and why not 2^32-1 ?

    Link to comment
    Share on other sites

    1 hour ago, tinman said:

    is based on boost:asio, posix time overflow?

    Interesting question. Not a clue, that number seems a bit weird, but I guess in the end they are kernel timers and I am reasonably sure their resolution is ns and range is 64 bit.

     

    cat /proc/timer_list|grep LuaEnv -A 1

     

    Those might me the timers I use in Lua...

     

    I am not an expert on this, but I deduce the kernel timers use ktime_get so monotic time... Which may be good or a bad thing depending on what you want to do, eg do you care about DST changes? The Linux docs tell me "Useful for reliable timestamps and measuring short time intervals accurately. Starts at system boot time but stops during suspend.". If you want to measure 1 day I guess sometimes that means "exactly 24 h from now on" and sometimes it means "at exactly the same 24 h clock time" which in most cases is quite the same (when measuring 24 do we care about clock drift? Probably not.) - but not 2x per year or when people manually adjust the wall clock.

     

    Edit: of course @tinman and @jgab don't need me to tell them that... I try to write posts for a broader audience which might be unaware of the subtleties of time measurement and representation...

    Edited by petergebruers
    Link to comment
    Share on other sites

    definitely wired number, on the other hand 74 days uptime is a lot :P

    Link to comment
    Share on other sites

    :-D If Fibaro keeps doing HC (beta) firmware releases fast enough, I don't need 74 days.

    Link to comment
    Share on other sites

  • Topic Author
  • Well, in my emulator setTimeout behaves "better" and I provided a scene for a user that turns on/off lights at Earth Hour...next year... well it turned on and off the light in the middle of the night the other day :-) That's how I became aware of this strange behaviour. No guarantee that it actually works correctly for all values less than 6442450944, depending how it wraps/truncates... but at least it doesn't return immediately. Empirically, setTimeout seems to be well synched with os.time for periods of weeks at least, so I suspect they derive from the same "source". Hmm, what happens when it adjust the time with the (now working) NTP servers? I expect (Linux) timers adjust...or?

    Daylight savings is another story but they may soon be gone...

    Link to comment
    Share on other sites

    7 hours ago, jgab said:

    No guarantee that it actually works correctly for all values less than 6442450944

     

    This made me thinking... It probably uses a signed integer, somewhere, instead of an unsigned integer, 32 bit, then it suddenly becomes negative after 2^31.

     

    So 2147483648 -1 == 0x7FFFFFFF should work and 2147483648 == 0x80000000 should return immediately.

     

    Please login or register to see this code.

    Aha. That would mean rollover after 24.8 days.

     

     

     

     

     

     

     

    Link to comment
    Share on other sites

  • Topic Author
  • 4 hours ago, petergebruers said:

     

    This made me thinking... It probably uses a signed integer, somewhere, instead of an unsigned integer, 32 bit, then it suddenly becomes negative after 2^31.

     

    So 2147483648 -1 == 0x7FFFFFFF should work and 2147483648 == 0x80000000 should return immediately.

     

    Please login or register to see this code.

    Aha. That would mean rollover after 24.8 days.

     

     

     

     

     

     

     

    Good spot! Kick myself for not testing it - can't change title of the thread :-) 

    Link to comment
    Share on other sites

    13 hours ago, petergebruers said:

    Aha. That would mean rollover after 24.8 days.

     

    and not we know where the 6*2°30 (or 1.5*2^32) is coming from :) 

     

    22 hours ago, tinman said:

    definitely wired number, on the other hand 74 days uptime is a lot :P

     

    ok, we need more than 74 24 days :P  image.png.ec2eecf94d3b2c944613ad066d4eb498.png

    Edited by tinman
    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
    Reply to this topic...

    ×   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...