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
Question
jgab 2,042
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...
Link to comment
Share on other sites
Top Posters For This Question
19
6
4
3
Popular Days
Feb 9
17
Feb 10
9
Feb 10
5
Feb 8
4
Top Posters For This Question
jgab 19 posts
petrkl12 6 posts
petergebruers 4 posts
tcviper 3 posts
Popular Days
Feb 9 2020
17 posts
Feb 10 2020
9 posts
Feb 10 2021
5 posts
Feb 8 2020
4 posts
Popular Posts
jgab
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 m
tinman
just think different, heating/cooling is not via each every thermostate but via each every zone: - create as much you need, climate zones, it can be more than one per room - add to these zon
petergebruers
First devices ship with 5.020.60 to be exact. Yes, they've promised that. Yes, IMHO, it is best to think of it this way "I am a power user on HC2" ------->
47 answers to this question
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.