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.

42 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

    44 downloads

       (0 reviews)

    0 comments

    Updated

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

    90 downloads

       (0 reviews)

    0 comments

    Submitted

  3. Routing Info

    Routing Information
    This scene reads the routing information of the ZWave devices from the API of the HC3 or HC2 .
    What information is that?
     the neighbors of each device  the last used working route of the device  the number of hops for the device  the working route respose time (WRRT)  
    In addition, the following is checked:
     whether a device has no routes  or whether a device has no neighbors at all  
    In the summary, all devices are listed according to the number of hops.
    For routes with 4 or 3 hops, the mesh network should possibly be rebuilt
    for these devices.
     
    The scene is available in 2 different versions for HC2 and HC3.

    264 downloads

       (0 reviews)

    1 comment

    Submitted

  4. Różne sceny

    Różne sceny dla grupy urządzeń. 

    356 downloads

       (0 reviews)

    0 comments

    Submitted

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

    273 downloads

       (0 reviews)

    0 comments

    Updated

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

    241 downloads

       (5 reviews)

    0 comments

    Updated

  7. Sceny do Urządzeń

    Kilka scen dedykowanych do określonych grup urządzeń. 

    135 downloads

       (0 reviews)

    0 comments

    Submitted

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

    337 downloads

       (0 reviews)

    1 comment

    Submitted

  9. Smart Fade out for Sonos VD

    Smart fade out for Sonos
    First release on french board in April 2019
     
    INTRODUCTION
    This scene allow your HC2 to smoothly shut down your Sonos speakers. You can copy this scene with differents VD IDs as much as you want.
    I personnaly use it for each room in my home, and one global with all IDs.
    For example, I often use the scene in my bedroom to have a sleep mode, without beeing awaken by a hard shutdown of the speakers in the room.
     
    WHAT DOES THIS SCENE?
    Look into the IDs and retrieve the volume and the room affected to the VD Look for the masters speakers (Those which can manage others speakers) Fadeout step by step every speakers Press the Pause button on masters speakers Put the volume at an audible level for next playing  
    WHAT'S A MASTER SPEAKER?
    When you use Sonos Controller, you can create a group of speakers by adding speakers to the actual. All the speakers may play the same program simutaneously.
    The speaker that you first selected is the master. It's transparent in the Sonos Controller App, but to manage Play/Pause/Programs Buttons on your HC2 server, you have to manage it on the master speaker. Actions won't be taken into account on VD of slaves speakers.
     
    SCENE SETTINGS
    -- VD List local VD = {242,243,244}; -- Duration between to steps in the fadeout local StepDuration = 3 -- Speakers Volume will be set at the following volume after the fadeout local Volume = 15 If you have modified the original VD, it's possible to update the ids for Volume Slider and Pause Button here :
    -- Slider Volume ID local SliderVol = "15" -- Pause Button ID local BtnPause = "8" SCENE ICON

     
    REQUIREMENTS
    Your HC2 Server have to run on version 4.xxx Using VD Sonos Remote by Krikroff

    45 downloads

       (0 reviews)

    0 comments

    Updated

  10. SVG_XSS.svg

    SVG_XSS.svg

    11 downloads

       (0 reviews)

    0 comments

    Submitted

  11. Text to Speech - Android phone/tablet

    First of all the entire credit goes to @davanha who has written this text to speech (and alarm control)  APK for android and continues to maintain the code.  Outstanding job.
    Now, to my opinion, everyone should use this very simple and straight forward implementation. This is a great opportunity to give a voice to your home. I'm using TTS for years (UBI and EMIC solutions), but to have it on my phone at any place at home !!! sounds much better. Of course if you have tablet which runs Fibaro application and now you can make it speak... great feature for all your family, finally they can hear what you're doing. In my case the smart home is part of the family.
    I know that many users use other solutions like SONOS, Google, but not one of them has this nice and convenience way to speak directly to you or any other member of your family at any place at home.
    Please follow next installation steps:
    1. Create TTS scene and copy the code (TTS scene v1.0-lua.txt) on your HC2.
    2. Download zenitgatekeeper_0.1.651.txt to your phone or tablet. Change file extension to .apk and install the application.
    3. Go to setting (initial password 1234) Application settings -> [check  'Autostart application after reboot' box] -> Http services [check all boxes on this page]  see fifth screenshot-> go back till you see "Text-To-Speech mode" window (as displayed on third screenshot)
    4. Usually we're cleaning our phones by killing background applications, so please lock this application on your phone.
    5. To verify proper installation run on web browser follow line http://<ipadress of android device>:8080/tts=testing Your android device should now play the speech
    6. You can add to play intro announcement before the message.. like "ding dong" or any other. To do so please click "Settings" button (default password to settings menu is "1234")  -> Application Settings -> Http services ->  Play speech on device.
    7. New releases of the app are available at https://github.com/davandev/AlarmController/releases
    8. Now if the setup is OK... open any code on your HC2 and execute
    fibaro:startScene('ttsSceneID',{"testing my text to speech setup","<IP address of android device:8080"}) fibaro:startScene('ttsSceneID',{"testing my text to speech setup","<IP address of android device>:8080",<volume level>})            Usual volume level range is 1-15.  Please notice that the volume level of your phone or tablet will be changed accordingly.
    9. Another great feature of zenitgatekeeper application, it can receive "wakeup" command and it will turn on the  android device screen. I've found this very useful for my tablet in living room. Till now the display was constantly on, now since I have motion sensor in the room, I'm able to turn on the display only if someone in the room. It extends my tablet display life cycle. To use wakeup just start TTS scene as shown below:
    fibaro:startScene('ttsSceneID',{"wakeup","<IP address of android device:8080"}) For more information please visit this topic:  https://forum.fibaro.com/topic/25004-using-an-android-device-as-a-text-to-speech-engine/
     
    Notes:
    This solution works on your local LAN- home network  only. When your device is out of range, no message will be received. But when you back to your area the device connects automatically and starts to "speak". My suggestion is to assign fixed IP address to your device on your home network. Otherwise the IP address could be changed and you'll need to change it in the code. You will hear the messages even if your phone is on mute. To stop to hear the messages you need to reduce the volume or to kill the application.  
    Some ideas of messages could be seen on first screenshot. In addition you can install the apk application on other members of the family and you can redirect relevant messages of smart home directly to them only.
     

    452 downloads

       (1 review)

    10 comments

    Updated

  12. TRV Boost

    Purpose: Fully open the radiator valves in order to heat up the rooms more quickly.
     
    Notes:
    One of the problems that I have with my Danfoss radiator valves is that they do not seem to fully open when required.  For example, I have a radiator in a very cold room, which, let's say the room temperature is 10°C and I've set the TRV to 15°C, then the valve barely opens and as a result, the room doesn't reach the target temperature.  It's almost as though the TRV isn't taking into account the current room temperature when determining how far to open the valve.  There only seems to be a direct correlation between the target temperature and the valve opening.  So for example, when the target temperature is 15°C then the valve is only open slightly, at 21°C then it's open half-way, and at 28°C it's fully open.
     
    I want my rooms to heat up as quickly as possible when they need heat so I created this scene to monitor the room temperatures and control the valve opening as appropriate in order to fully open the valves when needed.  When the room temperature is below a certain threshold lower than the heating panel zone temperature, then the valve target temperatures are boosted to 28°C in order to fully open them.  Once the room temperatures are close to reaching the required zone temperature, then the valve temperatures are returned to normal.
     
    Setup required:
    Boost Temperature Set this to the temperature which causes the valves to fully open.
    local boostTemp = 28
     
    Boost Duration The maximum number of minutes that the valve target temperature will be boosted for.  This should not need changing.  Once the room has reached the desired temperature then the boost will be turned off.  If the room has not reach the desired temperature within this duration, then the boost will be turned on again.
    local boostDuration = 120
     
    Turn on Threshold The temperature below the target room temperature defined in the Heating Panel Zone which will cause the TRV to go into boost mode.
    local turnOnTrigger = 0.7
     
    Turn off Threshold The temperature below the target room temperature which will cause the TRV to return to normal mode.  We want to try to prevent overshoot as much as possible, so the boost mode is turned off before the desired room temperature has been reached.  If your rooms heat up quickly, then you might want to increase this value.
    local turnOffTrigger = 0.3
     
    Valve device types The list of device types that are used to identify the TRV valves.
    local valveTypes = {"com.fibaro.thermostatDanfoss", "com.fibaro.setPoint", "com.fibaro.FGT001"}
     
    The device types can be found via the Fibaro API, eg: http://<Fibaro IP Address>/api/devices/123 where 123 is the device ID, or via the API documentation portal at http://<Fibaro IP Address>/docs/#!/devices/getDevice.  The device type can be found in the response message:
    { "id": 123, "name": "Radiator Valve 1", "roomID": 4, "type": "com.fibaro.thermostatDanfoss", "baseType": "com.fibaro.hvac", "enabled": true, "visible": true, "isPlugin": false, "parentId": 129, "remoteGatewayId": 0, "interfaces": [ If you are not able to use the device types in order to identify your valves, then you can define a list:
    local valveIDs = {123,234,345,876} And then remove the following code which builds the list of device IDs:
    -- Get the list of TRV Ids using the list of types -- If non-TRV devices are returned then more filtering may be required -- or a hardcoded list of ids can be used. local valveIDs = {} for i, valveType in pairs(valveTypes) do local valveIDs1 = fibaro:getDevicesId({type = valveType, enabled=true, visible=true}) --print(valveType .. " " .. json.encode(valveIDs1)) valveIDs = array_concat({valveIDs, valveIDs1}) end  
    This scene needs to be triggered to run every few minutes using a timer scene.  If you do not have one, then take a look at this scene or search for one in the downloads area of the forum:
     

    69 downloads

       (0 reviews)

    0 comments

    Submitted

  13. Universal Alarm Scene

    Universal alarm v1.0
     

     
    Hello everyone!
     
    Here is one simple scene that can be used for FIRE, FLOOD or OTHER ALARM purpose. When triggered by sensor it will send you popup, push and e-mail notification. It can also activate additional alarm sounders. You can also add additional actions to turn On lights, lower blinds or whatever action you like to happen when alarm is breached and also when sensor get back to safe state.
     
    There is no global variables needed! If you use HomeTable then you can just uncomment line where this table is read to the scene.
     
    SCENE SETUP
    First you need to decide for what you will use this scene. You can use it for FIRE ALARM or for FLOOD ALARM or for any other purpose that you can think off. Just for setup example I will show here how to set it up for FIRE alarm. Same setup can be done for FLOOD alarm.
     
    First you need to add all your smoke detectors to scene header so that it is triggered when any of this sensors detects fire and get breached:
    --[[ %% properties 96 value 128 value 605 value %% globals --]] Then you can setup devices to which you want this scene to send push notifications. As already mentioned in my other threads, to find ID of your mobile devices you can enter this link in your browser:
     
    http://<YOUR_HC_IP>/docs/#!/iosDevices/getIosDevices
     
    and then press on button TRY IT! You will get ID numbers of all mobile devices that you can enter here:
    -- PUSH MESSAGES AND MOBILE DEVICE SETUP --------------------------------- -- define mobile devices to send push messages. Enter devices inside -- braces separated by comma local iosDeviceID = {206, 321};  
    Then you can setup messages text, translate it to your language:
    -- PUSH MESSAGES SETUP ------------------------------------------------------ -- enter push message text for breached alarm notification local pushMessage = "WARNING! FIRE/FLOOD/OTHER ALARM BREACHED!"; -- POPUP MESSAGES SETUP ----------------------------------------------------- -- enter popup message text and button caption for breached alarm local popupMainTitle = "FIRE/FLOOD/OTHER ALARM"; local popupTimeFormat = "%H:%M:%S | %d.%m.%Y."; local popupContentTitle = "ALARM breached!"; local popupImgUrl = ""; local popupButtonCaption = "OK"; Here you can setup users that will receive e-mail message. Same as for mobile devices, you can find users ID by entering following link in your browser:
     
    http://<YOUR_PC_IP/docs/#!/users/getUserss
     
    and then press button TRY IT!. You will get ID numbers of all users that you can enter here:
    -- E-MAIL MESSAGE SETUP ----------------------------------------------------- -- define users for which you want to receive e-mail warning. Enter users -- inside braces separated by comma local userID = {}; -- Translate this e-mail message text that will be sent to you. On this -- part scene will add which sensor was breached. local emailMessage = "Breached FIRE/FLLOD/OTHER sensor:" In above settings you can also setup first part of the e-mail message. Scene will on that part add room and name of the sensor that is breached!
     
    If you want to activate additional sounders because fire and flood sensor sounder is not enough then you can setup here additional sounders to be activated when alarm is activated:
    -- EXTRA SOUNDER SETUP ------------------------------------------------------ -- define alarm sounder ID inside braces. You can define more than one just -- separate them with comma. local sounderID = {128, 210}; And for the end, if this is not enough for you and you want more action to be executed when alarm is breached, like close water valves, close blinds or turn on some lighting then you can add that code yourself. There are three functions where you can add code:
    -- EXTRA FUNCTIONS WHERE YOU CAN ADD YOUR CODE ---------------------------- -- use this function to add code that will be executed before all other -- code when sensor is breached function extraUserCodeBreachFirst() -- your code goes here end -- use this function to add code that will be executed after all other -- code when sensor is breached function extraUserCodeBreachLast() -- your code goes here end -- use this function to add code that will be executed when sensor is -- back to safe state function extraUserCodeSafe() -- your code goes here end If you want some action before notifications are send and sounders activated then you add code to function extraUserCodeBreachFirst(). If you want some action to be executed after notifications are sent and sounders activated then you add code to function extraUserCodeBreachLast(). When sensor goes back to safe state scene is activated again. It will not send any messages but will stop sounders and if you want some more action then you can add code to function extraUserCodeSafe().
     
    So, one copy of this scene you can setup for FIRE ALARM. Another copy you can setup for FLOOD ALARM, and if you have something else then you can setup third copy for that OTHER ALARM.
     
    Also please check this video by Mr Apple @MarcoTorino71:
     
     
    NOTE!
    This scene is tested on my HC2 with software 4.110 up to 4.510 by breaching FIRE & FLOOD sensors and found to work flawlessly. If you encounter any problems then please first check your settings and look for typos. If you are still unable to make it work then please send me copy of complete scene code and screenshot of debugging window to my private message and I will help you to make it work!

    1,033 downloads

       (2 reviews)

    3 comments

    Updated

  14. Very Smart Lights scene

    Very Smart Lights™ v1.4.3
     
     
    Hello everyone!
     
    I am so excited! Very Smart Lights™ scene just get smarter!!! Thanks to all of you for valuable feedback and requests! We are listening and acting! So here it is, completely rewritten, smarter, better scene to control your home lighting!  
     
    NEW UPDATE v1.4.3 (09 Apr 2019)
    This update brings support for Philips HUE AIO VD v3.0 standalone! I have updated instructions for setting up HUE AIO VD in scene code and also I have optimized a bit code. This scene can still work with HUE VD old versions but I humbly recommend upgrading HUE VD to the latest version.
     
    UPDATE HISTORY
    1.4.2 (11 Jan 18)
    Two updates in one day! In v1.4.2 corrected code for HUE plugin lights. Problem was that scene was turning on HUE plugin lights at brightness 1 even brightness was set to 0 to keep them Off. Thanks to @shingoo for pointing out this bug!
    1.4.1 (11 Jan18) - Corrected bug that was causing scene to stop working if RGBW lights are controlled and useIndoorLights and indoorLightsDim where set to Yes. Many thanks to @AndrewB82 for reporting this bug!
    1.4.0 (20. Jan 17) -
    What is new: 
    Darkness is not used anymore for turning On lights and dim low levels. Only TimeOfDay is now used for that purpose. Added support for different types of Philips HUE light VD. Scene now supports HUE color ambience, HUE white ambience and HUE white dimmable only bulbs and VDs. Also added support for customized HUE VD. Support for HUE plugin remain same. It is now possible to mix different types of HUE VD since now you have to define VD type for each HUE light. Ambient color settings can now be stored also for White ambience bulbs. Also added default color setting for this bulbs!
    Added two new global variables for Cooking and for Mealtime that can be used  to define different brightness levels and to keep lights On as long as this variables are set to Yes if added to extraGlobalName.
    Corrected dimming of RGBW lights when useRGBWcolor is set to Yes. Also RGBW lights will now turn on when dim low is set on defined settings.
    Corrected duration timer compensation with PIRwindowTime. Now is properly calculated and warning displayed if duration setting is lower than PIRwindowTime. Now lights will always turn on for the duration of motion sensor breach time.
    Corrected scene behavior when PresentState and SleepState are changed. When PresentState is changed to Home or Holiday scene will turn on lights when motion is detected or dim low if set for that part of day. Same is when SleepState change from Sleep to Awake. When PresentState is set to Holiday scene can be controlled by global variable triggers
    Global variable SleepState added to scene header global triggers so now scene will turn Off or dim low lights when SleepState is set to Sleep or turn on or dim low lights when set to Awake! It is not needed any more to manually run VLS scene to do that!
    Completely rewritten code for turning On/Off lights and added error handling so now you will know if there is some mistake in settings for quick correction. If you don't use special condition for HolidayLights then you don't need to setup flags anymore. If any of special conditions is not used like IndoorLightsDim and use is set to No then you don't even need to add this global variable to variable panel!
    Added debugging for lights handling so if there is any problems you can turn lightdebug to true and see how each light is controlled and what brightness setting is used for each defined light.
    Refined other debugging messages and added more colors for easier reading and fault finding.
     
    1.3.5 (09. Jan 17) - Corrected that scene turn off switch lights if user set valSWT to 0. Corrected that scene turn off RGBW lights if program is running or color is enabled if dimRGB is set to 0. Added ProjectorState global variable that can be used to additionally setup lighting for movie time with projector. So now you can have two different setup to watch movies! Don't forget to put CinemaState and ProjectorState to extraGlobalName to keep lights at predefined values!
     
    1.3.4 (09. Jan 17) - resolved bug for keepDimSleep setting that logic was reversed. Now if set to true will keep lights dimmed and false will turn them off when SleepState is set to sleep. Rectified situation when scene not turning lights on at all if not using light sensors. Corrected dimOff logic to properly dim or turn off lights depending on settings. Cleaned code of some other bugs found during testing. Also removed ™ and © symbols from code because some users reported trouble with these on Windows 10.
     
    1.3.3 (06. Jan 17) - resolved bug that was preventing extra timer using jompa68 Alarm clock from proper functioning. Extended dimOff function so now lights can be dimmed low during all day and also all night regardless of SleepState depending on your settings. Corrected scene behavior when sleepingName and PresentState global variables value changes and added debugging messages.
     
    1.3.2 (30. Dec 16) - Added support for latest version of jompa68 Alarm clock 3.0.0. Added possibility to define two different dimming levels for Evening and Night time if there is no movement in room and lights are set to dim instead switch off. Corrected bug for turning on RGBW lights if program and color set to No. Added some basic checking of user settings if HolidayLights flag, Brightness and dimOff values are missing. Corrected how scene handles ambilight settings. dim and off ambilight changed to one setting dimOffAmbilight and it must be set to Yes to use settings. keepAmbilight is just setting if you want to keep color when motion detected or use defalut colors. Even if you do not keep colors while in room they will still revert to color when no movement detected.
     
    1.3.1 (25. Dec 16)- Corrected usage of dimAmbilight and offAmbilight so that only color and saturation is remembered while brightness is set by scene setting corrected Alarm clock timer to check if it is turned Off to not keep lights on.
     
    1.3  (First public release) - Added ambilight selection so that scene remembers previous status of the HUE lamps to dim back when no motion in the room, or even leave settings after turning them off. It is also possible to select if HUE lamps will raise brightness in ambilight colors or to default settings when there is motion in the room. Now every lamp can be set to different light level for every used situation like (hoilday lights, guests, cinema, etc.) and for every part of the day.
     
    SCENE DESCRIPTION
    You need one copy of this scene for each room or space. One room can have two scenes if needed to control two different groups of lights, but one scene is not supposed to control lighting in more than one room! Here is short description (new 09. Jan 17, thanks to @clowg): 
     
    How it works:
    This scene uses Darkness and TimeOfDay global variables to change brightness of the lights when there is motion in the room and same times to dim lights when there is no motion if that option is turned on. TimeOfDay can have four different values Morning, Day, Evening and Night. Darkness can have two values Light and Dark. They both change values according to sunrise and sunset times and are very important for proper functioning of VSL scene. I recommend installing Main scene for time based events control with Sunrise & Sunset virtual device to ensure proper handling of this two important global variables. More info about Main scene you can find on provided link.
    You do not need to change the LightStatus, nor times when Morning, Day, Evening and Night starts.  Once these values are set, the Main scene will move those times according to the sunrise and sunset times.  Day duration is changing throughout the whole year and the Main scene and Sunrise & Sunset VD will make sure that everything else is following these times!
     
    SCENE SPECIFICATION 
    SCENE IS CONTROLLED BY ANY NUMBER OF MOTION, LIGHT AND DOOR/WINDOW SENSORS AND GLOBAL VARIABLES
    - With this scene lights can be controlled by any number of motion sensors, light sensors, door/window sensors and global variables that can be mirror of the motion sensors from other alarm systems or used to mimic lights while you enjoy your vacation.
    - Light level (lux) is calculated if used more than one light sensor.
    - If lights are turned On but lux level reaches turning Off threshold then lights will turn off no matter what other condition keeps them on (motion, extra devices or globals, extra timers).
     
    LIGHT DEVICES THAT CAN BE CONTROLLED
    Tested and can control any number and any combination of this types of light control devices:
        1) Philips HUE virtual device  - pls check --> Philips HUE Color & White ambience VD
        2) Philips HUE plugin
        3) FIBARO Dimmer 2
        4) FIBARO single/double switch
        5) FIBARO RGBW module including programs, color RGB/RGBW and white only
        6) FIBARO smart plug
    Not tested but can possibly control devices from other manufacturers. (need your feedback!)
    For FIBARO RGBW module you can define seven different programs for each day of the week and time of day when you want program to be run.
     
    LIGHT BRIGHTNESS AND DURATION CONTROL
    Light brightness for each individual light can be set and duration (ONLY ONE FOR ALL LIGHTS!) can be defined by these conditions:
        1) Guests time
        2) Cooking time
        3) Mealtime
        4) Projector movie time (NEW v1.3.5)
        5) Cinema time   
        6) Holiday time
        7) Indoor lights time
        ? Sleep/Awake
        9) Time of day
    All this states can be fully configured or just switched off and use only Time of day condition.
     
    EXTRA DEVICE AND/OR GLOBAL VARIABLE CONDITION CHECK
    Extra device value or/and power consumption and global variable check gives you ability to disable switching off lights for as long as status of device and/or global variable meets defined value. For example:
        1) If working table smart plug consumption is greater than 10W then keep lights on
        2) if bathroom door is closed then keep lights on
        4) if TV is on can be checked by global variable status or smart plug then keep lights in living room on and dimmed.
        5) if outside is day but overcast and/or raining then set global variable and keep lights in kitchen always on
     
    EXTRA TIMERS
    User can define extra timer that will keep lights on for predefined time. For example you can keep light on for defined time eg. 1 hour after alarm clock wakes you up. Control is done by using alarm clock global variable setting.
     
    TIMER TO TURN ON ANY DEVICE/SCENE/CHANGE VALUE TO GLOBAL VARIABLE AFTER PREDEFINED TIME
    Scene has timer that can start up any number of devices and/or scenes and/or change global variables value if it is running longer than predefined time. For example if you stay longer in bathroom so scene is running longer than 5 minutes then it can start up extraction fan and also start scene that will stop fan after predefined time and also after 10 minutes in bathroom change global variable value which will in return send push notification to your loved one that you are currently really busy  

    INSTALLATION GUIDE
    Please check this video made by @MarcoTorino71:
     
     
    Since I did a lot of comments and instructions in scene itself what and how to setup I will just use some examples here to give some more information. But first of all there are some global variables that must be added to global variable panel before scene can run correctly so here they are:
     
    GLOBAL VARIABLES DEFINITION
    All following global variables are predefined global variables to be added in lower part of variable panel! Possible values can be set in your language and then mapped to values in english used in scene code!
    1) TimeOfDay -  possible values "Morning", "Day", "Evening", "Night". This global variable value is controlled by Main scene for time based events control. TimeOfDay condition will be override by all conditions bellow. If useTimeOfDay is set to "No" then you need to setup Awake brightness settings.
     
    2) PresentState - possible values "Home", "Away", "Holiday". This global variable value is controlled on my HC2 with scenes that are run when we leave or come back home. Those scenes are actually responsible for more actions than just change value of this global variable but about them some other time. You need to take care to change value of this global variable.
     
    3) LightState - possible values "Auto" and "Manual". This variable value is set by virtual device. If value is set to Auto then Very Smart Lights™ scenes are enabled and will control lighting as needed. If value is set to Manual then Very Smart Light™ scenes will be disabled and light can be controlled old fashion way with wall switches only. You need to make simple VD to change value of this variable.
     
    4) GuestState - possible values "Yes" and "No". Value is changed either with VD or scene that is run when guests arrive. If set to Yes then lights will be set to predefined brightness level and can also be kept On during guests visit. This condition also has highest priority and will override all other conditions if set yo Yes.
     
    5) CookingState - possible values "Yes" and "No". Value is changed either with VD or scene that is run when you are busy in the kitchen. When set to Yes it will override other conditions bellow.
     
    6) MealState - possible values "Yes" and "No". Value is changed either with VD or scene that is run when you are having launch or dinner.  When set to Yes it will override other conditions bellow.
     
    7) ProjectorState -  possible values "Yes" and "No". Variable value is set by VD or scene that controls movie projector and other devices connected. As above variable if ProjectorState is set to Yes then scene will adjust light brightness to desirable levels. When set to Yes it will override other conditions bellow.
     
    ? CinemaState - possible values "Yes" and "No". Variable value is set by VD or scene that controls TV and other devices connected to TV. As above variables if CinemaState is set to Yes then scene will adjust light brightness to desirable levels. When set to Yes it will override other conditions bellow.
     
    9) HolidayLights - possible values "On" and "Off". Variable value is set by VD Holiday Lights v1.0. If value is set to On then lights will be dimmed to predefined brightness. Also scene will stop control selected lights which holidayFlag is set to 1 so that they can be controlled by some other scene or VD like HUE lamps changing colors. When set to Yes it will override other conditions bellow. If it is set to Off then other conditions will apply and scene will take over control of all lights even holidayFlag is set to 1. With all those Christmas lights blinking in color we don't want to spoil that atmosphere with main light turned on to maximum brightness so you can set special brightness level of dimmer lights and select not to turn on some of the switch lights, also you can choose some of the HUE lamps or any other lamp not to be controlled any more with Very Smart Light™ scene but use another scene to control their color or brightness change or even some of the nice mobile applications! Here you can download Holiday Lights VD that will change value of this global variable and turn on/off holiday (Christmas) lights:  [VD] Holiday Lights [Christmas Lights],
     
    10) IndoorLightsDim - possible values "Yes" and "No". This variable can be set by VD or scene. I used it to dim indoor lights during summer time to keep insects that are provoked by lights to enter our house through open windows and doors. So if set to Yes then lights in the house will stay dimmed to sleep brightness levels. This condition will be override by all conditions above.
     
    11) SleepState - possible values "Awake" and "Sleep" . This global variable value is controlled on my HC2 with two scenes. One is "Good morning" and is activated either by Alarm clock ACWUT (AlarmClock + WakeUpTime) - version 3.0.0 made by @jompa68 or manually with swipe or dimmer switch. Other one is "Good night" scene that is activated either by swipe or dimmer switch. This global is used only to change light brightness during sleep time. If you want to disable lights turning on then see bellow global variable SleepXxxxx!
     
    12) SleepXxxxx - possible values "Yes" and "No". In name of this variable use room name instead of Xxxxx. You can define this variable for bedrooms and living room if you use it sometimes as bedroom like SleepLiving, SleepMaster, SleepRoom1, etc. You need to add name of this global variable to local variable sleepingName. In comparison to "SleepState" which puts to sleep entire house or apartment this one is used to put to sleep only one room. So it can be used to turn living room into bedroom, or to disable lights in children rooms so they can go sleep earlier and we don't have to put entire house to sleep. If value is set to "Yes" then it disables smart light and immediately turns lights of. If set to "No" enables smart light and also turn on lights immediately if there was motion in the room. In our children bedrooms I setup dimmer 2 switch 2 to start scene on 1 click which then press button on VD to change state of this variable from "No" to "Yes" and vice versa so they can switch off lighting themselves. Put also this global variable under the scene header section %% globals! If you don't need it then just leave empty quotes.Value of this global variables can be changed to Yes or Sleep by simple VD with one label that will show status and one button to change status:
     

     
    All following global variables are global variables to be added in upper part of variable panel!
    12) Darkness - global variable (upper part of variable panel) with possible values 0 for day time (Light) and 1 for night time (Dark). Value is changed at adjusted time for sunrise and sunset time. This variable is also controlled by Main scene for time based events control
     
    Now when all needed global variables are defined in variable panel it is time to copy paste code to new scene and configure it. So let see through examples how to set this scene to control our lighting.
    Here is part of code where you can setup global variables names and make mapping of your values with corresponding values in code. Also you can define which of the extra conditions for light brightness levels you like to use by setting use variable either to Yes to use condition or No to not use. 
     
    Using this above global variables for different conditions allow us to automate change of lights status and it happens automatically without needing us to intervene. That's what home automation is about! Bellow is example of global variables setup for living room that can be also transformed to bed room:
     

    3,688 downloads

       (3 reviews)

    6 comments

    Updated

  15. 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!

    426 downloads

       (1 review)

    0 comments

    Updated

  16. Z-Range analyzer

    First of all, I would like to express my sincere appreciation to @10der  @Alex @petergebruers  @robmac  @amilanov @Bodyart @drboss and others for their time and help to improve / debug the code.
    The scene “analyzes” mesh network configuration in the system and displays the location efficiency of the devices in table format. Table sorted by the rooms according to average location efficiency of the devices in the room (in ascending  order - from lowest to highest efficiency). More like "Z-wave mapping" in your residence.
    In addition scene analyzes location efficiency of HC2 location.
    To achieve precise data, please make sure your devices' physical location correctly associated with room names.
    For example:
    in-wall switch located in kitchen, but controls lights in garden, should be assigned to kitchen and not garden.  (the device name should be assigned as  garden lights)
    Usually inclusion of the device done close to HC2 therefore the route table is incorrect. To achieve reliable data, perform inclusion when device located in designated place/spot in residence or perform Mesh Reconfiguration to device after inclusion near to HC2.
    User configurable parameters,:
    showDevices=false          if set tot true,not sorted table of all devices will be displayed also). fontSize=100     font size percentage (80% - 150%). Big Note: 
    If you've removed device which is part of mesh route to others, the route table doesn't get updated !
    Controller continues to maintain undated route table! Mesh table must be reconfigured. (Z-Range Analyzer identifies these devices.)
    Warning: Battery powered devices cannot forward packets and cannot be used in route for others.  
    To observe data in graphic, use @10der's visualizer.
     
    Run the scene and here some details on what will be displayed:
    When or if corrupted/deleted devices have found in your system, data details will be printed before table appearance.
     
    Table header:   
    ·       Number of master (physical) and slave devices in the system. By hovering mouse over controller name, table color index and Z-Capacity are shown
    ·       Date range of displayed data (if any changes done like adding, relocating devices after this date, mesh reconfiguration requires)
    ·       HC and devices location efficiency.  If devices lack mesh route data (colored by red) present in the system, two efficiency numbers displayed. (50%/60%).
    including devices with no routes and neighbors data excluding these devices. Table columns:

     
    1.    # 
    Script's total serial number / Script's serial number in room
    2.    Room Name  %
    Room name and average location efficiency of the devices in room
    3.    Parent ID: Name
    Parent (master) device ID, name and room. Devices lack mesh route data colored by red. By hovering mouse over, child (slave) devices list is shown (and number of last 24 hours z-wave events of each slave)
    4.   %
    Percentage of location efficiency of each device in the room.
    5.     iSee
    Total number of neighbors (adjacent) devices that it can communicate with (seen by device). By hovering mouse over, devices details are shown. Great view on how device located by seeing who neighbors are.
        The data shown in two colors:
                        I.            green - Device can communicate directly to controller. Shades of green according to number of adjacent neighbors. greener, more neighbors)
                      II.            red - Device doesn’t communicate directly to controller.  Shades of red according to number of adjacent neighbors. (redder, less neighbors)
    If tilde sign appears before  the number - means the list includes device(s) that not in the system (deleted device). I devices details menu this device marked grey.
     
    4.     Last Route
     List of devices that participate in route communication to controller. By hovering mouse over list of devices details is shown.
    3.     iRoute
    Total number of devices where this device is part of communication route. By hovering mouse over, devices details are shown.
    5.     Status
    Last working route status. (OK, pending, in progress, error)
    6.     Time Stamp
    Time stamp of last working route reported to the controller.         
    7.     24History
    Master's last 24 hours events number and percentage of total events. By hovering mouse over parent in Parent ID: Description column, number of z-wave events for each slave is shown. Please notice 24 hours history based on saved logs in event panel. If you have devices that excluded from saving logs,  theirs events are not available.
     
    Points for improvement
    Location efficiency calculated relatively to your best device in system, therefore red and yellow marked devices don't necessary indicates that your system is broken.
    Special attention requires when changing/removing physical place of devices in location with low efficiency level, it could cause loss of communication or delays.
     
            I.            Parent ID: Description - Device marked red indicates lack of route data. Perform mesh reconfiguration for this device. If reconfiguration failed, recommended to exclude/include the device (Painful process and occasionally updates in code are required).
          II.            Last Route - More devices in route increase probability of communication delay and indicates that device is in distance from controller.  Since in Z-Wave each device calculates the shortest route to the destination (up to 4 hops), therefore if route includes more than three devices recommended
    Check/verify devices in route as well. Mesh reconfiguration recommended. Device is far away from HC2 or Z-wave signal interrupted.     III.            iSee - If number is in shade of red and relatively low, means the device located far away from controller and low number of adjacent neighbors in that area or device located where physical barriers such as metal panels, concrete walls and etc. are blocking Z-Wave signal. (or located in-wall socket and Z-wave signal interrupted) Increased probability of packets loss rate, delay expected.
        IV.            iRoute - As much as number is higher, means increased workload for this device (needs to track messages from this number of neighbors). Increased probability of delays from device and routed devices.  Recommended number less than five devices.
          V.            Route tables do not get automatically updated by adding a new device or device relocation. Mesh reconfiguration (in Z-Wave Panel) requires.
    Do not reconfigure mesh network when devices are not in designated spot.

    845 downloads

       (6 reviews)

    81 comments

    Updated

  17. Z-wave monitor

    This scene monitors and catches Z-wave commands traffic between controller and devices. The data displayed to user as a table which includes total commands and their properties per device, in addition same data displayed at graphical chart and shows system activities over the time. Since Z-wave protocol is not a fastest one  (in many case it's just freeze) this code helps to analyze the data and to take necessary actions to reduce overall Z-wave traffic and system load.
    Scene functionality
    1. This is not an auto started scene. You need to start it manually. While the scene is running, you can switch views  between table/chart and  monitor (follow instructions on screen).
    2. User configurable parameters are:
    gVar = true-- Create and use global predefined variable. The scene could work with local table as well, but by using global parameter you can keep history of the traffic. It very helpful when you're updating the system to new release, to compare Z-wave performance. In case you have decided to use global variable, copy the data to other variable to keep the history. To view data of saved variable please download and use Z-wave Viewer scene.  Z-wave Viewer could be executed in parallel to Z-wave Monitor as well (when using global variable only)
    logRate = 5     -- Time rate in minutes to log Z-wave activity. Used as axis X scale in charts view. Reasonable value 5 to15 minutes for 24 hours of monitoring. In case to achieve better resolution the value could be decreased down to 1 minute.
    time2monitor = 6   -- Time-slot in hours to monitor z-wave traffic, after that time, table and chart will be displayed on debug window and scene will stopped. Value of  0 hours disables auto ending. User needs to stop the monitoring. If less than hour monitoring required please use decimal fraction. For example to set monitor time to 15 minutes set, time2monitor = .25
     markId = "|0|0|", " Cyan" -- Devices (IDs) list and text color to display specific devices in defined color at monitor view for follow up purpose. In few cases you need to monitor specific device, so fill-in the device ID and it will be highlighted by different color from other devices.
    deadOnTop = {true, "maroon"}  -- Display DEAD devices on top of the monitor view list in defined text color. Since we're not always looking on the screen, so in case the system will identify dead device it will continuously display the device (in red) on debug window.
     
    All variables below are the same for Z-wave Monitor  and  Z-wave Viewer
    chartHeight = 100        -- Chart height in percents (%). Chart's default height fits debug window.  The variable changes height of all charts (devices.scenes and events)
    chartWidth = 100         -- Chart width in percents (%). Chart's default width expands according to number of samples.  User could expand the width  to get better detail view or to stretch to visualize the load on time axis or to take snap shot of entire time line. The variable changes width of all charts (devices.scenes and events)
     
    topDev2disp = 6          -- Number of most active devices to display on devices chart.  If set to zero chart won't be displayed.
    topScene2disp= 10        -- Number of most active scenes to display on scenes chart. If set to zero chart won't be displayed.
    darkSkinMode = true      -- Charts display skin mode. Set false for light (white) skin.
    dev2review={false,"|470|804"} -- Generate chart for every device in list of actual device readings over the monitoring time. For devices with two results (like power and energy) both reading will be displayed. On left and right sides of the chart  applicable scale displayed. Please note, no chart is generated for devices like motion, door and any other sensors, which provide values of true/false.
    userDev={false,"|504|_531|"} -- User defined devices and scenes IDs to generate specific combined chart. Please write underscore before scene ID |_531| 
    stackedChart=true        --  A stacked line chart is an line chart in which lines do not overlap because they are cumulative at each point. Set to false to view standard line char. All charts except ZKG chart (events,CPU and RAM) will be displayed according to this variable.
     
     
     
    Brief explanation what is displayed:
    1. Monitor view
    This snap shot includes top and dead devices marked in different color from other devices.
    Two main sections in this view:
    Header
                 1:08:07/ 6:00:00               1824 events/77 devices            event/2.3s               (Click Start for )
        Elapsed Time/Monitoring time             Number of Z-wave events/devices          Z-wave traffic rate        Click to switch to table/chart view
                   
    Devices list
    Every device displayed at follow format -
     #2/34TV509@Salon(216.7 power) 
    #2/34 -First number is number of events during logRate slot. Second number is total number for events so far.
    TV509@Salon - device name, ID and room name
    (216.7 power) - actual reading and reading property
     
     
    2. Table view
    total # - number of total Z-wave events on device
    total %  - Percentage of device's events of total system Z-wave events.
    All yellow marked headers are received Z-wave properties, except two properties, dead and deadReason which are marked in red. For each device displayed the total number of this specific properties. Red marked ID, means that device was or is "dead" 
    By hovering mouse over device IDs, device and room names will be display (tool-tip) at popup box.
    At the end displayed few extra summaries 
     Elapsed time and Start-End timestamps
    Sample log rate as defined by user. Total samples during monitoring time
    Total Z-wave events and total number of active devices
    Average Z-wave traffic rate
    Z-traffic range. Shows the highest and lowest z-wave activities during monitoring time.
    If dead devices have found, list of them is displayed
     
    3. Most active devices chart
    This chart shows events number of most active devices ( up to number of all active devices allowed by setting topDevNum variable ) on monitoring time-line. On the right-upper corner displayed ID, name and room of the device. By hovering mouse on diagrams or legend, selected item will emphasized in bold to make the item more visible.
     
    4. Most active scenes chart
    This chart shows triggers number of most active scenes ( up to number of all triggered scenes allowed by setting topDevNum variable ) on monitoring time-line. On the right-upper corner displayed ID, name and room of the scenes. By hovering mouse on diagrams or legend, selected item will emphasized in bold to make the item more visible.
    5. Review device's actual readings - (dev2review)
    For devices with two results (like power and energy) both reading will be displayed. On left and right sides of the chart  applicable scale displayed.
    This chart most useful to identify  if device configured to send reports interval at high rate and " differ in readings to send report" set to very low value.
    By hovering mouse over the chart, will scale down the diagram to make visible entire range. In case the horizontal scrollbar is not in the middle of the chart , the diagram will flicker.
      
     
     
    6. User defined combined chart
    In some cases we  need to inspect behavior of some devices and scene that triggered by the device. This chart shows user defined devices and scenes on monitoring time-line. On the right-upper corner displayed ID, name and room of the scenes and/or device. By hovering mouse on diagrams or legend, selected item will emphasized in bold to make the item more visible.
     
     
     
    7. ZKG Chart View
    Chart view shows Z-wave traffic and system load on time line (based on logRate value). You actually could see your smart home beating heart (like EKG). I have named as ZKG (Z-wave cardiogram). Now it's possible to see the "rush" and "quiet" hours of the system.
    Chart view includes 5 diagrams displayed over time-line of monitoring period. The diagrams are:
    Z-wave events Triggered scenes CPU1  percentage CPU2  percentage RAM  percentage At top-right corner of the screen, displayed legend of the diagrams and colors.
    Events total number in same color as a diagram line.
    CPU1 min  > avg < max in same color as a diagram line.
    CPU2 min  > avg < max in same color as a diagram line.
    RAM min  > avg < max  in same color as a diagram line.
    Triggered scenes total in same color as a diagram line.
    Most triggered scene ID  and scene's name in same color as a triggered scenes
    In case dead devices have found during the monitoring period, the time stamp where it happened will colored red and at the top of the screen, directly above the time stamp, dead device(s) ID displayed.
    Axis Y has two scales. Left scale  represents occurrence numbers of Z-wave events and triggered scenes. Right scale is a percentage and it related to CPU1, CPU2 and RAM measured values.
    By hovering mouse on diagrams or legend, selected item will emphasized in bold to make the item more visible.
    I'm strongly advising to use global variable and to view the data using Z-wave Viewer in parallel to Z-wave Monitor
    The idea behind, that you can change parameters to view different devices/scenes on the fly.
    By changing user configurable parameters in Z-wave Monitor you'll need to start the scene all over again.
    Note:
    The debug text of these scenes is very big, so If you're using Clear Debug scene, please remove these scenes from the list.
     
    Please let me know if extra info is required.
    Please report if any bug occurred.

    3,555 downloads

       (13 reviews)

    110 comments

    Updated


×
×
  • Create New...