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


The category contains scenes submitted by users.
Downloading and submission terms have to be accepted.

Types of scenes: magic, block, LUA.
Types of files accepted: PDF, JPG, JPEG, PNG, LUA, TXT.
Scenes have to be described properly, screen shots are optional.
Support topics are created automatically here Scenes

Report topics and files that are no longer supported by authors.
All the files submitted have to be approved by administrators.

40 files

  1. Reduce Ztraffic - fibaro_call

    First of all, this is not scene or script. Just a function to use in scripts to avoid unnecessary Zwave traffic.
    In many cases we send commands to devices without verifying the devices status, this function verifies device current status before sending command and in case the status of the device is not as required, command send.
    This function supports "turnOn" and "turnOff" commands for switches and dimmers.
    How to use?
    Copy this function to your script and change all fibaro:call(...) to fibaro_call(...). Just replace the colon " : " by underscore " _ "
    Function always returns Boolean variable true or false. 
    Two options to use the function:
    fibaro_call ( devID, "trunOn" ) or  fibaro_call ( devID, "turnOff" ) -  verify device status and send "turnOn" if neccessary. fibaro_call ( devID, "?turnOn" ) or  fibaro_call ( devID, "?turnOff" ) - checks device status only. Returns true or false according to status.  No command sent. For example: Original scene which includes few scenarios of sending  turnOff/turnOn .
    --[[ %% properties 823 value 792 value --]] local devID = fibaro:getSourceTrigger()["deviceID"] if devID == 823 then -- no status verification at all fibaro:call(540,"turnOff") end if devID == 792 then -- including verification if tonumber(fibaro:getValue(540,"value"))==0 then fibaro:call(540,"turnOn") end end if tonumber(fibaro:getValue(540,"value"))==1 then -- checkin device status fibaro:setGlobal("test","lightOn") else fibaro:setGlobal("test","lightOff") end Now we add the function
    --[[ %% properties 823 value 792 value --]] function fibaro_call(devId,param) local fStatus,act=true,{["turnOn"]=1,["turnOff"]=0,["?turnOn"]=1,["?turnOff"]=0} if not act[param] then fibaro:debug("fibaro_call.lua:\'<font color=firebrick><font size=2> "..param.." </font></font>\' not supported."); return false end if math.min(1,tonumber(fibaro:getValue(devId,"value"))) ~= act[param] then fStatus=false end if param:find("?") then return fStatus end if not fStatus then fibaro:call(devId,param);fStatus=true end return fStatus end local devID = fibaro:getSourceTrigger()["deviceID"] if devID == 823 then --verification done by fibaro_call() fibaro_call(540,"turnOff") end if devID == 792 then -- no need extra lines for verification fibaro_call(540,"turnOn") end if fibaro_call(540,"?turnOn") then -- checking device status by fibaro_call(). fibaro:setGlobal("test","lightOn") else fibaro:setGlobal("test","lightOff") end That's all.
    Please use this function as a template and change it according to your needs.
    In order to observe how much your Zwave traffic is loaded by repeated commands, please download Zwave monitor version 3.0

    32 downloads

       (0 reviews)

    0 comments

    Updated

  2. Device list and status

    Several times I've got lost in my system to identify specific device.
    I believe many of us have old devices/scenes that have been hidden or disabled. After a while, finding them again is quite a headache and not an easy task.
    I have written a scene that shows all existing devices, scenes, users and mobile devices with some extra data of properties.
     
    The scene output has two formats:
    a list of devices by rooms a plain list of all components in acceding order of IDs  
    In order to choose between two formats please change as following:
    local plainList =false (for list by rooms) local plainList=true (for plain list in acceding order) Since the latest upgrade 4.503 there is a new type of warning "API: not found".
    So during the execution you might see a lot of messages:
    [DEBUG] 00:19:26: Gathering system information.....
    [DEBUG] 00:19:26: [1;31m2018-07-03 00:19:26.358874 [ error] API: Not found
    [DEBUG] 00:19:26: [1;31m2018-07-03 00:19:26.528578 [ error] API: Not found
    [DEBUG] 00:19:26: [1;31m2018-07-03 00:19:26.669187 [ error] API: Not found
    [DEBUG] 00:19:26: [1;31m2018-07-03 00:19:26.826398 [ error] API: Not found
    ....................................................
    Please ignore the messages and wait...
    I hope Fibaro team will fix it on stable release.

    1,129 downloads

       (3 reviews)

    1 comment

    Updated

  3. Print json string in readable format

    This function can come in handy if you want to print a json structure in readable form for debugging or inspection.
     
    It takes a json string as input and returns a HTML formatted string which can be printed in the debug window using fibaro:debug();
     
    Example
    Input:
    "{\"api_data\":{\"status\":\"online\",\"timestamp\":\"2019-01-18-18:01:32\",\"sensor_1\":[\"value_1\":125,\"value_2\":35],\"sensor_2\":[\"value_a\":34.5,\"value_b\":45]}}" Output:
    {   "api_data" : {     "status" : "online",     "timestamp" : "2019-01-18-18:01:32",     "sensor_1" : [       "value_1" : 125,       "value_2" : 35     ],     "sensor_2" : [       "value_a" : 34.5,       "value_b" : 45     ]   } }  

    43 downloads

       (0 reviews)

    0 comments

    Submitted

  4. Scan variables and strings.

    Due to lack of global functions, we're adding more and more global variables. In some  cases after a while we find a way to do it differently, but the global variables are still there. Usually we quite afraid to delete the variable because we're not sure if the variable is not in use somewhere in code.
    So, this code scans scenes and virtual devices and finds where the variable is in use.
    Scenes displayed (blue color) by name and scene ID. Virtual devices displayed (wheat color) by name, button name, device ID and button ID. The program execution has four options:
    1. Scan for all variables and display scenes and virtual devices where every variable is in use. (make sure findVar=nil and findString=nil)
    2. Find where specific variable is in use by defining findVar.
    3. Find where specific string (phrase) is in use by defining findString.
    Some characters, called magic characters, have special meanings when used in a pattern. The magic characters are      
    (     )   .   %   +   -   *   ?   [   ^  $
    The character `%´ works as an escape for those magic characters. So, '%.' matches a dot; '%%' matches the character `%´ itself. You can use the escape `%´  also for all other non-alphanumeric characters. When in doubt, play safe and put an escape. For example if you're searching for string "match(" you should use "match%(".
    4. To find not in use variables only. Press "start" twice within 1 second.
     
    --================= User configurable parameters ============================
    findVar = nil --------- Name of specific variable to search.
    findString = nil ------ Any string to search.
    --============================================================================
    Notes:
    In case findVar and findString are both defined, the code will scan for findString. Make sure when findVar and findString  are not in use to set to nil  
    As usual hope it helps...

    243 downloads

       (0 reviews)

    0 comments

    Updated

  5. CPU & RAM monitor

    The purpose of this scene is to monitor CPU and RAM performances. In case the performance decreased it will notify the user before the system becomes unresponsive  and/or stuck. During introduction of last few releases many users have an issue with CPU overloaded and system stuck, so the idea is to catch and try to solve the problem before the system doesn't respond.
    The program execution has two options:
    1. Stand alone using local json table
    2. Using global variable for json table
    Using second option you can acces to current min, max, average values of CPU and current RAM load from any other sense or virtual device.
    --================= User configurable parameters ============================
    gVarName       = ""                  ---------------------- Global Predefined Variable name.
    eMail                = true                -------------------- send eMail notification to admin only
    pushNote        = true                 -------------------- send push notification to users in push list
    popupNote      = true                -------------------- send popup notification to all mobiles
    sleepTime        = 60                ---------------------- time between samples in seconds.
    batchNum        = 2                 ----------------------- batches/readings number per sample.
    batchDelay      = 10                 ---------------------- time between batches in seconds.
    ramHi               = 75                  ---------------------- RAM high limit.
    highLim1         = 50; highLim2        = 50    ---- CPU 1,2 highest load limit.
    normLim1       = 20; normLim2       = 20    ---- CPU 1,2 normal load limit.
    sample2avg1 = 20; sample2avg2 = 20     ---- CPU 1,2 number of samples to average.
    --============================================================================
    How it works?: (based on default values of user configurable parameters)
    The program checks if any global variable defined, if not local table in use.
    Every 60 seconds (sleepTime) the program will get two readings (batchNum) within   10 seconds (batchDelay) of CPU 1 and 2 load. 
    After 20 samples (sample2avg1/sample2avg2) average load of each CPU and RAM is calculating and in case the CPU load is over 50% (highLim1/highLim2) and/or RAM is higher than 75% (ramHi) notification will be send out by eMail, push notification and popup mobile notification. Please note that popup notification will be received by all mobiles in list of the system. If after overload the CPU average load drops below 20% (normLim1/normLim2) and/or RAM drops below 75%, user will be notified as well.
    Change default values according to your needs, but please pay attention if you reduce the sleepTime and number of samples (sample2avg1/sample2avg2) , the scene could catch momentary peak of load which is not necessarily represents system performances.
     
     

    201 downloads

       (1 review)

    0 comments

    Updated

  6. Simple Timer / Scheduling Scene

    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.

    307 downloads

       (0 reviews)

    1 comment

    Submitted

  7. Netatmo Plugin - Restart Scene

    Due to the netatmo plugin  often stop work without any info the attached scene reboot it. Please add the scene to any another  time based scene (ex for 2 time call by day)
    Explication of scene. After check mail.lua in plugin source:
    if (netatmo:updateProperty('polling_time', config.polling_time) or netatmo:updateProperty('username', config.username) or netatmo:updateProperty('password', config.password) or netatmo:updateProperty('client_id', config.client_id) or netatmo:updateProperty('client_secret', config.client_secret)) then plugin.restart() end to force plugin restart the scene change pooling_time variable. It add to pooling time of netatmo plugin 5s or subtract 5s, alternately and after this check any change in plugin. Result of this is restart of netatmo plugin.
     

    94 downloads

       (1 review)

    2 comments

    Updated

  8. Device inventory scene v. 0.1.6

    Device inventory scene 
     
    Hello everybody,

    this is a simple scene that shows you all the objects in the HC2 and their number, no matter if zwave devices, users, virtual devices and so on.
    See the attached screenshot.
    The script does not need an autostart or other triggers, rather it is meant to be executed ad hoc.

    In any case, it is no longer necessary to count the devices by hand in the future.

    215 downloads

       (0 reviews)

    0 comments

    Updated

  9. List of device grouped by parent

    List of devices grouped by parentId (normally hidden). For check if device is good excluded or find subdevice of same parent device.
    info='short'    -- only device ID
    info='full'        -- device ID with name and list of phone

    65 downloads

       (0 reviews)

    0 comments

    Submitted

  10. Room Thermostat Override

    Overview:
    I have a Secure SRT321 room thermostat in my living room, and up until now the only function that it has performed is as a temperature sensor.  Changing the temperature on the thermostat has had no effect.  I haven't associated it with my boiler switch, as I've implemented a multi-room system.  In theory, I should be able to associate the thermostat with the Danfoss LC-13 radiator valves in that room, but that doesn't seem to work.  However, what I really wanted to do is to override the Heating Panel for that room.  That way, any overrides will also be visible in my Heating Override Virtual Device.
     
    This scene should work with any thermostat device (including the radiator valves), but is primarily designed to work with room thermostats.  When the set point temperature on the thermostat is changed, then the corresponding Heating Panel for the room that the thermostat is located in will also be updated.  If the temperature that is selected is not the same as the current scheduled temperature for that room, then it will put the Heating Panel in manual mode.  If it's the same as the scheduled temperature, then the Heating Panel will revert to scheduled mode.  By having it update the Heating Panel, then the radiator valves in the room will also be updated.
     
    Setup required:
    You will need to change the list of devices ids in the Scene Header, for each of the room thermostats:
    --[[ %% properties 123 targetLevel 234 targetLevel --]] Ensure that you enter the device id for the thermostat and not the associated temperature sensor on the device, if there is one.
     
    You can specify a fixed override duration (the number of minutes that the Heating Panel will be overridden) by changing this variable:
    local overrideDurationMins = 0 -- Set to zero to override until next scheduled change However, if you leave this variable as zero, then it will override the Heating Panel until the time that the panel is next due to change, or for the Minimum Duration.  The Minimum Duration can be specified here:
    local minimumOverrideMins = 60 -- If the duration until the next scheduled change is less than this, then use this value Set the Minimum Duration to zero if you don't want use this feature.
     
    You might need to increase the number of scenes that can run concurrently by changing the Max Running Instances in the scene properties.  Changing the thermostat could trigger several occurrences of this scene.  If there is a limit on the number of scenes that can run, then it's possible that the final setting of the thermostat will be ignored.
     

     
    Code:
    Download it from here: Room Thermostat Override 1.0.lua
     
     

    77 downloads

       (0 reviews)

    0 comments

    Submitted

  11. Consumption Monitoring Scene

    Consumption monitoring™ v3.0.4
     
    CHANGES 2018-02-18 Added support for send push every hour. Added more emoijs to VD 2017-04-04 Corrected day, line 115 2017-04-13 Corrected selfRun function. Added 2 more labels with info. Added emoijs.  
    Monitor your energy consumption and if wanted it will send a daily push and month report with consumed energy
    Supports AEON Labs energy meter (and more...?) Supports Autofrank's Smart Message Hub

     
     
     
    Create an empty vd(virtual device) with 7 labels. ID of the label should be Label1 to Label5. Name you can set what you want. 
    Update - 2017-04-13 - To show the new info in VD then add 2 more labels. Label1 to Label7  Create an empty LUA scene and copy the LUA code into that scene. Change line 22 to your AEON LABS HEM id local energyMeterID = 319 Change line 26 to your vd id that you just created local vdID = 464 Change line 30 to false (local selfRun = true) if you want to run the scene from other scene like @Sankotronic Time Based Events Control Supports @AutoFrank SmartMessageHub, set line 38 to false if you want to use standard push (local SMsgH = true) set id of the SMsgH scene at line 40 local SMsgHid  = 262 Does also support @AutoFrank HomeTable setup if you set  local SMsgH = false remember to fill in id of the smartphones you want to have the push local pushUsersHC2 = {"449"} Separated with comma change line 59 to false if you don't want to have an daily report pushed. local sendPushDaily = true change line 62 to false if you don't want to have an monthly report pushed local sendPushMonthly = true change line 64 to wanted time you want to have the report to be sent local sendPushTime  = "06:30"  
    EXTRA INFO
    Can support more then just AEON HEM but that depends if Fibaro have the power info from the device. You can check that if you run this in your browser http://HC2_IP/api/energy/now-86400/now/single/devices/power/ID_OF_DEVICE. Result should be like the below picture So for example if you just want to have info about the dishwasher, fridge, washing machine etc it should be supported.  
     
     

    Consumption_Dashboard.vfib

    326 downloads

       (0 reviews)

    0 comments

    Updated

  12. Presence Detector

    Want to share my Geolocation and Presence Detector scene i use in my Fibaro setup 
    In wife's and my own smartphone i use both geofency app and wifi presence to check if we are home. A VD runs scheduled and will update a global variable with value "0" or "1" depends if smartphone is active or not.
    Geofency app is the most reliable and correct app i use myself because the smartphones wifi turns into "sleep" mode often to save battery.. You could of course only run Geofency if you want.
     
    Instructions for Geolocation setup
    https://forum.fibaro.com/index.php?/topic/18383-tutorial-geofency-geo-location-based-fibaro-triggering-ioswindows-pc
     
    This scene can be setup and scheduled in Sankotronics "Main scene timebased events"
    https://forum.fibaro.com/index.php?/topic/23510-scene-main-scene-for-time-based-events-control-v-124/
     
    Settings that can be changed by user:
    -- USER SETTINGS --------------------------------------------------------- -- "PresentState" is predefined global value that determines if you are at home -- away or on holidays. This variable value is set by other scene or VD. -- Enter name of your global variable between "" or leave as it is local presentState = "PresentState"; local presentStateMapping = {Home="Hemma", Away="Borta", Holiday="Holiday"}; -- GuestState is predefined global variable with possible values: "Yes", "No". local guestState = "GuestState"; local guestStateMapping = {Yes="Yes", No="No"}; -- Geo is predefined global variable with possible values: "1", "0" -- and name of users. This variable value is set by other scene or VD. -- variable example setup: --> "Geo_Jonny_Home" local geoState = "Geo_"; local geoUserMapping = {User1="Jonny", User2="Mona"}; local usegeoState = true; -- Smartphone is predefined global variable with possible values: "1", "0" -- and name of users. This variable value is set by other scene or VD. -- variable example setup: --> "Phone_JL_Present" local wifiState = "Phone_"; local wifiUserMapping = {User1="JL", User2="ML",User3="SL", User4="SW",User5="MW", User6="DD"}; local useWifiState = true; -- Telegram settings local varTelegram = "Telegram"; local useTelegram = true;  

     
     

    170 downloads

       (0 reviews)

    0 comments

    Submitted

  13. WakeUpAndPolling

    Support topic for this scene:
     
     
     
    Script to summarize "Wake up interval" and "Polling time interval" off all physical (master) devices.
    Version 1.2, 2016-06-23.
        * Improved detection: FLiRS & non-Zwave devices.
        * Isolate "display" logic into table "printing", so
          the detection logic (code) becomes clearer.
        * Replace "*" with "-" because, well, I like that
        * Handle more exceptional cases (missing data).
        * Handle html special characters (ampersand, comparison).
        * Implement tests (on my laptop only...). Version 1.1. 2015-06-27 Fix for: LUA error: /opt/fibaro/scenes/390.lua:70:attempt to perform arithmetic on local 'timeSec' (a nil value). Version 1.0. 2015-06-14. Initial version. Tested on HC2 V4.049. Description of the report
     
    This is a example. The ID is clickable when you run the script. It takes you to the settings of the device in a new tab or window.
     ID   T(s) T(h:m:s)  Type Info  299     -        -    X  333 7200 02:00:00 W  382     *        *   G  383   125 00:02:05   P  804   600 00:10:00 W For battery devices the script will say:
     
    W = Wakeup Interval (device is battery powered). or
    F = FLiRS (frequently listening routing slave).  FLiRS are battery operated that can respond in 1 second to commands (unlike normal battery powered devices). Typically found on door locks. Battery is checked every 24h (non-configurable).
     
    Polling comes in three flavors. The sentences used here are the same as in the HC2 device GUI. They are shown on the "Advanced" page of a device). The possibilities are:
     
    G = Device uses global polling queue. P = Device will be polled at periodic intervals. X = Device excluded from polling. Global polling uses the settings of polling on the "Configuration, Z-Wave Network" tab.
     
    So in the example: device 299 e'X'cluded from polling, 330 'W'akes every 2h, 382 has 'G'lobal polling, 383 has 'P'eriodic ('P'er device) polling set at 125 s.
     
    * Background *
     
    Wake up interval
     
    This setting applies to battery devices. This is the time between wake up and "wake up" means the device exits "deep sleep" and sends a specific signal to controller. That WAKEUP-NOTIFICATION tells the controller that it is ready to exchange configuration information. The device stays awake for some time (timing is device dependent) to exchange data. Wake up is not to be confused with polling. Also, I'd like to note that a wake up can be forced through some specific button press sequence, but not by "using" a device. For example, breaching a motion sensor, or opening a door with a door sensor does not wake up the device. Such an event merely makes the device send a status change to the controller. After that, it immediately goes to sleep. This is necessary to minimize power consumption. When does this all matter? Suppose you have changed a device parameter. That request will be queued until the device wakes up. Suppose it's a Smoke Sensor, high up there against the wall and you can't push the button. In that case, you'll have to wait until the next "wake up interval" passes. And if you own a radiator thermostat? That kind of device will pick up the set point from the controller at wake up. And for a key fob: you probably wouldn't want it to wake up at all, because there's no interesting data to exchange.
     
    Polling interval
     
    This is the time between "polls" and a poll is the controller asking for the device to send information. Only mains powered devices have their radio switched on at all times, so they can respond to this request whenever the controller asks. But what with a battery device? If the controller ask something while the device sleeps (and that's almost always), it can't receive the poll. I don't know how Fibaro implemented it, but there are 2 possibilities: either the poll is queued or it is discarded. There is a hint how it's done: have you looked at the interface lately? Then you have noticed that a battery device does not have the "polling" settings. In my own opinion, polling indeed doesn't apply to battery powered devices.
     
    What should we do with polling? Is polling necessary? First of all, I remember cases of users that where unhappy without polling, as it was disabled in the earlier 4.X versions. I once owned a device myself, that did not report status to the controller: a simple switch. No polling means: the controller doesn't know the state of the switch when operated locally. But if you have a look at the technical documentation of your device, you're likely to find a "reporting group". And if it's Z-Wave plus, having such a group is part of the standard. That means the device sends data to the controller, when something interesting happens.
     
    What's the issue with polling? Polling causes network traffic. And that may introduce delays from and to your devices. It depends on network size, network design, code and device types. I have 37 mains powered devices (43 battery), and I can tell the difference between polling on and off. The polling traffic is very likely unnecessary traffic. I would disable polling. If HC2 is wrong about the status of a device, verify if "1" is in the reporting group (see device manual). To my knowledge, none of the Fibaro devices need polling.
     
    One more thing. The "polling" and "wake up" interval can be put on the same report, in the same column, because they cannot occur together. If it's a battery powered device, it can't be polled because the device switches off its radio when it's sleeping. And when it's a mains powered device, its radio is always on, so "wake up" doesn't apply.
     
    * FLiRS *
     
    FLiRS are battery operated, but still can receive commands. Because they are "Frequently Listening Routing Slaves" meaning they briefly wake up once per second to check if the controller sends a special command. The Fibaro Heat Controller FGT-001 is such a device. You can also build your own FLiRS based on a Z-Uno. Technically they can be polled, but I think the HC interface does not allow you to do so (not on FW 4.150 anyway). FLiRS "do not wake up as a normal battery device" so there is no such configuration parameter.

    * About the code *
     
    Special thanks to forum users krikroff an A. Socha (Fibaro) for pointing me in the right direction for the API. Bits and pieces were gathered on this forum. Some parts were discovered by trial and error (by me). And an invaluable source of information is the book "Z-Wave Basics" by Dr. Christian Paetz.
     
    One small warning: parts of the code uses features that are not (yet) documented. They were discovered by reverse engineering. I may be wrong. Or the code may break if Fibaro changes things in future firmware releases. Maybe the script barks at you. Please let me know if it does so, I'll try to learn from it. I last checked the code on my system, running FW 4.153 jan 2018 and it was still fine.
     
    The code is available as an attachment to this post.
     
    Please let me know what you think of it!
     
    Thanks for reading this long post. And as always: have fun with Home Automation!

    379 downloads

       (1 review)

    0 comments

    Updated

  14. ALL-IN-ONE Message Scene

    --[[ ----------------------------------------------------------------------------- -- ALLINONE MESSAGE SCENE -- TELEGRAM/PUSH/POPUP/API.POST ----------------------------------------------------------------------------- ----------------------------------------------------------------------------- 0.0.9 Started with Telegram and push function 1.0.0 Added popup and api.post functions 1.0.1 Added support for TTS to your MUSAIC player. You need to set right language for you TTS string. 1.0.2 TelegramMessage function does now support if you resend same message many times another scene. 1.0.3 Added support for Sonos remote VD -- SCENE DESCRIPTION -------------------------------------------------------- This scene will send message to your smartphone, which function that will run depends on what string you send and to which variable. Example: -- TELEGRAM ----------------------------------------------------------------- Drop your message to TelegramMessage variable and this scene will send it to you Demands a telegram token and chatid -- fibaro:setGlobal("TelegramMessage", "YOUR MESSAGE") -- -- PUSHSMARTPHONE ----------------------------------------------------------- Drop your message to SmartPhoneMessage variable and this scene will send it to your smarthphone as push -- fibaro:setGlobal("SmartPhoneMessage", "YOUR MESSAGE") -- -- SENDPOPUP ---------------------------------------------------------------- Will send an popup message to fibaro app in your smartphone -- fibaro:setGlobal("popUpMessage", "Info:Test:From fibaro HC2:Test of string") -- String translate : (typeInfo, windowTitle, header, contentInfo) typeInfo = available types: ('Info', 'Success','Warning','Critical') windowTitle = pop-up window title header = pop-up content title contentInfo = pop-up content text -- API.POST ----------------------------------------------------------------- If you want to send an api.post message to your smartphone with the possibillity to start a scene you send this example string to apiPostMessage variable. -- fibaro:setGlobal("apiPostMessage","Activate alarm?:Nobody at home:RUN_CANCEL:283") -- String translate: (message, title, category, data) message = the message title = the title category = the value for what to do, can be RUN_CANCEL or YES_NO data = sceneID to run -- SONOS TTS ---------------------------------------------------------------- Drop your message to sonosTTS variable and this scene will send it to your Sonos player as TTS -- fibaro:setGlobal("sonosTTS", "YOUR MESSAGE") -- --]]

    170 downloads

       (1 review)

    0 comments

    Updated

  15. Scene timer

    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.

    185 downloads

       (5 reviews)

    0 comments

    Updated


×
×
  • Create New...