Remote configuration on auto:cerr2 example

[Łukasz997 117]

This is addition to the topic of

Please login or register to see this link.

, explaining mentioned "secret" function of the program
But it also touches on the issue of quickapp configuration, which may interest many people.

 

Complex quickapps require the ability to set operating parameters without interfering with the code (preferences). Preferences can be introduced into the UI. Developers show extraordinary ingenuity to overcome the limitations of the interface. But still, not everything can be achieved. Moreover, preferences are always visible and clutter the UI. One solution is local and global variables. Local variables are not visible between quickapps. Globals, on the other hand, when used too often, become a central trash bin for settings of various scripts. Both types are very difficult to fill with more complex structured data.

 

I come to the conclusion that sometimes the best method is simply to edit the code and alter the settings there. This involves restarting the quickapp and certain risks. How to remedy that? In my idea, the event mechanism comes to the rescue. Here is an illustration of this solution - a quickapp for sending filters to auto::cerr2.

 

You can create filters, select them in a drop-down menu (one or more at a time), and send them to auto::cerr2 with the send button. Creating or changing a filter indeed consists in editing the code (conveniently), but we do not touch the main program. I tested sending up to ~3000 characters and it works (39 filters at once). Besides, the message has a checksum, in case it gets cut.

 

In a::c2 we see a message that remote filters arrives, confirm it with the [Toggle filters] button, and after correct compilation the filters are appended to the built-in ones (available in the menu). Filters can be loaded repeatedly - they will always be appended to the current ones. By pressing ↻F you can delete the loaded filters, without deleting the stored messages.

 

This is just an example. It separates the program’s configuration from the program itself into another quickapp, which has many advantages. Of course, other program parameters could also be changed this way. 

 

I have an idea for a universal configuration framework, containing code on both the sender and receiver side. With time and motivation, I will try to implement it.

Please login or register to see this attachment.

[jgab 2,647]

It's also a god idea to separate code from config if the QA is encrypted.

 

[Brors94 115]

2 hours ago, Łukasz997 said:

 

 

Complex quickapps require the ability to set operating parameters without interfering with the code (preferences). Preferences can be introduced into the UI. Developers show extraordinary ingenuity to overcome the limitations of the interface. But still, not everything can be achieved. Moreover, preferences are always visible and clutter the UI. One solution is local and global variables. Local variables are not visible between quickapps. Globals, on the other hand, when used too often, become a central trash bin for settings of various scripts. Both types are very difficult to fill with more complex structured data.

 

I

Please login or register to see this attachment.

I often use the UI on my QA to set preferences/settings  
But I have to admit it gets messi in the UI, But we could also solve this by show/hiding alot of settings with a "Setup toggle on/off" button on the bottom the QA 😄 

It is just another thing to add to all the QA's 😅😂

 

 

[Sankotronic 2,370]

3 hours ago, Łukasz997 said:

One solution is local and global variables. Local variables are not visible between quickapps.

Hi @Łukasz997,

 

That is not true. My quick apps can, not only read another QA local variable, but also change its value in any format: number, string or table. Since my Quick apps are also aware of the existence of other quick apps so can adjust behavior and actions.

3 hours ago, Łukasz997 said:

Globals, on the other hand, when used too often, become a central trash bin for settings of various scripts. Both types are very difficult to fill with more complex structured data.

 

Again not entirely true. All my quick apps are able to add, change, read and delete global variables as needed and again can store complex data in form of data tables.

 

Actually i think that the worst solution for most of the users is to do setup inside code since it does require from user to sit down by the computer using browser and of course learn syntax is it LUA, or some invented scripting language that is then interpreted after by developer code.

 

My goal with HC2 UHAS and now with Yubii UHAS is to simplify user setup as much as possible so that only very basic setup is done by e.g. quick app local variables during installation. Everything else must be possible to do with Yubii Home app comfortably sitting in sofa

 

[jgab 2,647]

Maybe we need a better terminology.

I suggest 

- Fibaro globals - the local variables we set in the general panel or fibaro.setGlobalVariable...

- QuickApp variables - variables set per QA in web UI or self:setVariable...

- Lua globals

- Lua locals

 

Designing a complex user configuration interface solely using the available UI elements from Fibaro demands—or is facilitated by—a masochistic inclination  

 

[Łukasz997 117]

I cannot compare my experience with yours. That is why it is difficult for me to engage in a debate. But I will keep my own opinion.
I meant that for the user it is difficult to "store complex data" into a QuickApp variable or Fibaro global (by typing it), not the QA itself.

 

1 godzinę temu, Sankotronic napisał:

Actually i think that the worst solution for most of the users is to do setup inside code

 

I look at it from my own perspective - I am my only "client" and it does not bother me. Having a smart home tends to require some basic tech literacy, and for many users this may not be an issue either.
If anyone uses my programs at all, they tend to be slightly more advanced users. Still, I believe that typing o.e. such a filter into QuickApp (enforces restart of QA) variable is more troublesome than doing it in the LUA editor.

I don’t know UHAS specifically, but I know it is a widely used program (I need to get familiar with it!). Another very reputable quickapp – EventRunner – as fas as I know it's “configured” inside the LUA editor? I hope that it can't be done other way...
Not everything can be achieved with the simplest methods, so I am exploring an alternative approach. 

[Sankotronic 2,370]

16 minutes ago, jgab said:

Designing a complex user configuration interface solely using the available UI elements from Fibaro demands—or is facilitated by—a masochistic inclination  

 

Like learning how to write dozen of rules and write them in the code is much better?  

[jgab 2,647]

we all have our vices… 😉