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 Scenes (not QA) - fibaro:args - how?


afendikov

Recommended Posts

Hi All,

 

Please guide me to right way to get args in scene on HC3

 

HC2 code to get scene args was:

    local args = fibaro:args()
 

on HC3 it not working now :(

 

Tried:

 

    local args = fibaro.args()    -> got error:  attempt to call a nil value (field 'args')
    local args = fibaro:args().   -> got error: attempt to call a nil value (method 'args')

 

LUA editor don't show any functions containing "args".... 

 

Help, please...

 

Thanks

 

  • Thanks 1
Link to comment
Share on other sites

Is not yet available at the moment

Link to comment
Share on other sites

  • 9 months later...

Is this still not possible?
A lot of my HC2 scenes use arguments to pass from one to another scene.
Is there an alternative?

Link to comment
Share on other sites

2 hours ago, SDeath said:

Is this still not possible?
A lot of my HC2 scenes use arguments to pass from one to another scene.
Is there an alternative?

The alternative is to write the scenes as QAs.

If the scene was a "shared function" like Logging scene or Message scene it is best replaced by a QA.

QAs can react to fibaro.call(<QA_ID>,<action>,<args...>) so it makes them very convenient to carry out shared functionality.

If you scene also triggered on devices etc it's a bit more work in a QA, but there are lots of examples in the forum how to poll for events within a QA.

The other problem is that QA's can't return values (fibaro.call doesn't return values), but that was kind of a problem with scenes to. However there are ways around that too with some coding,

  • Like 1
Link to comment
Share on other sites

So why does that work from another QA and not from a scene?
The arguments don't get passed on, but the QA method gets called, just the arguments are empty.

Link to comment
Share on other sites

4 hours ago, SDeath said:

So why does that work from another QA and not from a scene?
The arguments don't get passed on, but the QA method gets called, just the arguments are empty.

It should work. How does your call look like?

(There are some strange marshaling going on for some types but there are ways around that too...)

Link to comment
Share on other sites

5 hours ago, jgab said:

It should work. How does your call look like?

(There are some strange marshaling going on for some types but there are ways around that too...)

QA device type is generic.
The same as in my other QA call:

Please login or register to see this code.

 

And in the QA the method looks like

Please login or register to see this code.

 

Edited by SDeath
Link to comment
Share on other sites

17 minutes ago, SDeath said:

The same as in my other QA call:

Please login or register to see this code.

 

And in the QA the method looks like

Please login or register to see this code.

 

 

Well, that's the kind of string arguments you can't send. The way they encode the api.call from the scene to the QA makes them interpret them as key/values of the api.call...

The QA implementation of fibaro.call is better (don't ask me why they have different implementations)

The way around it is probably to url encode the string. Unfortunately urlencode is not built-in...

Please login or register to see this code.

 

on the other hand I can think that it's strange that the caller of Pushoverleaf needs to put together the url to pushover as the argument.

Alternatively create the url in the QA

 

Please login or register to see this code.

 

 
  • Like 1
Link to comment
Share on other sites

5 minutes ago, jgab said:

 

Well, that's the kind of string arguments you can't send. The way they encode the api.call from the scene to the QA makes them interpret them as key/values of the api.call...

The QA implementation of fibaro.call is better (don't ask me why they have different implementations)

The way around it is probably to url encode the string. Unfortunately urlencode is not built-in...

Please login or register to see this code.

 

on the other hand I can think that it's strange that the caller of Pushoverleaf needs to put together the url to pushover as the argument.

Alternatively create the url in the QA

 

Please login or register to see this code.

 

 

 

Yes you are correct, I should put the link together in the QA, I will change the code, it looks cleaner.
Thanks for your help!

Link to comment
Share on other sites

 

Quote

Yes you are correct, I should put the link together in the QA, I will change the code, it looks cleaner.
Thanks for your help!

 

Works great!

Link to comment
Share on other sites

...but it is an issue that they fail encoding the parameters correctly from the scene's implementation. If you are unlucky and an argument string has the wrong format you get unexplainable bugs...

Link to comment
Share on other sites

6 minutes ago, jgab said:

...but it is an issue that they fail encoding the parameters correctly from the scene's implementation. If you are unlucky and an argument string has the wrong format you get unexplainable bugs...

Yes true because I saw no error in the LUA itself, just the response from the Pushover API that there was no message.

Link to comment
Share on other sites

  • 2 years later...
On 5/17/2020 at 12:43 AM, afendikov said:

Tried:

 

    local args = fibaro.args()    -> got error:  attempt to call a nil value (field 'args')
    local args = fibaro:args().   -> got error: attempt to call a nil value (method 'args')

 

LUA editor don't show any functions containing "args".... 

 

After more than 3 years still not available. Lame Fibaro! :-(

 

Link to comment
Share on other sites

1 hour ago, Sankotronic said:

After more than 3 years still not available. Lame Fibaro! :-(

You can send customEvents, but they don't carry any arguments, so you need a lot... :-) 

Seriously, Scenes on the HC3 are useless for serious stuff - QAs have taken over that role - and you get (at least one way) function calls to declared QuickApp functions.

The triggers you get in Scenes are easily implemented in QAs and you get much more flexibility (you can trigger on more types of events).

You can have one QA that collects events/triggers and send to your other QAs for efficiency. 

Scenes seems to be for simple no-code integrators...

 

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

47 minutes ago, jgab said:

The triggers you get in Scenes are easily implemented in QAs and you get much more flexibility (you can trigger on more types of events).

You can have one QA that collects events/triggers and send to your other QAs for efficiency.

 

Hi @jgab ,

 

Thank you for the tip! Last few days I was busy comparing HC2 and HC3 and how much effort and time I will need to invest to move my UHAS to HC3. At this point it seems lots of time and effort. Also, I fear that at some point of development Fibaro will do some drastic change that will require to do few steps back and already existing code rewrite to either make it working or to get advantage of those changes. Provided manuals are maybe OK for making some simple code and not for advanced developers. Not to mention, that probably many things are not even mentioned in those manuals and will depend on on yours and some other gurus findings to be able to do some advanced programming. History repeats itself and I'm still not sure that I want to do it all over again.

 

 

Link to comment
Share on other sites

4 minutes ago, Sankotronic said:

 

Hi @jgab ,

 

Thank you for the tip! Last few days I was busy comparing HC2 and HC3 and how much effort and time I will need to invest to move my UHAS to HC3. At this point it seems lots of time and effort. Also, I fear that at some point of development Fibaro will do some drastic change that will require to do few steps back and already existing code rewrite to either make it working or to get advantage of those changes. Provided manuals are maybe OK for making some simple code and not for advanced developers. Not to mention, that probably many things are not even mentioned in those manuals and will depend on on yours and some other gurus findings to be able to do some advanced programming. History repeats itself and I'm still not sure that I want to do it all over again.

 

 

So I moved ER3 from HC2 to ER4 on HC3, ~4000 lines of code and it was straight forward to move most of the stuff. On the HC2 I had to do some acrobatics to get triggers without restarting the scene, but that is of course trivial on the HC3 with QAs. I believe your biggest hurdle will be the QA UIs that you obviously spent a lot of time on with the HC2 VDs. The binding of functionality to UI elements are of course different for QAs vs VDs. 

I wouldn't worry about Fibaro making changes - they move slower than tectonic plates...

There are advantages and I find the HC3/QA environment a huge improvement over HC2 (but not perfect  - seems like Fibaro always stops before perfect)

- you can have lua files you reuse between QAs, and there is more or less efficient ways to call functions between QAs.

 

...if you embark on this journey I would recommend to develop the QAs offline, using something like ZeroBraneStudio and TQAE or vscode and fibemu (what I'm using currently).

Gives you debugging, testing multiple QAs simultaneously for testing interactions, and a build and deploy system for multi-file QAs (makes it easy to build up your own shared libraries).

It will cut your development time with more than 50%...

 

...just saying...

  • Like 2
Link to comment
Share on other sites

Hi @jgab ,

 

Thanks for encouragement and for sharing your knowledge here on forum. 🙏 Will start with learning and planing.

Link to comment
Share on other sites

So, I took a look at a VD (was a long time ago) and it was your LIFX_Color_VD_v1.4.vfib...

Besides your, not so small, task to migrate to HC3, this may be of interests to others moving VDs

 

It's doable to auto convert the UI layout.

I wrote a small program that took the fib and created a QuickApp file with the headers for my fibemu emulator 

Please login or register to see this spoiler.

The --%u=... declares the UI element and builds the correct structure for a QuickApps viewLayout incl. Lua handlers.

The mainLoop is here just included in the QuickApp:onInit() function and some simple transformation of the code us done ex. fibaro:* to fibaro.*

Here I also ignore the lua code for the UI elements (buttons and sliders). One approach is to stuff them in a separate QA file and create QuickApp:<btn/sliders> functions to call them.

 

However, taking a step back one realises that the code needs some refactoring.

  • There are a lot of library/common functions that should be put in a separate QA file and reused between QAs
  • Most of mainLoop should not be put inside QuickApp:onInit() but outside. 
    :onInit() should be just initialisation and maybe a setInterval to run a periodic loop
  • The code for handlers for the UI elements could be reduced as they don't need to include a lot of support functions and could focus on their tasks. Probably would not need to be put in separate QA files, but kept as QuickApp:* functions in the main QA file.

Probably, some more steps could be automated by the transformation program, but ultimately their will be a lot of manual tweaking to make it QuickAppy...

  • Like 1
Link to comment
Share on other sites

Hi @jgab ,

 

Thanks for trying. I think that converting HC2 virtual devices to HC3 quick apps is not easy, specially because VD's are not that advanced as QD. You can use my Sonos API Player VD and Sonos API Player QA and see all the differences. On HC2 I was able to use predefined global variables to store data tables while on HC3 predefined variables can't hold any other data but the one that is initially predefined. That means that code that takes care for global variables must be changed.

 

Another thing that I need is to be able to store my own role types to QD so that they can find each other including scenes. On HC2 I was able to use scene json table to store this in "properties" as a table together with scene version and run type. For virtual devices I had to use global variable. Fibaro provided Role is just not sufficient for me since there are some combinations of roles that can't be covered with their solution. I'm now checking possibilities on HC3 with swagger to see if situation is a bit better with QD's and scenes.

 

Also, there are some solutions on HC2 that required combination of virtual devices and scenes while on HC3 those solutions can be achieved solely with QD's. One example is Philips HUE with new API2 which requires HTTPS calls so all communication between HC2 and Philips HUE bridge I had to move to scene, but on HC3 this can be done with QD. Problem that I'm facing with HC3 and QD child devices are that child devices are rudimentary which is not good enough from my perspective. This is because I want to have possibility to select and activate HUE light scenes at least on group of lights as I have made it for HC2 UHAS. I need that so that users can adjust lighting for specific situation and then save that setting to be used in light automation. This means that When user add QD children for HUE grouped lights then there should be besides default buttons and sliders also buttons and labels to select desired HUE light scene and activation.

 

But of course you know all the above. :-) I think I will manage, specially thanks to your effort and knowledge shared here on forum. Without your help and your posts here on forum everything would be much more difficult. Eternal thanks and respect goes to you Jan! 🙏

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