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


  • 1

HC3 coding - first impressions


jgab

Question

I have been playing around with the HC3 and tried to program some scenes/devices. This is my experience so far.

Disclaimer1: My review is based on the latest beta firmware, v5.020.xx, and there may be improvements coming before the ink in this post has dried.

disclaimer2: My personal preferences when it comes to API design and programming styles shines through in my review… others may have other preferences.

 

Scenes

They have changed quite a lot, some Lua functions and some fibaro* functions have disappeared -

Please login or register to see this link.

 

So scenes have a new way of declaring triggers. No more the Lua comment section in the top of the scene. Instead a separate section of the scene that contains a "Lua table" expression that checks various events/states. If the total expression is true, the action part of the scene is executed. Technically, the scene structure that you get from api.get("/scenes/<SceneID>").content returns a struct with two parts; a conditions part with the condition structure and an actions part with the Lua code that makes up the action part.

Is this an improvement? I don’t know - seasoned Lua programmers could make these tests in the Lua code previously anyway and without having been able to dig too deep into this there is usually some interesting trade-offs and subtle sources of errors/unintended consequences when doing these kind of trigger expressions when it comes to stateless and stateful events….

 

Is it easier for non-Lua programmers? You judge, here is a condition for a device and a time:

Please login or register to see this code.

(block scenes make use of the conditions support - but I'm not reviewing the block scenes as the implementation seem to be a bit unfinished in the current release)

 

Because scenes miss net.HTTPClient(), fibaro.getSourceTrigger(), fibaro.sleep(), os.time(), os.date(), clearTimeout() I haven’t played around so much with scenes, as some of my standard scenes were not portable without major rework.

Edit: The above functions are now part of scenes. Note that fibaro:getSourceTrigger() is now a variable, 'sourceTrigger'.

 

Noted though that they changed from fibaro:* to fibaro.* and some names have changed, like  fibaro:getGlobalValue has changed to fibaro.getGlobalVariable etc. deviceID can be a list, so fibaro.call({66,77},"turnOff") works.

 

Devices

This is a new animal and has received  most of my attention.

 

Devices you code yourself are called QuickApps.

 

When you create a new QuickApp device, you can choose what type of device it should be; binary switch, binary sensor, multilevel switch, temperature sensor etc. …and it will be treated as a “native” device of that type.

You can call fibaro.call(<myDeviceID>,”turnOn”) on a QuickApp device of type binary switch etc.

 

However, you are limited to the available types - more on that later.

 

To code a QuickApp device you now have QuickApp “class” that provides a some functions that makes up the Devices interface.

Please login or register to see this code.

Above is a simple binary switch you can turn on/off. :onInit() is called when the device is saved or restarted - good place to setup stuff or start loops (with setTimeout)

 

You extend the QuickApp class with methods being the actions that the device should accept. Here ‘turnOn’ and ’turnOff’.

 

It turns out that you can define

Please login or register to see this code.

and then from another scene/device call fibaro.call(<deviceID>,”doWhatever”,5,10)

and your function gets called. This is seriously cool as it means that we have a nice way to pass arguments between devices and from scenes to devices - something we didn’t have before.

The other cool thing is that the function is called in the same thread as is started with :onInit()…. This requires some effort from the design perspective (not like in the old scenes when just another instance was created).

This also means that

Please login or register to see this code.

will count up x every time fibaro.call(<deviceID>,”incX”) is called. We have stateful devices...

 

So, ‘QuickApp’ is a “class” that we can extends with some methods to handle actions on devices.

 

There are also possibilities to define handlers for the QDs UI elements (button etc).

If you have a button named ‘button1’ you can define

Please login or register to see this code.

and it will be called when the button is pressed (similar for sliders)

 

There maybe other QuickApp:* methods too but I haven’t discovered any more yet.

 

Then there is the self:* methods…

 

Inside the QuickApp:functions() there is 'self', a variable available with our QuickApps methods.

‘self’ is not the same as ‘QuickApp’ and should not be confused (however in some prototype based object implementations for Lua, the “class” and the “self” is the same object, so it can be confusing). QuickApp is the class, and 'self' is a variable holding our instance of that class.

 

I have found some useful methods.

Please login or register to see this code.

Note here that the UI that can be defined have the same buttons in sets of 1 - 5 buttons, slider, and static text - doesn’t seem to be any enhancements here. It may be extendable but I guess it needs to be supported in the mobile apps too.

 

Another improvement is that Devices have their own “global variables”. In practice a property table associated with the Device structure. We have functions like:

Please login or register to see this code.

 

We can do setVariable/getVariable for variables belonging to our device. They survive restarts and they are also saved when we download and distribute with a QuickApp VD file. In that way we can see them as a generalisation of the IP: and Port fields in old VDs - Here we can define them ourselves and use them as initialisation parameters for QDs.

 

There may be more self:* functions but I haven’t seen them so far.

 

Besides this we have almost the same Lua and fibaro functions as we had in scenes in the past. No synchronous HTTP functions anymore - only the asynchronous net.HTTPClient().

 

The api.get(“/refreshState?<lastID>”) api seems a little more extensive - it seems to report more types of events - like global variables changing states.

 

And there is a new concept <CustomEvents>.

They are of type {name = <string>, userDescription=<string>}

They can be defined with api.post("/customEvents",{name=name,userDescription=descr})

and “emitted” with api.post("/customEvents/"..name)

I think there is a fibaro.emitCustomEvent(<name>) function available too.

 

Scenes can probably trigger on them and they show up in api.get(“/refreshState?<lastID>”)

 

Because events are “statically” defined - name and user description - you have to be a bit creative with naming schemas to use them as general message events - but it’s doable. I will come back on this topic and why you would like to have that... I have played with them to implement a kind of broadcast function...

 

Summary

So, all-in-all, QDs opens up for some new interesting programming paradigms.

- What I miss is a more extensive network library to easier integrate with external systems/devices. Nothing much have happened with the net.HTTPClient() library in 7 years…

- I would have liked  more UI elements and layout options than the buttons and sliders we have had for some years now.

- I would have liked Lua metatables, loadstring, and coroutines too - it’s 2020 and the security issues should be solvable (there are so many other more low hanging security risks anyway)

- Possibility to enable remote Lua debugging - using

Please login or register to see this link.

?

- Now, some more advanced programming has to be realised as QDs, and thus need to have device types like binary switch. For some code like schedulers or other helper scenes it doesn't make sense to squeeze it into a device model - they are not really devices. At least an 'other' device type would be nice to have.

 

This was a first impression - some good news and some stuff that could Improve.

Some small issues I have been wrestling with:

- There are some glitches in the code editors and sometimes the code for a device just stops working and the only solutions is to remove the device definition and create a new.

- Hit and miss what line an error is reported on...

- Some mistakes just hangs/give no visible errors - Ex. by mistake calling QuickApp:debug("FOO")

- api.get(“/refreshState?<lastID>”) seems to hang for ~30s if there is no new event available, instead of immediately returning an empty event/change table.

- net.HTTPClient() seems to have an issue with ‘POST’ command and json payloads in many cases as neither the success or the error handler seems to get called (no problem with GET commands) Turned out that I needed to add a 'Connection: keep-alive' header when doing a POST to get the result back - never needed that in the past...

 

However, I expect these to be fixed over time… and people start coding will report in more bugs...

 

Disclaimer 3: I may have missed stuff that are available and I haven’t been able to discover  :-) 

 

So, have anyone else discovered some new programming concepts on the HC3? or additional methods/tricks available in QuickApps ?

Meanwhile, I will update this thread with new stuff as I continue to make discoveries in this undocumented landscape... ;-) 

 

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

Recommended Posts

  • 0

@jgab Thanks, it works ? I have added also other settings (Accept, Connection etc.) to header based on Chrome

Link to comment
Share on other sites

  • 0

Let's hope 

Please login or register to see this link.

 will also be able to get it to work with HC3 :)

Link to comment
Share on other sites

  • 0
  • Inquirer
  • 4 minutes ago, tcviper said:

    Let's hope 

    Please login or register to see this link.

     will also be able to get it to work with HC3 :)

     

    It shouldn't be difficult - most of the rest APIs look more or less the same. There may even be some new feature in the HC3 that could be leveraged...

    Link to comment
    Share on other sites

    • 0

    Jan,

    question just off curiousity can we export our devices on a wau and import in HC3 or do we have to learn the devices on the HC3?

    Link to comment
    Share on other sites

    • 0

    @Sjakie It's not possible to export virtual device and import it to HC3 ☹️ Very diffirent logic and also commands

     

    @jgab Do you know how to change value for label? I have tried: self:updateView("lblTest", "text", "Test") but it doesn't work ...
     

    Edited by petrkl12
    Link to comment
    Share on other sites

    • 0
  • Inquirer
  • 19 hours ago, jgab said:

     

    It shouldn't be difficult - most of the rest APIs look more or less the same. There may even be some new feature in the HC3 that could be leveraged...

     

    It's common that external system polls the HCx to get state changes. I've seen nodered systems and the home bridge does it.

    It generates some unnecessary traffic and load on the HCx. It would be better to have something like webhooks...

     

    One could now (and maybe in the past too) write a "webhook" type of devices on the HC3

    Please login or register to see this code.

    The external client a post /devices/{deviceID}/action/registerForEvents {args:["<url>]}

    and the device will start to post events to the url

    if the client doesn't respond it's just removed from the subscribers and the client needs to re-register

    A more advanced version would allow for defining event filters etc.

    Simple...

    19 hours ago, petrkl12 said:

    @jgab Do you know how to change value for label? I have tried: self:updateView("lblTest", "text", "Test") but it doesn't work ...

     

    I have succeeded with self:updateView("label","text","Test").

    You have to be careful that you use the self you get from inside QuickApp

    Ex.

    Please login or register to see this code.

    Oh, and you have to switch the "Preview mode" for the Device UI to blue...

    Edited by jgab
    Link to comment
    Share on other sites

    • 0
  • Inquirer
  • 19 minutes ago, petrkl12 said:

    @Sjakie It's not possible to export virtual device and import it to HC3 ☹️ Very diffirent logic and also commands

     

    @jgab Do you know how to change value for label? I have tried: self:updateView("lblTest", "text", "Test") but it doesn't work ...
     

     

    As @petrkl12 says, it's different. The save format is also very different. Also the http functions are the ones that used to be in scenes and the ones in the old VDs are gone. So http requests needs to be recoded.

    Link to comment
    Share on other sites

    • 0
    52 minutes ago, jgab said:

    I have succeeded with self:updateView("label","text","Test").

    You have to be careful that you use the self you get from inside QuickApp

    Ex.

    Please login or register to see this code.

    Oh, and you have to switch the "Preview mode" for the Device UI to blue...

     

    You're right - problem was in "Preview mode" ?

    Edited by petrkl12
    Link to comment
    Share on other sites

    • 0
    19 hours ago, jgab said:

     

    It shouldn't be difficult - most of the rest APIs look more or less the same. There may even be some new feature in the HC3 that could be leveraged...

     

    I dont have the skills nor time to get it to work in Homekit/Homebridge. If someone is willing to make it work, i would be willing to pay for it :) 

    Link to comment
    Share on other sites

    • 0
  • Inquirer
  • Reflection. 

    I've been running some complex lua code in a VD - single thread, no I/O (but exercising the LUA VM), and benchmarking it gives almost identical times on the HC2 and the HC3. Intel Atom Dual Core (1.6 GHz) vs. Quad-core Arm Cortex A53 (1.2 GHz). Do they 'nice' the scene/QD processes?

    However, I have to say that in general the HC3 feels snappier, calling APIs and starting scenes etc. In the past my strategy has been to concentrate as much of my home automation in a single scene (ER), but it may be smarter to start to split it up into many devices/scenes to exercise those cores... ;-) 

    Link to comment
    Share on other sites

    • 0
    8 minutes ago, jgab said:

    Intel Atom Dual Core (1.6 GHz) vs. Quad-core Arm Cortex A53 (1.2 GHz). Do they 'nice' the scene/QD processes?

    However, I have to say that in general the HC3 feels snappier, calling APIs and starting scenes etc.

    Makes sense to me, the single core CPU performance would not be significantly different. Not sure about memory bandwidth, might be 1 generation ahead so better match for 4 cores. Disk I/O may be a lot better, so database access and loading/writing stuff is sped up. Anyway, the hardware is not "miles ahead" of the competition (like when HC2 appeared on the marked, that was long ago!). HC3 is basically a kind of raspberry pi but nice package and nice radio's ;)

     

    Link to comment
    Share on other sites

    • 0

    Has anyone tried it yet with Satel alarm? :) Hope it's easy to make a scene to arm/disarm so you can use it with Siri and so on :)

    Link to comment
    Share on other sites

    • 0
    On 2/5/2020 at 12:04 AM, jgab said:

    Is it easier for non-Lua programmers? You judge, here is a condition for a device and a time:

    I don't think it easier... currently in Lua you cannot see what device's properties are...? and instead of Lua commands you need to memorize Fibaro's language in conditions, which gives no added value for Lua coding.

    For Lua programmers, it's an extra code typing. For example if I want to create a simple scene that turns On/Off lights according  to motion sensor.

    In conditions you need to include both sensor's states (true and false), and need to verify again the sensor state in Lua code to decide what to do (On or Off).

    Another way is to create endless number of scenes according to every state, which creates a huge issue when re-including device and need to go through all scenes to identify where you need to change device ID. At end you'll end up with hundred of scenes!!!

    By the way have found an interesting way to trigger scene for devices with power measurements, define "stupid" condition of power value to get scene triggered. (Didn't find any other way to trigger scene with any power value)

    I don't think this is a "smart" design that you need to cheat conditions to trigger scene.

     

    On 2/5/2020 at 12:04 AM, jgab said:

    This is a new animal and has received  most of my attention.

    Devices you code yourself are called QuickApps.

    I've played a lot with this animal... and have found nothing interesting or cool about this feature. May be it very exciting to add another virtual switch to turn On/Off, but didn't find any reason to do it. We have it in VD with buttons... Now buttons!!! Again extra code required. When you create a button and write a code in button control, this code is useless and couldn't be called from any where. As you mentioned you need to create QuiclApp function with the same code as in button control and you need to do it for every button and slider... why? (off course you can call QuickApp function in button control, but it also extra code). Regarding option to call QuickApp with parameters from anywhere, we have it in HC2. Create a scene and call it from anywhere with parameters also.

     

    Currently Lua scene has reduced abilities comparing to HC2 and no way to import any code from HC2.

    But may be I'm missing something or next FW release will reveal more useful functionalities.

    Edited by cag014
    Link to comment
    Share on other sites

    • 0
  • Inquirer
  • 2 minutes ago, cag014 said:

    I don't think it easier... currently in Lua you cannot see what device's properties are...? and instead of Lua commands you need to memorize Fibaro's language in conditions.

    For Lua programmers, it's an extra code typing. For example if I want to create a simple scene that turns On/Off lights according  to motion sensor.

    In conditions you need to include both sensor's states (true and false), and need to verify again the sensor state in Lua to decide what to do (On or Off).

    Another way is to create endless number of scenes according to every state, which creates a huge issue when re-including device and to go through all scenes to identify where I need to change device ID.

    I tend to agree with you, see my later post with a more in-depth look at conditions.

     

    2 minutes ago, cag014 said:

     

    I've played a lot with this animal... and have found nothing interesting or cool about this feature. May be it very exciting to add another virtual switch to turn On/Off, but didn't find any reason to do it. We have it in VD with buttons... Now buttons!!! Again extra code required. When you create a button and write a code in button control, this code is useless and couldn't be called from any where. As you mentioned you need to create QuiclApp function with the same code as in button control and you need to do it for every button and slider... why? (off course you can use QuickApp in button control, but it also extra code).

    Well, the code in a button share the _G with the main VD environment (it seems it's loaded every time with something like 'loadstring'.

    Could be used for something... but I agree that the code in the button is useless as the main VDs QuickApp functions will be called (or you could pick them up with /refreshStates) . Myself, I think it's better to keep the code together in one place and not distribute it in various UI elements. (It's also easy to autogenerate the callback function(s)...)

     

    2 minutes ago, cag014 said:

    Regarding option to call QuickApp with parameters from anywhere, we have it in HC2. Create a scene and call it from anywhere with parameters also.

    But it's not the same. The QuickApp call is received in the same thread as the main VD is running(!) This opens up for some interesting stuff that I will come back on...

     

    2 minutes ago, cag014 said:

    Currently Lua scene has reduced abilities comparing to HC2 and no way to import any code from HC2.

    Yes that sucks - some new functions will come, but I hope they reintroduce the net.* functions to scenes too....

     

    2 minutes ago, cag014 said:

    But may be I'm missing something or next FW release will reveal more useful functionality.

    fingers crossed.

    Link to comment
    Share on other sites

    • 0
    18 minutes ago, jgab said:

    fingers crossed.

    Finger crossed (hands and legs)

    Link to comment
    Share on other sites

    • 0
  • Inquirer
  • 2 hours ago, AR27690 said:

    Any  suggestions if it worth to order HC3?

     

    The verdict is still out there... However, I'm a nerd so any hardware is a temptation for me ;-) 

    Link to comment
    Share on other sites

    • 0
  • Inquirer
  • So, in my first notes on coding for the HC3 I expressed my doubts on the "conditions" model for scenes.

     

    A couple of things makes it very confusing.

    - first the isTrigger property that seems easy to grasp - but is tricky...

    - secondly the date "cron" expression that can be used in comparisons (match> etc). (I ranted more on this <

    Please login or register to see this link.

    >)

    Take this expression

    Please login or register to see this code.

    The condition should trigger when the Variable Test is set to X3 or every minute after the sunset.

     

    If Test is set the X3 it triggers every minute, even before sunset - which is kind of ...un-intuitively

     

    Why does it trigger?

    Because the only way to know if a cron expression is true (in general) you need run it every minute to test it.

    If you set a cron expression's isTrigger to true they will test the cron expression every minute and if true test the whole condition if it's true - if you have an "any" that is always true (like the global in the example) it will trigger the actions...

    What they can do is test the whole "all" expression the date test is part of... but I suspect there are more issues buried here...

    Also, >,< comparisons for cron expressions doesn't make sense. There are some easy cases like {"15","10","*","*","*","'*"} but why not have a date property that looks like a time instead? Like {type='date', property="10:15", operator='=='} ?

    Then we all would know what {type='date', property="time", value "10:15", operator=">=''} means.

    I have still no clue what {type='date', property="cron", operator="match>'', value = {"*", "10,15", "*", "3,5", "*"} means...

     

    Edited by jgab
    Link to comment
    Share on other sites

    • 0
    On 2/10/2020 at 6:44 PM, AR27690 said:

    Any  suggestions if it worth to order HC3?

     

    If you are not planning any changes in you home automation, and are not in a hurry to learn the new ways in HC2 - then my advise is to wait. There's a lot that is not implemented and working yet, 433 and ZigBee is not activated yet, LUA functions missing and the UI is buggy.

     

    On the other hand, if you know you will move to HC3 eventually, and you can live with the above missing functions, and you are interested to learn the new stuff in HC3 - then you could order it. You can still use your HC2 for important stuff, while you can migrate some devices or just start to learn Quick Apps on the HC3. This is what I did.

    Link to comment
    Share on other sites

    • 0
  • Inquirer
  • On 2/20/2020 at 1:30 PM, robw said:

    On the other hand, if you know you will move to HC3 eventually, and you can live with the above missing functions, and you are interested to learn the new stuff in HC3 - then you could order it. You can still use your HC2 for important stuff, while you can migrate some devices or just start to learn Quick Apps on the HC3. This is what I did.

    So, I'm still using my HC2 to run the house... and I use the HC3 to play with and learn.

    I have created QD proxies for some of the devices connected to the HC2 so I can use them as devices on the HC3 too. It allows me to have some devices to "play with" on the HC3 while they still do their daily task directed by the HC2.

     

     

    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
    Answer this question...

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