Why is device property "mainFunction" removed????​

[Sankotronic 2,370]

Hi @m.roszak,

 

Until this update I was able to change or add device property "mainFunction", but not anymore. New quick app of type "com.fibaro.deviceController" refuses it. Why? I just added following quick apps types:

 

com.fibaro.genericDevice

com.fibaro.deviceController

com.fibaro.player

com.fibaro.weather

com.fibaro.colorController

 

and they are all missing property "mainFunction" and can't be added. Note that same type of devices added prior to this update have this property.

 

So history repeats itself. Same was when I was developing UHAS for HC2. With almost every stable version I had to go back to the beginning and rewrite my code because somebody decided to remove or change something. It seems that nothing in your world of automation is not definite and there is no guarantee that will work after next update. Very disappointing 😪😪😪😪

 

[jgab 2,642]

Haven't 'mainFunction' been gone for years on the HC3? QAs started to store files separately since...2020?

[Sankotronic 2,370]

2 hours ago, jgab said:

Haven't 'mainFunction' been gone for years on the HC3? QAs started to store files separately since...2020?

You are right. I just checked and all my quick apps that have "mainFunction" property were made some time ago or just imported lately and that is why I noticed now when I start with completely new quick apps that is missing.  

 

 

 

 

[m.roszak 763]

Yep, it was removed few years back for technical reasons - all was in the changelog back then

[Sankotronic 2,370]

Thanks @m.roszak!

 

The idea behind my question is to have 3 properties that I can use to filter quick apps and easy find the one needed.

I use properties:

1. "manufacturer" to filter all quick apps that belong to UHAS.
2. "model" to find group or one quick app that does specific actions. As example, all quick apps that send notifications when started they look for Advanced Notification Center (ALC) quick app and if found then use it to send notifications. if not found then use native Fibaro e-mail and push notifications. This is also good if any of the quick apps need to be reinstalled and change their ID because after restarting they will find freshly installed ANC and continue use it  This also greatly reduces amount of settings that user need to do to make system working.
3. need one more property which will hold name of the UHAS module so that UHAS Control center can control/stop/start only quick apps belonging to that module. Any suggestions? For now I will use "userDescription" because if user change it, quick app is restarted and can revert to what I need.

It would be nice if scenes have similar possibility. For example on HC2 scenes has "properties" where I was able to store all 3 properties in table format and therefore easily find and even change the scene code if needed.

 

Unfortunately on HC3 scenes do not have anything similar. I know that almost everything is doable with quick apps and there is very little need for scenes, but still scenes can be handy to do some work. Any chance your team can add this one "properties" to scenes?  

 

I believe that it is possible to make automation on Fibaro gateways that will be aware of all installed devices and scenes and therefore do most of the settings without needing user to hassle with various devices and scenes IDs. Only what user will have to do is customize automation using mobile app and sitting comfortably on the sofa  

 

I almost succeeded to achieve it with UHAS for HC2. I believe with HC3 can do it even better, but will need some developer manuals and help. Is there a chance that you will update some developer documentation? Possibly with examples. Thanks!

[jgab 2,642]

properties.quickAppUuid

properties.buildNumber

 

properties.userDescription is easily edited/changed by the user, using the web UI, and should probably be avoided and let the user use it as a way to add notes to a QA.

buildNumber is maybe more proper for versions etc.

 

I use properties.quickAppUuid to identify my QAs, for updating etc. Long unique string, instead of some model text...

Unfortunately, most of these props, like quickAppUuid is not saved with the fqa so the prop needs to be setup when QA starts.

Edited October 13, 2025 by jgab

[Sankotronic 2,370]

Thanks @jgab!

 

So, I can use properties.quickAppUuid. It does not need to be saved with fqa since it is in my case always checked and setup during quick app start up.

It is definitely better than user description, thanks! 👍