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

25 minutes ago, jgab said:

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'?

I have 4 HUE ambiance spot in a group outside located on my house wall and the other 4 are ambiance candle (E14) in window.
Outside group are always powered on 100% but inside lights i dim to XX% if no movements after XX minutes and back to normal when sensor see movements.

Link to comment
Share on other sites

  • Topic Author
  • 3 minutes ago, jompa68 said:

    I have 4 HUE ambiance spot in a group outside located on my house wall and the other 4 are ambiance candle (E14) in window.
    Outside group are always powered on 100% but inside lights i dim to XX% if no movements after XX minutes and back to normal when sensor see movements.

    ...is dim just setting the brightness property {bri=X} ? or do you set scenes?

    Now when doing fibaro:call(hueID,"setValue",X) or hueID:value=X, I send the parameters {bri=X/99*254} to the light (or group). When recalling value, fibaro:getValue(hueID,"value") I return 0 if the 'bri' is 0 or if reachable=false. Otherwise I return math.floor('bri'/254*99+0.5).  The Hue has range 0-254 but fibaro only have 0-99, and my thinking is that's more compatible to translate then to return values > 99...

    Link to comment
    Share on other sites

  • Topic Author
  • 15 minutes ago, jompa68 said:

    i just set brightness but scene is possible.

    Ok, so that's currently supported by <id>:value=<dim value> or fibaro:call(<id>,'setValue',<dim value>) .

     

    To integrate with a HomeTable I pushed a new version that gives a possibility to give the deviceID number to Hue.define

    Please login or register to see this code.

    Normally with Hue.define assigns ids starting with 10000, but with the (optional) third argument we can decide ourselves. Just make sure it doesn't collide with an existing deviceID.

    The idea is that if we have a HomeTable with

    Please login or register to see this code.

    we could do

    Please login or register to see this code.

    to link the right Hue device name to the right id, and then we could do

    Please login or register to see this code.

     

    Edited by jgab
    Link to comment
    Share on other sites

    When i enable debug on fibaroGet i dont see that it grabs the variable "nightSafeTime". Is this correct?

     

    Please login or register to see this code.

     

    Link to comment
    Share on other sites

  • Topic Author
  • 35 minutes ago, jompa68 said:

    When i enable debug on fibaroGet i dont see that it grabs the variable "nightSafeTime". Is this correct?

    It only starts reading "nightSafeTime" when e.g. rule 5 is triggered - and it should log it then.

    To be sure start rule 5 with rule("log("R5 invoked") & for(time($nightSafeTime),...  "). Then you should see "R5" just before the getGlobal log. If not, something is very wrong... Also, you could do a rule("log('$nightSafeTime=%s',$nightSafeTime)") just before the definition of rule 5 to be sure that nightSafeTime is correct.

    Link to comment
    Share on other sites

    Now some hue setup fails....

     

    in my hometable i have this

    Please login or register to see this code.

    and EventRunner setup like this

    Please login or register to see this code.

    and finally the error

    Please login or register to see this code.

    Aha! Think i mapped them wrong.

    Edited by jompa68
    Link to comment
    Share on other sites

  • Topic Author
  • 18 minutes ago, jompa68 said:

    Now some hue setup fails....

     

    in my hometable i have this

    Please login or register to see this code.

    and EventRunner setup like this

    Please login or register to see this code.

    and finally the error

    Please login or register to see this code.

    Aha! Think i mapped them wrong.

    Yes :-) I had id=name you have name=id

    Link to comment
    Share on other sites

    Does not turn on my spot1 when i test in live scene. 

     

    Please login or register to see this code.

    Please login or register to see this code.

    Please login or register to see this image.

    /monthly_2018_12/image.png.84c8cbe2169407dfa7ee8325e2a7d9df.png" alt="image.png.84c8cbe2169407dfa7ee8325e2a7d9df.png" />

    Link to comment
    Share on other sites

  • Topic Author
  • 19 minutes ago, jompa68 said:

    Does not turn on my spot1 when i test in live scene. 

     

    Please login or register to see this code.

    Please login or register to see this code.

    Please login or register to see this link.

     

    set _debugFlags.hue=true and it will log the http request and payload - and see if it makes sense.

     

    If you have an experimental scene just do a rule("huevagg.spot1:on") and see if it turns on.

     

    'turnOn' only sends payload {on=true} to the light. If brightness is low (~=0) it will not show I guess. On the other hand I don't want to up brightness either if people have a preset they like.

     

    ...and don't forget the username is part of the URL ;-) 

    Edited by jgab
    Link to comment
    Share on other sites

  • Topic Author
  • The EventRunner framework now has support for Hue lights.  It's still experimental in the sense that it is hot off the press, so there could be bugs.
    Anyway, here is a summary on how to setup and use the Hue module.

     

    In the beginning of the EventRunner scene set up:

    Please login or register to see this code.

    The Hue username you can get by following this guide 

    Please login or register to see this link.

     

    If those variables are setup and correct the Hue module for EventRunner will be initialized before we enter main()


    In the EventRunner framework all rules are setup inside the main() function

    Please login or register to see this code.

    The Hue module for EventRunner will re-define versions of fibaro:* functions that operate on Hue lights in additions to standard Z-wave devices. However, to be able to do that we need to map Hue devices to "Z-wave device IDs". We fake it by giving Hue devices high device ID numbers (above 10000), and we do it with the function Hue.define(<Hue device name>,<Eventscript variable>,<device ID number>)

    •   <Hue device name> is the name the device has on the Hue bridge (visible in the Hue app). It can be lights, groups, or sensors.
    •   <Eventscript variable> is a  optional string or nil that will define an eventscript variable assigned to the id the Hue device gets
    •   <device ID number> is optional the number that will be the deviceID for the Hue device. If nil it will be assigned values from 10000 and upwards. However, in many cases we want to assign the ID value ourselves because we have those in a HomeTable like in the example above. In the example we have a map from Hue device names to deviceIDs, and we loop over that table assigning ids to devices.

    When that's done we can use fibaro:* functions to manipulate our Hue devices the same was as normal z-wave devices:

    Please login or register to see this code.

    All other fibaro:getValue(<id>,<prop>) will try to return the property <prop> from the Hue device. Ex. for a Hue switch, fibaro:getValue(<id>,'buttonevent') will return the last 'buttonevent' property.

     

    There are also some additional non-standard ways to manipulate Hue lights

    Please login or register to see this code.

    These commands also works on sensors, and will return the properties. However at the moment 
    fibaro:getValue(<id>,'value') will not work for sensors as they don't have 'on' or 'bri' property.

     

    When running the EventRunner framework, changes from within the scene to a Hue devices will generate the corresponding SourceTrigger event.
    Ex.

    Please login or register to see this code.

    will generate an event of type

    Please login or register to see this code.

    Other property changes on a Hue lamp will generate events for that property

    Please login or register to see this code.

    will generate the following events

    Please login or register to see this code.

    The problem is that for sensors (and sometimes lights) we are not changing states from the scene, but people interact with them - and we would like to get event also then.
    The Hue system has no way to get call-backs from the Hue bridge when devices change states. The only way to do it is to poll the bridge. This is not a satisfactory solutions but the only way until Philips fixes the API.
    The way to monitor a device for now is to use

    Please login or register to see this code.

    This function will start to poll the device at the given intervals. Called with time==0 will stop monitoring.

    Please login or register to see this code.

    If the device changes state it will generate events as described above.
    If a button on the switch is pressed it will generate an event of type

    Please login or register to see this code.

    Because EventScript is based on events and fibaro:* calls, Hue devices will work in eventscript rules too

    Please login or register to see this code.

    In the example we see that we increase the polling of a Hue switch when we detect a motion in the room, the logic being that we will only get keypresses when someone is in the room. Rules like this could lower the load on the bridge and only poll relevant Hue devices at relevant times.

     

    I still only have a few types of Hue devices so I haven't been able to test all setups. Also exactly how to map Z-wave/fibaro values to Hue values and back is still under experimentation and experience will show what's best...

    Some things that one could do is to allow Hue scenes to be applied to individual lights (something that the API doesn't allow - but could be just to copy the scene's attribute to the light)

    Better mapping of values - 'button event' could be mapped to fibaro's 'CentralSceneEvent' to make it more compatible...

    Edited by jgab
    Link to comment
    Share on other sites

    FIrst group of hue lights setup

    Please login or register to see this image.

    /monthly_2018_12/image.png.28b2bca78364d0387d19bba0cf34dafa.png" style="width:400px;height:auto;" alt="image.png.28b2bca78364d0387d19bba0cf34dafa.png" />

    Link to comment
    Share on other sites

  • Topic Author
  • and it works? 

    I have 3 lamps in the kitchen windows (Advent stars), but I have defined them as a Hue group - and turn them on/off with a single deviceID. Of course your way is more flexible. 

    The reason to have Hue groups is that the lights turn on/off more in sync. I guess now you can see the lights turning on in sequence?

    Link to comment
    Share on other sites

    Yes it works very well. All lights turnOff and On at the same time. Atleast it looks so in the hue app.

    Link to comment
    Share on other sites

    @jgab

    i have setup HUE in an own scene now, can i combine that to my normal eventrunner cron scene?

     

    Please login or register to see this code.

    defvars and reverseMapDef will be set to latest define i guess, or?

    Link to comment
    Share on other sites

  • Topic Author
  • Yes, you can just move over the HUE scene rules to the cron scene. (and also move the HueIP, HueUserAddress, and the Hue.defines)

    ...and you need to update the cron scene the latest version of the framework with the hue support.

    You may also restructure the HomeTable so you have the hue lights mixed with ordinary lights instead of on a separate 'hue' branch.

     

    Link to comment
    Share on other sites

    1 hour ago, jgab said:

    Yes, you can just move over the HUE scene rules to the cron scene. (and also move the HueIP, HueUserAddress, and the Hue.defines)

    ...and you need to update the cron scene the latest version of the framework with the hue support.

    You may also restructure the HomeTable so you have the hue lights mixed with ordinary lights instead of on a separate 'hue' branch.

     

    Ok, did move them now and i needed to change a bit in the code.

    from

    Please login or register to see this code.

    to

    Please login or register to see this code.

     

    Link to comment
    Share on other sites

  • Topic Author
  • 10 minutes ago, jompa68 said:

    Ok, did move them now and i needed to change a bit in the code.

    from

    Please login or register to see this code.

    to

    Please login or register to see this code.

     

    Yes, in my "hometable" I have mixed the hue devices with the "ordinary" devices, to put them in the room they are. Ex.

    Please login or register to see this code.

    and in that way I can do kitchen.lamp:on or kitchen.desk:on, without bothering if they are Hue lamps or Z-wave lamps.

     

     

    Edited by jgab
    Link to comment
    Share on other sites

  • Topic Author
  • New version, v1.7, of EventRunner. Update EventRunner.lua, EventRunnerDebug.lua

     

    -Initial support for Hue devices see post <

    Please login or register to see this link.

    >

     

    -Change in how Eventscript handle ':<props>' access on tables.

     The normal syntax is to do {77,99}:on to turn on both 77,99. This is quite useful for applying commands to groups of devices. However, many people have 'HomeTable' data structures with their devices grouped in rooms or other logical sets.

    Ex.

    Please login or register to see this code.

    ... and wouldn't it convenient to apply ':on' to kitchen? I used to assume that the table argument was a 1 indexed simple table with device numbers. Instead, now I loop over the table argument with 'pairs' and apply the property command to the value part (unless it's a table, then I ignore it).

    This means that stuff like this also works in addition to the standard behaviour.

    Please login or register to see this code.

    This works for

    • :on
    • :off
    • :isOn
    • :isOff
    • :isAllOn
    • :isAnyOff
    • :safe
    • :breached

    Currently, it'is not recursive, so it will not descend tables inside tables... It is easy to allow but it makes the semantic of ':value' complicated. It would be nice to apply :prop commands to parts of or the whole HomeTable tree with some kind of filter - like getDevicesId or callGroupAction...

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

  • Topic Author
  • How to best deal with Hue devices depends on how they are fitted into the HA system. The EventRunner framework tries to make them look like ordinary fibaro devices, both when it comes to commands and triggers. However, it's still tricky to always make the best mapping from Hue values/events to fibaro/Z-wave values/triggers.

    Ex. If we have a Hue dimmer switch with the assigned deviceID 10000 and we poll it at an interval

    Please login or register to see this code.

    we now get this event when the first button is pressed:

    Please login or register to see this code.

    This means that we can write event handlers like this to trigger on a button event:

    Please login or register to see this code.

    It's only Hue devices that emit 'buttonevent' events, and if we have other Z-wave keypads that give 'CentralSceneEvents' we may want to "harmonise it".

     

    The advantage with an event model, that the EventRunner framework uses, is that we can easily write an event transforming rule:

    Please login or register to see this code.

    We trigger on the incoming 'buttonevent' event and we re-post it as a CentralSceneEvent, mapping the keyId and keyAttribute from the 'buttonevent' value.

    Now we have a Hue switch that behaves like any other Z-wave keypad in our system and we can have the same rules or fibaro event handlers.

    Please login or register to see this code.

     

    Edited by jgab
    Link to comment
    Share on other sites

    Join the conversation

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

    Guest
    Reply to this topic...

    ×   Pasted as rich text.   Paste as plain text instead

      Only 75 emoji are allowed.

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

    ×   Your previous content has been restored.   Clear editor

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

    ×
    ×
    • Create New...