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


Recommended Posts

  • Topic Author
  • Posted
    7 minutes ago, jompa68 said:

    Ah, i see :D

    Time to sort up rules, thanks Jan.

     

    Merry Christmas!

    Thanks,

    the 'enable' command has a 'secret' second option that 'disables' all other defined sections.

    Please login or register to see this code.

    will disable 'Summer'. That can in some cases be useful if the sections are mutual exclusive. It's a bit noisy now as there is a log statement logging all sections being disabled. It's on line 297 and you can remove it. I will take it away the log statement in the next release.

  • Topic Author
  • Posted

    I have made a VD that can be used for debugging EventRunner based scenes.

    Please login or register to see this image.

    /monthly_2018_12/EVVD.png.3c7b438420febf0d9413aca48870dab4.png" alt="EVVD.png.3c7b438420febf0d9413aca48870dab4.png" />

    Pressing "Refresh" scans through all scenes and collects the ones based on EventRunner framework (works from v1.5)

    '<<' and '>>' moves between the scenes.

    In the scene you need to add 2 things:

    Please login or register to see this code.

    First a comment block that starts with "--[[CMD" and contains one command per line.

    Secondly a handler that receives events from the VD and executes them.

    Here I just do Rule.eval but it could be something more advanced.

    In the VD the commands will show up when a scene is selected. '<<' and '>>' move between the commands and 'Eval' sends it to the scene as an event of type

    {type='%VDEVCMD%', cmd=<cmd>, id=<id of VD>}

    and we catch that event in the scene and evaluate the command.

    This VD is useful for sending test events to EventRunner scenes when running live on the HC2, or other housekeeping commands that one wants to send to scenes.

    The VD is available in the Github <

    Please login or register to see this link.

    >

    Posted

    Cool! Works very well

    Posted

    @jgab need some help with rules.

    When i test this with ZBS it looks like it triggers even that i only have 1 of the device/variable set to true. What is the right approach here?

     

    For example if UHASDarkness is not "Dagsljus" it triggers when i change value on lux and turnOff light

    Please login or register to see this code.

     

  • Topic Author
  • Posted (edited)
    2 hours ago, jompa68 said:

    @jgab need some help with rules.

    When i test this with ZBS it looks like it triggers even that i only have 1 of the device/variable set to true. What is the right approach here?

     

    For example if UHASDarkness is not "Dagsljus" it triggers when i change value on lux and turnOff light

    Please login or register to see this code.

     

    In short, it is the OR '|' that makes the rules behave in an unintentional way. In general one should avoid OR in the header but there are cases when it helps. Often when one makes expression with OR in the header it is actually when trying to combine several rules into one because they have the same action, right-hand side. Your rule rewritten, that probably works as you intended:

    Please login or register to see this code.

    Why the original doesn't work is due to how rule triggering work. When the rule is compiled all devices and fibaro globals are collected in the header and event handlers are created to trigger the rule when any of them changes. That is the list you get when you do a Util.printRule(<rule>) like in an earlier post. Anyway, ex. for the second rule, assume that UHASDarkness is not "Dagsljus" and you change the value on lux. You could think that because  UHASDarkness is not "Dagsljus" that ($UHASDarkness=='Dagsljus ' & vardagsrum.light2:lux < 20) would be false. However, if one of $VSL_sleep_4=='Sover'  or $UHASPresentState=='Borta' is true the overall condition will be true, even if it is the lux change that triggered the rule.  The solution, the way it is coded in my example above, when lux changes it only triggers the relevant rules.

     

    I have tried to make the system intuitive so one shouldn't need to think about triggers, but this is clearly one such case - where it isn't so intuitive. So the solution is to be careful with OR in the header.

    In some cases, many rules have the same right-hand side actions and they can be long and complicated. That is a case when it is tempting to combine the rules. However, in that case it is much better to factor out the actions.

    Please login or register to see this code.

     

    Edited by jgab
    Posted (edited)

    Thanks for clarifying this Jan.

    Edited by jompa68
    Posted

    Jan

     

    Ok so moving on to get my head around events to manage lights ... particularly lights left on for a period of time.   

    Please login or register to see this code.

    This simple test code is currently triggering an API error.    Is this something in my setup of ER v1.6 orsetup / problem in my HC2 (still on 4.510 until I read better comments from the community!).

    Please login or register to see this code.

    Cheers

  • Topic Author
  • Posted (edited)
    1 hour ago, ipsofacto said:

    Jan

     

    Ok so moving on to get my head around events to manage lights ... particularly lights left on for a period of time.   

    This simple test code is currently triggering an API error.    Is this something in my setup of ER v1.6 orsetup / problem in my HC2 (still on 4.510 until I read better comments from the community!).

    Cheers

    I’m away from my computer 24hours so I’m unable to test, but typically when you get an API error is when a Fibaro call have the wrong parameters. If you turn on the logging of Fibaro calls by setting _debugFlags in the beginning of the scene.

    _debugFlags = { post=true,invoke=false,triggers=false,dailys=false,timers=false,rule=false,ruleTrue=false,fibaro=true,fibaroGet=true,fibaroSet=true,sysTimers=false }

    then you see what gets wrong. My suspicion is that one of the devices 333,524 or 335 doesn’t exist.

    Edited by jgab
    Posted

    Jan - always a fast response - thanks!

     

    A quick test with debug and the key log lines seem to be as below

     

    I double checked Study.StudySpotLights and Study.StudyWallLights are defined in Hometable ... my log above prints the lights array that I construct for the rule.

    Please login or register to see this code.

    Is this an isAnyOn related error? .. 

    Please login or register to see this code.

    Please login or register to see this code.

    I've doubled checked.   Any other places I might have missed something?

  • Topic Author
  • Posted

    Yes, :isAnyOn isn’t a function. ID:isOn returns true if any is on. 

    fibaro:get(Study.StudySpotlights,”isAnyOn”)=null gave it away.

     

    If <id>:<prop> doesn’t recognize <prop> it tries to do a fibaro:get(<id>,<prop>) with the hope that the device has that property.

    Posted

    Great thanks.   wiki tutorial page made  me to assume I needed an isAnyOn similar to isAnyOff.  

     

     

    Thanks for - as always - the quick turnaround and support.    Happy Holidays.

     

     

  • Topic Author
  • Posted (edited)

    I bought myself some Hue lights in Xmas presents. I still haven't figured them out completely and I only have the RGB bulbs- Anyway it bothers me that, as lights, I have to treat them differently in the scripts. 

    So, I made this hack that allow me to code like this:

    Please login or register to see this code.

    The Hue.define function actually assigns them an deviceID from 10000+ and we intercept calls to fibaro:* to see if the devideID is mapped to a Hue light/group. It also optionally assigns an EventScript variable the deviceID

    Hue calls are asynchronous, so we do an "optimistic" state change, i.e. when turning off a light we immediately cache the state to off and later when we get the result back we set the state again. That is so if one part of the script turns off a lamp, another can test it immediately...

    The code is still experimental, state changes do not trigger rules and there is no support for sensors/switches.

     

    The other thing is that the call to setup the Hue function is asynchronous and Hue.defvar etc can not be used before it has finished. A practical design pattern to handle that is to create an additional main() function. In this way we don't have to mess up our rule definitions.

    Please login or register to see this code.

    This is the pattern I have used to add the Hue support in the example below.

    Please login or register to see this code.

    It's experimental code, but if it seems to work out it could be included in the framework in some way. I'm a bit unsure about support for sensors as it means polling the bridge continuously, which is a really bad model. I hope that the Hue people will come up with some call-back mechanism.

     

    Edit: Hue support now included in EventRunner.lua so no need to do it this way. See next post.

    Edited by jgab
    • Like 1
  • Topic Author
  • Posted (edited)

    Ok, pushed a new version of EventRunner.lua with the experimental support for Hue.

    If you set HueIP and HueUserName in the beginning of the file I will initiate the Hue object and it will be ready when main() is called (if any variable is nil the Hue setup will be skipped and the Hue object will be nil)

    So it will look like this.

    Please login or register to see this code.

    So, hue devices get deviceID numbers from 10000 and upwards. I'm thinking how to best integrate this with a HomeTable model...

     

    Note. The Hue code in mainAux() should be possible to lift out into an "ordinary" scene (e.g. a scene not based on the EventRunner framework) to get the fibaro:* functions supporting hue lights. However, for short lived trigged scene instances the overhead may not be worth it.

    Edited by jgab
  • Topic Author
  • Posted

    Ok, pushed a new version EventRunner.lua with some bug fixes for the Hue support.

    There is a (experimental) way to get events from sensors/switches now:

    Please login or register to see this code.

    It will poll the hue device at the given interval and it will post {type='property', deviceID=<id>, propertyName=<prop>, value=<value>} events if a property change values for a light/sensor/switch

    There is a filter so it only posts 'buttonevent' and 'on' property changes. It can be changed.

    Hue.monitor(<Hue name>,0) will turn off monitoring. The time interval can also be changed while running. I.e. start polling a switch if a fibaro sensor senses someone in the room. All this to try to minimize polling of hue devices...

    Posted

    I have created something similar for hue support but as a complement of Event runner framework.

    Currently I have 6 different scenes with Event runner framework and I don't want to have hue support in every file ei. for timers :)

     

    I will send PM with my current hue support - it's a still under development ....

     

     

    Posted

    I want to have HUE support so please continue with testing. 

  • Topic Author
  • Posted
    3 hours ago, petrkl12 said:

    I have created something similar for hue support but as a complement of Event runner framework.

    Currently I have 6 different scenes with Event runner framework and I don't want to have hue support in every file ei. for timers :)

     

    I will send PM with my current hue support - it's a still under development ....

     

     

    No problem. The Hue system I have included is easy to override with your own code if you have a solution that suits your needs better. My intention is just an easy to use integration of Hue devices to make them look like z-wave devices and as transparently as possible for use in event handlers and event script rules. If you don't enable the Hue code (by setting HueIP or HueUserAddress to nil) it doesn't take any resources except some code. However, the whole mainAux() function can be removed. Even if enabled there are no timers started unless a call to Hue.monitor is done to get triggers from the Hue bridge.

    In general I try to keep additional functionality in separate scenes (iOSLocator, CronService etc) but I really wanted tight integration with fibaro:* calls and the eventscript engine so this was the only way for me to solve it.

    I'm typically not using any VDs to control things (I like the system to think for itself :-) ) so I haven't thought about how to do that kind of integration. So, please continue with your project and see if you can come up with a Hue VD model that integrates with the eventrunner framework. I'm trying hard to make sure that the eventrunner framework will continue to be compatible with your scenes (I'm happy to see you using it in so many scenes).

    Rgrds/J

    3 hours ago, jompa68 said:

    I want to have HUE support so please continue with testing. 

    I have been running rules and handlers the whole day with my 5 Hue rgb lights (and a Hue dimmer switch) and it seems to work pretty well. The goal is to use them as any other z-wave light which will not be 100% due to the different models. It's reasonable now but can probably be improved. What I have come to realise is that one really wants to use the group and scene concepts of the Hue system, and a group can be treated as any other device with :on, :off etc.. and <group>:value='<scene>' to set scenes.

    Anyway, it would be useful if you dared to try it because you have a good track record to find faults in my coding :-) 

    I moved my main auto light scene to it this evening so let's see if its survives the morning when lights and scenes are turned on. However, I coded it so I may subconsciously avoid doing things that break the code....

    Posted

    Yeah, i can test it. I have some "off work" days coming up so :-D

    Posted (edited)

    @jgab

    could you please add following change into your code or something similar:

    Please login or register to see this code.

    based on that there will be possible to run events in miliseconds if needed. Thanks

    Please login or register to see this code.

     

    5 hours ago, jgab said:

    I have been running rules and handlers the whole day with my 5 Hue rgb lights (and a Hue dimmer switch) and it seems to work pretty well. The goal is to use them as any other z-wave light which will not be 100% due to the different models. It's reasonable now but can probably be improved. What I have come to realise is that one really wants to use the group and scene concepts of the Hue system, and a group can be treated as any other device with :on, :off etc.. and <group>:value='<scene>' to set scenes.

     

    @jgab Is it possible to add also support for more hue bridges?

    Edited by petrkl12
  • Topic Author
  • Posted
    19 minutes ago, petrkl12 said:

    @jgab

    could you please add following change into your code or something similar:

    based on that there will be possible to run events in miliseconds if needed. Thanks

     

    If you just need a ms post you can do

    Please login or register to see this code.

    If you need it in Event.post you can patch Event.post inside main() to take ms...

    Please login or register to see this code.

    However, I don't think it is a good idea because when we are down on ms the overhead of the event system is starting to show (it takes some time to dispatch an event).  

     

    If it is about doing specific time things I would go for 'setTimeout' alone.

     

    For the Hue stuff I built there is a Hue.monitor(<Hue device>,< time in ms>) that uses a basic setTimeout loop. However, polling something over the network in ms intervals is terrible.... The real solution is that the Hue people start to support a call-back from the bridge . Many seems to ask for it and I'll be the first in line to use it.

     

    Yes, there is a possibility to initiate many Hue 'objects', one for each bridge, the only trick is to make sure we wait for all to finish their initialisation before calling main(). Then one would want a Hue.define(<Hue device>,<name>) that looked across all hue devices in all bridges. Let me think about it a bit.

    1 hour ago, jompa68 said:

    Yeah, i can test it. I have some "off work" days coming up so :-D

    Thanks,

    I'm kind of interested in what Hue features people uses and use cases, e.g. scenes, groups, setting individual attributes, how often state changes need to be monitored etc. Ex. now I support fibaro:call(id,"setColor",R,G,B,W) to make them behave like fibaro RGBW module. Is that useful? need to support getValue too for 'color'?

    Join the conversation

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

    Guest
    Reply to this topic...

    ×   Pasted as rich text.   Paste as plain text instead

      Only 75 emoji are allowed.

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

    ×   Your previous content has been restored.   Clear editor

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

    ×
    ×
    • Create New...