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


Search the Community

Showing results for tags 'timer'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • FIBARO Community
    • FIBARO Portal and Forum policy
    • FIBARO
    • Say hello!
    • Off-topics
  • FIBARO Update
    • FIBARO System Update
    • FIBARO Mobile Update
  • FIBARO Community Support
    • Scenes and Interface
    • FIBARO Products
    • FIBARO Mobile
    • FIBARO HomeKit
    • FIBARO Assistant Integrations
    • Other Devices / Third-party devices
    • Tutorials and Guides
    • Home Automation
    • Suggestions
  • FIBARO Społeczność
    • FIBARO
    • Przywitaj się!
    • Off-topic
  • FIBARO Aktualizacja
    • FIBARO System Aktualizacja
    • FIBARO Mobile Aktualizacja
  • FIBARO Wsparcie Społeczności
    • Sceny i Interfejs
    • FIBARO Urządzenia
    • FIBARO Mobilnie
    • FIBARO HomeKit
    • Integracja z Amazon Alexa i Google Home
    • Urządzenia Firm Trzecich
    • Poradniki
    • Automatyka Domowa
    • Sugestie

Categories

  • Scenes
  • Virtual Devices
  • Quick Apps
  • Icons

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Facebook


Google+


Skype


Website URL


WhatsApp


Country


Gateway/s


Interests

Found 17 results

  1. I want to activate a manual scene (Vaatwas Timer (number 2 in the picture)) with my ZRC-90. In this case I created a scene (Timer Vaatwas Active (number 1 in the picture)) that should activate the manual scene "Vaatwas Timer". The scene “Vaatwas Timer” is a manual scene and set to a certain time. I do not want this scene to be active every day at the programmed time and therefore I only want it to be active after I push and hold button 8 on my ZRC-90. As soon as I push button 8 the other scene is activated and does not wait until the time that is set in the scene. What do I need to do so that when I’ve pushed the botton, the scene “Vaatwas Timer” is active but not triggerd and turns on my dishwasher immediately. Short: when I hold down button 8 on my ZRC-90 I want my dishwasher (connected to the powerplug “Vaatwas PP2") to start at 23:30 the day I push the button and not immediately Button 8 hold --> activate Scene "Vaatwas Timer" --> Scene starts dishwasher at 23:30 as set in the scene
  2. jgab

    Scene timer

    Version 2.3

    185 downloads

    This is a scene that runs in the background and schedules your scenes that have a '%% timer' included (the original thread for this scene is <here>) Scenes can trigger on devices changing status (%% properties), when globals change values (%% globals) and events (%% events) etc. However, there is no trigger for time or timers - to allow a scene to be started at a specified time. Well, here is a fix for that... and it makes it very easy to start scenes at specified times of day including sunrise/sunset, at regular intervals, at specified weekdays, and at specified months... The scene below watches other scenes and allows them to declare "%% time" headers that they will be triggered on When the Timer.lua scene is installed and started (no configuration needed) we should be able to forget about it and turn our attention to scenes that we want to be triggered at given times. It's a perfect "tool" to have running on the HC2 as it makes it really easy to add a scene and schedule it to run at a given time. A simple added header to the scene is all that is needed: --[[ %% properties %% events %% globals %% time 15:00 --]] print("Scene started at 15:00") This scene will be run at 15:00 every day. To stop it from being scheduled, just remove the "%% time" lines from the header and save the scene again. A more extensive example with a scene declaring multiple triggers and retrieving the trigger when the scene gets invoked; --[[ %% properties %% events %% globals %% time log 15:00 bar -- scene triggered at 15:00 every day *00:15 test -- scene triggered every 15min throughout the day --]] print("Scene started") -- Redefine fibaro:getSourceTrigger do local a,b=fibaro;b=a.getSourceTrigger;function a:getSourceTrigger()local c=b(a)local d=a:args()if type(d)=='table'and d[1]and type(d[1])=='table'then if d[1].type~= nil then return d[1]end end;return c end end local st=fibaro:getSourceTrigger() if st.type=='time' and st.time then -- do something when we get a time trigger... fibaro:debug(string.format("Triggered:%s, tag:'%s'",st.time,st.tag)) end if st.type=='time' and st.tag=='log' then -- write out log messages from the time scene fibaro:debug("Time log:") fibaro:debug(st.log) end if st.type=='time' and st.tag=='error' then -- write out error messages from the time scene fibaro:debug("Time error:"..st.log) end In the scene we also redefine fibaro:getSourceTrigger() to return our timer as an "standard" source trigger. It's not strictly necessary as time triggers are of type 'other' with the arguments coming from fibaro:args(). However, this makes it more streamlined and plays well with standard fibaro source triggers. The timer scene is "drift free" so if you declare a timer on the hour you will be called exactly on the hour, and not slowly start to drift as is very common in many home made Lua timer loops. Standard 'time' triggers look like {type='time', tag=<tag>, time=<str>} tag=<tag> is the (optional) word provided last in the time rule and helps us to identify what time rule triggered our scene. time=<str> is the time the rule is invoked (in HH:MM format) Here we also add the keyword 'log' under "%% time" to instruct the time scene to send us log statements. Log statements come in two versions {type='time', tag='log', log=<msg>} Standard log messages are sent at startup and at midnight with the log msg containing information about the time rules scheduled. It's usually nice to get some feedback that the Timer scene has scheduled our scene and for what times. {type='time', tag='error', log=<msg>} Error messages are always sent (even without the 'log' keyword). Usually due to time rules being faulty. When you enable log messages your scene will also be triggered by log messages and not only timers. You need to tell them apart. A good way to test for a time trigger that is not a log message is to test if there is a .time field in the source trigger if sourceTrigger.type=='time' and sourceTrigger.time then --- do whatever end IN that case we know that it is a proper time trigger and not a log message, as they lack the .time field. Ok, the time rules in the example are 15:00 bar This means that the scene is called 15:00 every day, with the identifier tag "bar" In the scene we get an sourceTrigger at 15:00 of type {type='time', time='15:00', tag='bar'} In the above example we just print out the tag. *00:15 test creates a repeating timer that triggers the scene every 15 minutes, and with the tag "test". We get a sourceTrigger of type {type='time', time='*00:15', tag='test'} The generic version of a time description looks like %% time <time list> <conditions> <tag> : <time list> <conditions> <tag> Examples 15:00,17:00 test creates two timers at 15 and 17 with the same tag "test". sunrise test 'sunrise' is a valid time descriptor and evaluates to todays sunrise hour. 'sunset', "dawn", and "dusk" are available too. sunrise-00:10 test We can do simple arithmetic on times (+/-) to create offsets. 15:00 wednesday test timers at 15 but only on wednesday, tag "test". 15:00 wed test days can be shortened 15:00 wed,fri test or listed. 15:00 wed..fri test or intervals. 15:00 1..7 test interval with first to seventh day of the month 15:00 lastday test Only on the last day of the month 15:00 lastweek test only in the last week of the month (number_of_days_in_month-6..number_of_days_in_month) 15:00 monday lastweek test conditions can be combined. True for Monday of the last week 15:00 monday lastweek may..aug test month conditions also available. *00:15 test interval, every 15min starting immediately (when the script starts). Ex. 12:08:33, 12:23:33, 12:38:33 ... +00:15 test interval, every 15min, starting on next even 15min interval. Ex. 12:15:00, 12:30:00, 12:45:00 ... +00:15 weekends 10:00..15:00 test combined with weekend test (sat..sun) and time interval (10:00 to 15:00) +01:00 sunrise..sunset may..sep water every hour between sunrise and sunset and between May and September call scene with tag 'water' 20:30 2020/05/28,2021/05/27,2022/05/26 earth_hour "long date" format +01:00 oct/28/10:00..dec/30/07:00 tag Long date intervals. Year can be excluded and month can be the name of the month, and time can optionally be added at the end (not sunrise/sunset) The <time list> should be seen as the times we want to schedule and the <conditions> as filters, excluding some times from the <time list> The other way to look at the list of <conditions> is that the spaces are ANDs and commas are ORs. Ex."10:00 thu,sat lasweek tag" is "10:00 ((thu OR sat) AND lastweek), tag" The complete set of conditions are: <time>..<time>, time interval in HH:MM or HH:MM:SS (but also 'sunset' and 'sunrise') <week day>..<week day>, day interval. mon..wed, Thursday..Saturday <day number>..<day number> - 1..7, first to second day in current month <month>..<month>, month interval <time>,<time> -- One or more time specifiers. Ex. 10:00,11:00 <week day>,<week day> -- One or more day specifiers. Ex. monday <day number>,<day number> -- Ex. 1,8,15,22 <month>,<month> -- One or more month specifiers. Ex. june,july,august <long date>..<long date> - YYYY/MM/DD/HH:MM. Year cane be left out and time part is optional <long date>,<long date> - 2020/may/11/10:00, may/11/10:00, may/11 alldays - same as mon..sun weekends - same as sat..sun weekdays - same as mon..sun lastday - true if last day of the month lastweek - true if last week in the month true - always return true. See example below using fibaro global to disable rules false - always return false. Effectively disabling the rule. ...and they can be combined. It's allowed to end a time rule with a comment '--'. It's just removed before parsing the rule. (Wouldn't it be nice to be able to add comments to all headers?) Ex. 15:00 monday test -- Trigger scene every Monday at 3 PM A simple example turning on a lamp (with deviceID 55) at sunset-10min and turning off the lamp at sunrise+10min on weekdays --[[ %% time log sunset-00:10 weekdays turnOn sunrise+00:10 weekdays turnOff --]] print("Scene started") -- Redefine fibaro:getSourceTrigger do local a,b=fibaro;b=a.getSourceTrigger;function a:getSourceTrigger()local c=b(a)local d=a:args()if type(d)=='table'and d[1]and type(d[1])=='table'then if d[1].type~=nil then return d[1]end end;return c end end local st=fibaro:getSourceTrigger() if st.type=='time' and st.tag='turnOn' then fibaro:call(55,"turnOn") end if st.type=='time' and st.tag='turnOff' then fibaro:call(55,"turnOff") end --[[ -- Another solution if st.type=='time' and st.time then fibaro:call(55,st.tag) end --]] The tag is useful to identify what timer you get so you don't have to test against time again (or you can use it as in the example above, as an argument to a function, fibaro:call in the above case). We can also let the tag be the name of a function called in our scene at that time. . --[[ %% properties %% events %% globals %% time log 15:00 bar *00:15 test %% autostart --]] print("Scene started") -- Redefine fibaro:getSourceTrigger do local a,b=fibaro;b=a.getSourceTrigger;function a:getSourceTrigger()local c=b(a)local d=a:args()if type(d)=='table'and d[1]and type(d[1])=='table'then if d[1].type~=nil then return d[1]end end;return c end end local st=fibaro:getSourceTrigger() function bar() print("Bar called") end function test() print("Test called") end if st.type=='time' and st.time then fibaro:debug(string.format("Triggered:%s, tag:'%s'",st.time,st.tag)) if _ENV[st.tag] then _ENV[st.tag]() end end A more advanced feature is that time rules allows for substituting in values from fibaro globals. Ex. <myTime> monday test This will fetch the value from the the fibaro global "myTime" and insert whatever value it has instead of <myTest>. If the value was "10:00" the rule would be 10:00 monday test The substitution can be anywhere in the rule and contain anything so be careful. We also watch if the value of "myTime" changes and if it does it will update the timers for the scene. One way to use this is to have a global, ex "Stop" that is set to "true" or "false". If we include that in a rule 10:00 monday <Stop> test We can easily enable/disable the rule depending on what we set "Stop" to.
  3. Edit: Sept.7. Updated to v1.1 - thanks to @10der for finding bugs and suggesting improvements. Edit: Sept.7. Updated to v1.2 - bug fixes and support for catchup Edit: Sept.7. Updated to v1.3 - tabs in time rules changed to space Edit: Sept.7. Updated to v1.4 - more bug fixes, thanks @10der Edit: Sept.8. Updated to v1.5 - support for "long date" formats and day numbers Edit: Sept.8. Updated to v1.6 - Dang. Cut and paste error in v1.5. fixed. Edit: Sept.9. Updated to v1.7 Beta - Code restructuring, faster conditions, sunset/sunrise implementation to fix midnight "bug". Support for dawn and dusk. Edit: Sep.14. Updated to v1.8B - Fix split and tabs bugs Edit: Sep.15. Updated to v1.9B - sunset calculations broken - fixed Edit: Sep.29. Updated to v2.0 - no major bugs for 2 weeks Edit: Oct.6. Updated to v2.1 - bug was introduced for keyword weekends - fixed. Edit: Oct.6. Updated to v2.2 - 2.1 caused another bug - fixed. Edit: Oct.10. Updated to v2.3 - Improved time format. HH:MM+/-hh:mm allowed. Ex. 10:00-00:05. Good to have if used with variables. Ex. <TIME>+00:05 Scenes can trigger on devices changing status (%% properties), when globals change values (%% globals) and events (%% events) etc. However, there is no trigger for time or timers - to allow a scene to be started at a specified time. Well, here is a fix for that... and it makes it very easy to start scenes at specified times of day including sunrise/sunset, at regular intervals, at specified weekdays, and at specified months... The scene below watches other scenes and allows them to declare "%% time" headers that they will be triggered on Timer scene v2.3: Timer2_3B.lua When the Timer.lua scene is installed and started (no configuration needed) we should be able to forget about it and turn our attention to scenes that we want to be triggered at given times. It's a perfect "tool" to have running on the HC2 as it makes it really easy to add a scene and schedule it to run at a given time. A simple added header to the scene is all that is needed: --[[ %% properties %% events %% globals %% time 15:00 --]] print("Scene started at 15:00") This scene will be run at 15:00 every day. To stop it from being scheduled, just remove the "%% time" lines from the header and save the scene again. A more extensive example with a scene declaring multiple triggers and retrieving the trigger when the scene gets invoked; --[[ %% properties %% events %% globals %% time log 15:00 bar *00:15 test --]] print("Scene started") -- Redefine fibaro:getSourceTrigger do local a,b=fibaro;b=a.getSourceTrigger;function a:getSourceTrigger()local c=b(a)local d=a:args()if type(d)=='table'and d[1]and type(d[1])=='table'then if d[1].type~= nil then return d[1]end end;return c end end local st=fibaro:getSourceTrigger() if st.type=='time' and st.time then -- do something when we get a time trigger... fibaro:debug(string.format("Triggered:%s, tag:'%s'",st.time,st.tag)) end if st.type=='time' and st.tag=='log' then -- write out log messages from the time scene fibaro:debug("Time log:") fibaro:debug(st.log) end if st.type=='time' and st.tag=='error' then -- write out error messages from the time scene fibaro:debug("Time error:"..st.log) end In the scene we redefine fibaro:getSourceTrigger() to return our timer as an "standard" source trigger. It's not strictly necessary as time triggers are of type 'other' with the arguments coming from fibaro:args(). However, this makes it more streamlined and plays well with standard fibaro source triggers. The timer scene is "drift free" so if you declare a timer on the hour you will be called exactly on the hour, and not slowly start to drift as is very common in many home made Lua timer loops. Standard 'time' triggers look like {type='time', tag=<tag>, time=<str>} tag=<tag> is the (optional) word provided last in the time rule and helps us to identify what time rule triggered our scene. time=<str> is the time the rule is invoked (in HH:MM format) Here we also add the keyword 'log' under "%% time" to instruct the time scene to send us log statements. Log statements come in two versions {type='time', tag='log', log=<msg>} Standard log messages are sent at startup and at midnight with the log msg containing information about the time rules scheduled. It's usually nice to get some feedback that the Timer scene has scheduled our scene and for what times. {type='time', tag='error', log=<msg>} Error messages are always sent (even without the 'log' keyword). Usually due to time rules being faulty. When you enable log messages your scene will also be triggered by log messages and not only timers. You need to tell them apart. A good way to test for a time trigger that is not a log message is to test if there is a .time field in the source trigger if sourceTrigger.type=='time' and sourceTrigger.time then --- do whatever end IN that case we know that it is a proper time trigger and not a log message, as they lack the .time field. Ok, the time rules in the example are 15:00 bar This means that the scene is called 15:00 every day, with the identifier tag "bar" In the scene we get an sourceTrigger at 15:00 of type {type='time', time='15:00', tag='bar'} In the above example we just print out the tag. *00:15 test creates a repeating timer that triggers the scene every 15 minutes, and with the tag "test". We get a sourceTrigger of type {type='time', time='*00:15', tag='test'} The generic version of a time description looks like %% time <time list> <conditions> <tag> : <time list> <conditions> <tag> Examples 15:00,17:00 test creates two timers at 15 and 17 with the same tag "test". sunrise test 'sunrise' is a valid time descriptor and evaluates to todays sunrise hour. 'sunset', "dawn", and "dusk" are available too. sunrise-00:10 test We can do simple arithmetic on times (+/-) to create offsets. 15:00 wednesday test timers at 15 but only on wednesday, tag "test". 15:00 wed test days can be shortened 15:00 wed,fri test or listed. 15:00 wed..fri test or intervals. 15:00 1..7 test interval with first to seventh day of the month 15:00 lastday test Only on the last day of the month 15:00 lastweek test only in the last week of the month (number_of_days_in_month-6..number_of_days_in_month) 15:00 monday lastweek test conditions can be combined. True for Monday of the last week 15:00 monday lastweek may..aug test month conditions also available. *00:15 test interval, every 15min starting immediately (when the script starts). Ex. 12:08:33, 12:23:33, 12:38:33 ... +00:15 test interval, every 15min, starting on next even 15min interval. Ex. 12:15:00, 12:30:00, 12:45:00 ... +00:15 weekends 10:00..15:00 test combined with weekend test (sat..sun) and time interval (10:00 to 15:00) +01:00 sunrise..sunset may..sep water every hour between sunrise and sunset and between May and September call scene with tag 'water' 20:30 2020/05/28,2021/05/27,2022/05/26 earth_hour "long date" format +01:00 oct/28/10:00..dec/30/07:00 tag Long date intervals. Year can be excluded and month can be the name of the month, and time can optionally be added at the end (not sunrise/sunset) The <time list> should be seen as the times we want to schedule and the <conditions> as filters, excluding some times from the <time list> The other way to look at the list of <conditions> is that the spaces are ANDs and commas are ORs. Ex."10:00 thu,sat lasweek tag" is "10:00 ((thu OR sat) AND lastweek), tag" The complete set of conditions are: <time>..<time>, time interval in HH:MM or HH:MM:SS (but also 'sunset' and 'sunrise') <week day>..<week day>, day interval. mon..wed, Thursday..Saturday <day number>..<day number> - 1..7, first to second day in current month <month>..<month>, month interval <time>,<time> -- One or more time specifiers. Ex. 10:00,11:00 <week day>,<week day> -- One or more day specifiers. Ex. monday <day number>,<day number> -- Ex. 1,8,15,22 <month>,<month> -- One or more month specifiers. Ex. june,july,august <long date>..<long date> - YYYY/MM/DD/HH:MM. Year cane be left out and time part is optional <long date>,<long date> - 2020/may/11/10:00, may/11/10:00, may/11 alldays - same as mon..sun weekends - same as sat..sun weekdays - same as mon..sun lastday - true if last day of the month lastweek - true if last week in the month true - always return true. See example below using fibaro global to disable rules false - always return false. Effectively disabling the rule. ...and they can be combined. It's allowed to end a time rule with a comment '--'. It's just removed before parsing the rule. (Wouldn't it be nice to be able to add comments to all headers?) Ex. 15:00 monday test -- Trigger scene every Monday at 3 PM A simple example turning on a lamp (with deviceID 55) at sunset-10min and turning off the lamp at sunrise+10min on weekdays --[[ %% time log sunset-00:10 weekdays turnOn sunrise+00:10 weekdays turnOff --]] print("Scene started") -- Redefine fibaro:getSourceTrigger do local a,b=fibaro;b=a.getSourceTrigger;function a:getSourceTrigger()local c=b(a)local d=a:args()if type(d)=='table'and d[1]and type(d[1])=='table'then if d[1].type~=nil then return d[1]end end;return c end end local st=fibaro:getSourceTrigger() if st.type=='time' and st.tag='turnOn' then fibaro:call(55,"turnOn") end if st.type=='time' and st.tag='turnOff' then fibaro:call(55,"turnOff") end --[[ -- Another solution if st.type=='time' and st.time then fibaro:call(55,st.tag) end --]] The tag is useful to identify what timer you get so you don't have to test against time again (or you can use it as in the example above, as an argument to a function, fibaro:call in the above case). We can also let the tag be the name of a function called in our scene at that time. . --[[ %% properties %% events %% globals %% time log 15:00 bar *00:15 test %% autostart --]] print("Scene started") -- Redefine fibaro:getSourceTrigger do local a,b=fibaro;b=a.getSourceTrigger;function a:getSourceTrigger()local c=b(a)local d=a:args()if type(d)=='table'and d[1]and type(d[1])=='table'then if d[1].type~=nil then return d[1]end end;return c end end local st=fibaro:getSourceTrigger() function bar() print("Bar called") end function test() print("Test called") end if st.type=='time' and st.time then fibaro:debug(string.format("Triggered:%s, tag:'%s'",st.time,st.tag)) if _ENV[st.tag] then _ENV[st.tag]() end end A more advanced feature is that time rules allows for substituting in values from fibaro globals. Ex. <myTime> monday test This will fetch the value from the the fibaro global "myTime" and insert whatever value it has instead of <myTest>. If the value was "10:00" the rule would be 10:00 monday test The substitution can be anywhere in the rule and contain anything so be careful. We also watch if the value of "myTime" changes and if it does it will update the timers for the scene. One way to use this is to have a global, ex "Stop" that is set to "true" or "false". If we include that in a rule 10:00 monday <Stop> test We can easily enable/disable the rule depending on what we set "Stop" to. The scene could be improved and I'm open for suggestions. (and of course there are most likely bugs to be fixed...)
  4. Hello All Ok i have a bathroom fibaro motion sensor where i need to turn on the lights when it is triggered for 15 mins and then they have to be turned off automatically The problem is here, everytime the motion is triggered the timer will start again. And this seems causing a lot of delays in the Fibaro HC2 I have checked we have a parameter calls "blind time" but you can set it to 8 seconds MAX The solution i have in mind to run a scene that when the motion is armed and triggered > turn on light and change sensor to disarm > after 15 mins > change it to arm and turn off lights What do you think?
  5. Witam, mam scenę opartą na interwale co 30 min sprawdzaj czy brama jest zamknięta od godziny 18.30 do 7.44, ale chciałbym by timer interwału miałby się odnowić czyli czas naliczać od ostatnio wykonanej funkcji otworzenia czy przymknięcia, będę wdzięczny za pomoc --[[ %% autostart %% properties %% weather %% events %% globals --]] local sourceTrigger = fibaro:getSourceTrigger(); function tempFunc() local currentDate = os.date("*t"); local startSource = fibaro:getSourceTrigger(); if ( ( (tonumber(os.date("%H%M")) >= tonumber(string.format("%02d%02d", "18", "30")) or tonumber(os.date("%H%M")) <= tonumber(string.format("%02d%02d", "07", "44"))) and (math.floor(os.time()/60)-math.floor(1511285400/60))%60 == 0 ) ) then fibaro:call(136, "close"); end setTimeout(tempFunc, 60*1000) end if (sourceTrigger["type"] == "autostart") then tempFunc() else local currentDate = os.date("*t"); local startSource = fibaro:getSourceTrigger(); if ( startSource["type"] == "other" ) then fibaro:call(136, "close"); end end
  6. Hi all, I am trying to create a scene that checks if my front (Z-Wave) door lock has been unlocked for x minutes - then turn on a light (this is not the end goal, however for simplicity all I would like to do is turn in a light for the moment). The issue... In the LUA code below - all works as expected. Where I am falling down is if the lock is locked within the x minute timer countdown, my LUA code still turns on the light after the time expires - I would like my scene to re-set if the door is locked again. I have been investigating possibly using a variable, however I think I may be over complicating things - is there an easier (simpler) way? --[[ %% properties 386 secured %% weather %% events %% globals --]] local startSource = fibaro:getSourceTrigger(); if(startSource["type"] == "other") then fibaro:call(110, "turnOn"); else if (( tonumber(fibaro:getValue(386, "secured")) == 0 )) then setTimeout(function() local delayedCheck0 = false; local tempDeviceState0, deviceLastModification0 = fibaro:get(386, "value"); if (( tonumber(fibaro:getValue(386, "secured")) == 0 ) and (os.time() - deviceLastModification0) >= 600) then delayedCheck0 = true; end local startSource = fibaro:getSourceTrigger(); if ( ( delayedCheck0 == true ) or startSource["type"] == "other" ) then fibaro:call(110, "turnOn"); end end, 600000) end end Thanks for any assistance offered, it is greatly appreciated.
  7. Hi, hope some of you can help me. I wrote a timer script but it do not really run. Sometimes it runs, sometimes not. Via a virtual module I can set the time in std_heizung and min_heizung. This values are stored as a variable. heizung_aktiv is the variable which turns the scene on or off. But when I start the timer the heater (ID 89) don't turn on. What is my mistake? Has someone an idea? --[[ %% autostart %% properties %% events %% globals --]] local sourceTrigger = fibaro:getSourceTrigger(); while true do if ( tonumber(fibaro:getGlobalValue("heizung_aktiv")) == tonumber("1")) then fibaro:debug('Start der Heizungstimerszene.') local currentDate = os.date("*t"); std_h = tonumber(fibaro:getGlobalValue('std_heizung')) min_h = tonumber(fibaro:getGlobalValue('min_heizung')) if (currentDate.hour == std_h and currentDate.min == min_h) then fibaro:debug("Zeit erreicht, einschalten") fibaro:call(89, "turnOn"); fibaro:debug("30 Minuten warten") fibaro:sleep(30*60000) fibaro:debug("ausschalten") fibaro:call(89, "turnOff"); fibaro:sleep(7000) fibaro:setGlobal("heizung_aktiv", 2); end fibaro:debug("1 Minute warten...") fibaro:sleep(1*60000); -- läuft jede Minute 1 x end end
  8. Version 1.0.0

    307 downloads

    Sankotronic's scene for scheduling time based events (Topic 23510) is a shining example of LUA coding and impeccably documented. It's very powerful and caters for just about every scheduling requirement that you could think of, as well as adding a lot of useful variables that can be used to check whether a scene is running at different periods in the day, week, month, year etc. However, with that power comes a little added complexity, and it's possible that your requirements are much simpler. If you're one of those people and haven't already implemented your own scheduling scene, then that's where this scene may help. SIMPLE TIMER SCENE This scene will simply update global variables, either on a periodic basis, or at selected times of the day. These global variables can then be used to trigger other scenes by adding them to the %% globals section in the header, eg: --[[ %% globals fiveMinuteTimer --]] It will automatically create the global variables, so you don't need to worry about doing this manually. At the beginning of the scene is a table that contains the timers that you want to create, and you should modify this table according to your requirements. For each timer, as well as the timer name, you also specify either: The frequency in seconds that the timer will be triggered, or The set time(s) that the timer will be triggered, in HH:MM format. Two special values for 'sunrise' and 'sunset' can be used to trigger scenes to run at these times. This is the table that you should update: local timers = { timer1 = {name="oneMinuteTimer", frequency=60}, timer2 = {name="fiveMinuteTimer", frequency=300}, timer3 = {name="fifteenMinuteTimer", frequency=900}, timer4 = {name="twelveHourTimer", frequency=43200}, timer5 = {name="garageDoorCheckTimer", setTimes={"20:00", "21:00", "22:00"}}, timer6 = {name="sunriseTimer", setTimes={"sunrise"}}, timer7 = {name="sunsetTimer", setTimes={"sunset"}} } It is recommended that you set on the 'Do not allow alarm to stop scene while alarm is running'. If not, then whenever Fibaro's alarm is triggered, then all your scenes that depend on these timers will stop.
  9. Does anyone have a VD that can have several buttons that kan keep a light (or several) on for a certain time, e.g 3 hours, 4 hours etc. Or a suggestion to a scene (preferable block scene) that can do the same. I experience that with so long delay with timer to shut off a ligh in block scene I get problems with "to many instances"
  10. Hi I want to build a conditional scene as follows: If daypart ="state" (Ex: Evening) and main light at a specific room are on for more than defined time (ex: >=30sec) then turn other lights\devices on appreciate your support Ran
  11. Hi everyone! Could someone please help me with a couple of scenes that are supposed to be triggered in intervals? I have blinds that I want to automatically lower when the sun is shining (temperature and brightness sensed by motion sensor outside, HC2). So I started with interval trigger set to work between 10:30 and 16:59 every 15 minutes (see picture). However, the scene seems to be triggered much more often, sometimes every couple of seconds as I can tell by the switching noise of the blind's actuators (blinds are down, actuator tries to further lower the blinds). If I put a notification at the end of the scene to tell me when it triggers, as expected I get many many messages. Am I missing something? Thank you very much!
  12. Does anyone have a clue, why the following ON scene does work, but the OFF scene does not? I do want to switch on a forced ventilation twice a day for 2h, so I created the scene to switch on if it is either 9 AM or 5 PM. and a scene to switch off if it is either 11 AM or 7 PM Auto-ON works perfect, but Auto-OFF fails every time. I do not understand at all..... what is wrong here? Yes, both scenes are ON Both scenes are tagged as run when HCL runs and in Automatic mode, Allowed instances 2
  13. How to simplfy the following timer? : if (Mode == 'AUTO') then log("Wait 120 minuter"); -- add this by 120 = 120 x 1 minute = 2 hours after one minute can check temp for i=120,1,-1 do -- 1 minute wait for i=60,1,-1 do fibaro:setGlobal("BathroomSetTemp", FloorBathroomTargetTemp); fibaro:sleep(1000); ; end log("Test Time Delay"); end
  14. Hello I just found out - again - an operation that I would call stange. Maybe some of you will find it normal, I don't know.. I have a timer to trigger the pump of my swimming pool. I defined the start at 2:00 am until 23:00 pm with the launch of the scene every 5 hours. In theory, I should expect a trigger at 2:00 am, 7:00 am, 12:00 am, 05:00 pm and 10:00 pm with restarting next day at 2:00 am.. Well not at all, it seems to work the first day but shifts the following days, ie it takes account only the interval and not the start time. The next day, it begins at 10:00 pm + 5, ie 3:00 am then 8:00 am, etc. It does not restart at 2:00 am !!! Personally, I consider this a bug What do you think ? Thank you
  15. I created several scenes where the timer functions to start the scene is being used. But none of them works. Any idea where should be the problem? See the pictures attached. Thanx for any adwise. HC2, FW 4.056,
  16. Hi, I want to make a scene for a solarium where you can choose the time you want to use the solarium. It probally wil be a timer script which countsdown from 15 minutes, i want the scene activated when we turn the solarium on. To turn on and off the solarium we used a 1x3KW switch. Hopefully someone can help me with this.
  17. Dear all, I need your the community support . I'm trying to configure the HCLite to open my roller in the morning only when I'm not in Holidays. I can not use the LUA because I have the HC Lite, I tried creating a variable that indicate when I'm in vacation and when I'm going to work and I test the variable before the timer. This solution in general working well, I have the problem when I change the variable value from holiday to work because if the roller is closed the system open immediately the roller and ignore the timer condition. Someone could you explain me the reason or do you have any idea to solve this problem? Thanks for any suggestion. Luca Scene
×
×
  • Create New...