LUA scenes are worst on HC3(L) than on HC2! Why?

[Sankotronic 2,370]

Hello @m.roszak and Fibaro lovers,

 

I compared LUA scenes on HC3 and HC2 and find out that abilities were better on HC2.

 

Here is JSON response for one of my scenes on HC3:

Please login or register to see this spoiler.

 

What I'm missing in LUA scenes on HC3 and was there on HC2:

1. properties - it was really nice to use it on HC2 to store some information to easy find scene by e.g. role and module.
2. iconID - it was much easier to manipulate icons on HC2.
3. arguments - possibility to send some arguments to the scene when called to run.
4. categories - why use category ID instead of the category name same as on QA?
5. maxRunningInstances - why is not possible to setup this through GUI interface? I guess it can be changed with API call? What is the maximum of running instances?

 

 

Why are scenes on newer gateways HC3, HC3L etc. worst than on the HC2?

 

NOTE - this is not new topic, but is still interesting after 5 years of HC3(L) firmware development since there was no much improvement until this last beta.

 

Edited August 14, 2025 by Sankotronic
Just added spoiler for JSON code

[jgab 2,641]

1. There are documented 
fibaro.getSceneVariable(), fibaro.setSceneVariable()
Unfortunately, there is no REST API to call them, only builtin fibaro functions.

2. Well, can agree...

3. We use QuickApps for that. Scenes react to system sourceTriggers or customEvents. They can also read configs from global fibaro vars.  If we want to use them as services taking arguments, they should probably be QuickApps

4. Yes, there are a lot of inconsistencies. why does scenes have another json parser than quickapps etc...

5. A scene only run one instance at a time. Either they block new started scenes, or newly started scenes kill the running. No parallel execution of instances like we had on the HC2. So it's the restart property. maxRunningInstances must be a leftover?

Without being sure, the Lua scene options seems to be mainly to support the block scenes to have something to "translate" to. When the HC3 was launched a lot of lua functions were missing from scenes because they were not needed from block scenes I guess. Also the user unfriendly trigger condition(!)...
Then, when they had lua scene support they gave it to us - however, many advanced scenes we did on the HC2 can't be translated to the HC3 - scenes are much more basic here.
It's QuickApps that we should use to develop stuff for others. Scenes seems to be simple integration glue for the end users (Users can't even download/upload them, without the REST API). On the HC2 we had inferior Devices but they could show UIs, and more powerful Scenes that couldn't show UIs - on the HC3 we have QuickApps.

 

So for me, Scenes are basic automation integration glue for users.
Functionality developed for others should be delivered as QuickApps, and I make sure the QAs update properties or send customEvents so that Scenes can listen to them and use them for custom integration tasks. And most users will only use block scenes...

Edited August 14, 2025 by jgab