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


HC3 QuickApps coding - tips and tricks


Recommended Posts

1 hour ago, jgab said:

Install the new QA. Open it up in the editor (in the WEB GUI of the HC3) and cut and paste the content into the old QA, and save. Then delete the newly installed QA.

As I suspected. thx

Link to post
Share on other sites
  • Replies 1.2k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

This thread is most about QuickApp tricks and usually requires some deeper understanding of Lua. I'm going to make an attempt to do something more tutorial wise that could work for newcomers to Lua. I

A thread to share some coding techniques for QuickApps?  Because QAs are "long running scenes" (they don't have to be loaded and restarted for every event) - it is actually worthwhile to build up

The anatomy of QuickApps – Part 2 (Please login or register to see this link. )   Disclaimer1: We are now venturing into undocumented land. That means that Fibaro is free to change how things wo

Posted Images

  • Topic Author
  • 10 hours ago, SuSuDaddy said:

    Is it possible to add buttons or labels or slides on child devices?

    I don't know - try?

    However, it seems like (some) child devices have another UI model.

    Link to post
    Share on other sites
    4 hours ago, jgab said:

    I don't know - try?

    However, it seems like (some) child devices have another UI model.


    I tried to make a child device ui like the picture but i couldn't find a way

    Please login or register to see this attachment.

    Link to post
    Share on other sites
  • Topic Author
  • 22 hours ago, jgab said:

    Install the new QA. Open it up in the editor (in the WEB GUI of the HC3) and cut and paste the content into the old QA, and save. Then delete the newly installed QA.

     

    Yet another version.

    Can also add Light groups. They will be treated as dimmable lights - turn on/off/toggle + dim. Future release may support changing colors if colors are available.

    Please login or register to see this attachment.

     

    So the UI is limited to what the child devices support. However it's easy to add fibaro.call support for more functionality.

    What more would be useful? Send arbitrary Hue parameters? set Hue light program?, Scenes?

    Hue devices could also send custom-events. The Hue Lightsensor triggers on "dark" and "daylight" - send custom events in that case?

     

     

    Link to post
    Share on other sites
  • Topic Author
  • So, my offline SDK supports QA child devices, and as a test I have implemented a Hue device controller that creates child devices for the various hue devices...

    Because I have to emulate the behaviour of the HC3 api's I'm starting to get a decent idea what is going on....

    Here are some findings and tricks if you are into creating child devices too (my main tip would be to use the SDK as it allows you to debug this in a proper way...)

     

    Child devices have a property, parentID that points out the QA that created the device:

    Please login or register to see this code.

     

    For the parent QA to get the list of children one can do

    Please login or register to see this code.

    The way I implemented it in the SDK is probably how it looks on the HC3...

    Please login or register to see this code.

    When the parent QA starts up, the QA is supposed to call self:initChildDevices in the QuickApp:onInit() function.

    Ex.

    Please login or register to see this code.

    The argument is a table with mappings between devices types and QuickAppChild classes. The above is an example with just 1 mapping, com.fibaro.binarySwitch to the constructor MyBinarySwitch (that is a subclass of QuickAppChild)

    What the HC3 does is probably:

    Please login or register to see this code.

    It fetches all the child devices and then depending of the type of the child devices call the QuickAppChild subclass constructor associated with the type.

    Here the Fibaro documentation informs us that if we have different types mapping to the same child class we can do:

    Please login or register to see this code.

    However, what if you want to do the opposite? The com.fibaro.<type> decides the child UI you get for your device. With my Hue QA I found myself wanting to map different Hue lights to the same com.fibaro.colorController type. At the same time I wanted different QuickAppChild classes to represent the different Hue types because they behave slightly different.

    Please login or register to see this code.

    ...but that doesn't work of course.

     

    Another thing that the Fibaro documentation advice about is to keep the devices in sync by storing the external ID (the hue device ID in my case) and the QA child device ID in a Lua table and save that in quickAppVariable. That way we will not accidently remap the devices every time the QuickApp starts up or restarts.

     

    Here we have another small problem. If the user deletes a child devices using the webGUI we will not find out so we need to be careful keeping the list in sync. Different strategies can be used, scanning the self.childDevices list regularly to see if any child has disappeared. At startup, see if our saved list is different from self.childDevices (after we called self:initCildDevices(..))

     

    The strategy I have fallen back to is twofold:

    Please login or register to see this code.

    Here we in principle do the self:initChildDevices ourselves, but a bit smarter as we have a better way to map QuickAppChild IDs to classes.

    The problem is that if we don't call self:initChildDevices() the QuickApp:onInit() will do it for us, creating a lot of unnecessary class object. The way around it seems to be to redefine the function to do nothing. It's of course very dependent on the current implementation that Fibaro has chosen but hopefully they will provide us with a better way to associate IDs with classes in the future....

     

    Child devices can't have quickAppVariables. At least I haven't found anyway to make them stick. I have added the quickAppVariables property but to no avail.

    So instead we store it in the child's userDescription property. There we can store the stuff we need to create the right class and make the right id associations.

    That way we don't need to keep a separate list synced. If a user removes a child it will not be picked up the next time we start up.

    The DEV2HUE and HUE2DEV maps are temporary tables that don't need to be saved.

     

    When we create the childDevice it is important to set the userDescription property

    Ex:

    Please login or register to see this code.

     

    So, that's one way to do it...

     

    Next task - how to hack the child devices UIs?

     

    Edited by jgab
    Link to post
    Share on other sites
    18 hours ago, jgab said:

    So instead we store it in the child's userDescription property. There we can store the stuff we need to create the right class and make the right id associations.

    Thanks for sharing your thoughts. I'am working on a QA with child devices and I am thinking in the same direction... Fibaro suggests storing a mapping table in a QA variable in the parent, but I was thinking of using a child property like userDescription. But it feels "unsafe". Storing that mapping table in a QA var is "unsafe" in another way,  in either case the data is clearly visible and if the user decides to edit it... boom... I'd prefer a dedicated field, a bit like a "serial number". In case of eg a Zigbee devices that could store the Zigbee client ID (I would pick the IEEE address of the node, so very stable with respect to the physical object, same device can join/leave as many times as you like) - then some endpoint/function mapping (eg Zigbee Motion sensor can have motion and Lux)...

    Link to post
    Share on other sites
  • Topic Author
  • 47 minutes ago, petergebruers said:

    Thanks for sharing your thoughts. I'am working on a QA with child devices and I am thinking in the same direction... Fibaro suggests storing a mapping table in a QA variable in the parent, but I was thinking of using a child property like userDescription. But it feels "unsafe". Storing that mapping table in a QA var is "unsafe" in another way,  in either case the data is clearly visible and if the user decides to edit it... boom... I'd prefer a dedicated field, a bit like a "serial number". In case of eg a Zigbee devices that could store the Zigbee client ID (I would pick the IEEE address of the node, so very stable with respect to the physical object, same device can join/leave as many times as you like) - then some endpoint/function mapping (eg Zigbee Motion sensor can have motion and Lux)...

    It's less visible in a property than in a quickVar for the average user... Btw, doesn't seem like quickVars can be added to child devices.

    self:createChildDevice takes an initialProperties field in the props argument. Would be nice if fields could be added at that moment that were not "writable" later on. I assume they have some kind of schema that tells what is allowed or not in a QA struct.

    • Like 1
    Link to post
    Share on other sites
  • Topic Author
  • On the topics of QuickAppChildren and where to hide the ID...

    Children of type com.fibaro.philipsHueLight has a default property 'lightId' that seems to serve this purpose...

     

    I played with that type because it has a hue and saturation slider (as opposed to the colorController that only have an RGB slider)

    however I have not been able to get any callbacks when I interact with the 'Hue' slider.

    In the debug I get an "onAction" log with element "hue" but then it complains that there is no handler for "hue"

    I have tried MyChild:hue, MyChild:setHue, etc. but not got any callback. Have anyone tried com.fibaro.philipsHueLight and manage to get it to work?

    For com.fibaro.colorController I get callbacks on MyChild:setColor etc so that one works well.

     

    Link to post
    Share on other sites

    Hi jgab,

    Your script is so pretty.  i Always learning through your script.
    thank you for your help!

     

    Edited by SuSuDaddy
    Link to post
    Share on other sites
  • Topic Author
  • On 4/24/2020 at 7:19 AM, jgab said:

    On the topics of QuickAppChildren and where to hide the ID...

    Children of type com.fibaro.philipsHueLight has a default property 'lightId' that seems to serve this purpose...

     

    I played with that type because it has a hue and saturation slider (as opposed to the colorController that only have an RGB slider)

    however I have not been able to get any callbacks when I interact with the 'Hue' slider.

    In the debug I get an "onAction" log with element "hue" but then it complains that there is no handler for "hue"

    I have tried MyChild:hue, MyChild:setHue, etc. but not got any callback. Have anyone tried com.fibaro.philipsHueLight and manage to get it to work?

    For com.fibaro.colorController I get callbacks on MyChild:setColor etc so that one works well.

     

     

    Ok, here is a new version of my adventure with Hue child devices

    Please login or register to see this attachment.

     v. 0.4

    I leverage the child UI to have some pretty color sliders - however, it's also limited because of what's visible in a child UI - no extra buttons etc.

    It supports

    - lights - Extended color light, color light, dimmable light

    - sensors (switch, temp, light, motion)

    - groups (actually rooms) -- on/off and dim

    - and experimental support for CLIP sensors. I implemented it because I hoped to use the sensors for IFTTT but then found out that IFTTT doesn't support Hue sensors 😣. I guess they can be used for Hue rules or something...

    - There is an authentication button that fetches the user credential from the bridge when he bridge button been pressed.

    The quickAppVariable 'Hue_IP' needs to be setup by hand.

    You need one QA per bridge.

     

    The child QAs created try to adhere to all rules to be behave as real devices and be usable from block scenes etc.

    Every child device supports fibaro.call(<childDeviceId>,"setHueParameters",<properties>)

    where properties is a table of Hue properties sent to the Hue device, ex {on=true, bri=155}

    Link to post
    Share on other sites
  • Topic Author
  • 48 minutes ago, jgab said:

     

    Ok, here is a new version of my adventure with Hue child devices

    Please login or register to see this attachment.

     v. 0.4

    I leverage the child UI to have some pretty color sliders - however, it's also limited because of what's visible in a child UI - no extra buttons etc.

    It supports

    - lights - Extended color light, color light, dimmable light

    - sensors (switch, temp, light, motion)

    - groups (actually rooms) -- on/off and dim

    - and experimental support for CLIP sensors. I implemented it because I hoped to use the sensors for IFTTT but then found out that IFTTT doesn't support Hue sensors 😣. I guess they can be used for Hue rules or something...

    - There is an authentication button that fetches the user credential from the bridge when he bridge button been pressed.

    The quickAppVariable 'Hue_IP' needs to be setup by hand.

    You need one QA per bridge.

     

    The child QAs created try to adhere to all rules to be behave as real devices and be usable from block scenes etc.

    Every child device supports fibaro.call(<childDeviceId>,"setHueParameters",<properties>)

    where properties is a table of Hue properties sent to the Hue device, ex {on=true, bri=155}

     

    It turns out that lights are mapped to 'com.fibaro.colorController' show up in the app.

    Unfortunately I have mapped 'Extended color light' too 'com.fibaro.philipsHueLight' which have cool hue and saturation slides. Unfortunately these do not turn up in the app.

    In the beginning of the QA code you can remap  'Extended color light' to 'com.fibaro.colorController' (like 'Coloraturas light' has) and regenerate the lights and they will show in the app.

    There seems to be some issues with updating the states of the lights in the app but the buttons seems to work.

     

    Link to post
    Share on other sites
    4 hours ago, jgab said:

     

    It turns out that lights are mapped to 'com.fibaro.colorController' show up in the app.

    Unfortunately I have mapped 'Extended color light' too 'com.fibaro.philipsHueLight' which have cool hue and saturation slides. Unfortunately these do not turn up in the app.

    In the beginning of the QA code you can remap  'Extended color light' to 'com.fibaro.colorController' (like 'Coloraturas light' has) and regenerate the lights and they will show in the app.

    There seems to be some issues with updating the states of the lights in the app but the buttons seems to work.

     


    What is ProxyIP ?, it needs to be changed?

    Link to post
    Share on other sites
  • Topic Author
  • 5 minutes ago, Freddan67 said:


    What is ProxyIP ?, it needs to be changed?

    Sorry, old debug variable - you can ignore or remove.

    Link to post
    Share on other sites
    10 minutes ago, jgab said:

    Sorry, old debug variable - you can ignore or remove.

    The lamps are turned on and off as they should, but they do not change the status from off to on and vice versa. Do you know what it can be? Sensors etc. work without blame

    Link to post
    Share on other sites
  • Topic Author
  • 1 hour ago, Freddan67 said:

    The lamps are turned on and off as they should, but they do not change the status from off to on and vice versa. Do you know what it can be? Sensors etc. work without blame

    In the app or the web GUI? 

    Link to post
    Share on other sites
  • Topic Author
  • 28 minutes ago, Freddan67 said:

    Both

    What kind of lamp? Extended, color, or dimmer?

    Link to post
    Share on other sites
    42 minutes ago, jgab said:

    What kind of lamp? Extended, color, or dimmer?

    Extended and color what I remember now. I try to reset my hub to see so nothing is wrong with me

    Link to post
    Share on other sites
  • Topic Author
  • 11 hours ago, Freddan67 said:

    Extended and color what I remember now. I try to reset my hub to see so nothing is wrong with me

    On my machine (Mac/Safari) they behave correct (both in "device list view" and "House overview view"). On the web UI the on/off buttons on devices that are mapped to com.fibaro.philipsHueLight have ugly buttons that don't show state in the UI, only the color ring shifts to greys when it's off. All other lights in the web UI has on/off buttons where the button selected turns blue. And they all work for me. Disclaimer, I don't have any lights of type "Color light' but when I map my "Extended color lights" to the same class they behave well.

     

    In the app it's a different story,  it seems like on/off is not synced well for any light - all my lamps start off as ON even though they are off.

     

    Most children UI elements are controlled by setting properties, self:updateProperty('value',..) etc. So there is not much else to do.

    The com.fibaro.philipsHueLight needs some trickery (to catch UI events) and requires to update some view elements, self.updateView('hue',...) etc, but it seems to work quite well.

     

    Edited by jgab
    Link to post
    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...