Fibaro HC3 and QuickApp's

I’m sorry there was a misunderstanding here.
I had not yet added the variable Departure_Time.
But if the variable could be used in HR, I could easily add it.

But now I have added a variable called “Dep_Status” and it is included in the json file (I changed to a more appropriate name).
{
“name”: “Dep_Status”,
“value”: “Standby”
}
I added the variable in HR (Label) as an “Attributes: Dep_Status”, and linked “CarheaterCar_Yh.Dep_Status” (with Device binding :).
Unfortunately it did not work, maybe I’m wrong?
Can you give me a tip on how to do this? I’ve looked in your documentation, but I can’t find anything that help me. Many thanks for your help.

My_label

EDIT:
Regarding “callUIEvent” and the buttons for the car heater.
If it is of any help, I get this message in HC3 when I press the button “Auto” in HR.

onAction: {“actionName”:“setBtn_auto”,“args”:[""],“deviceId”:191}
[WARNING] [QUICKAPP191]: Class does not have setBtn_auto function defined - action ignored

The app does not currently support nested properties. All I was having you do now is just verify the data is available in the “devices”. And based on your findings, it is there. What you have will not work because you’ll have to provide the entire property path. What I will try to add in next release is the ability to add attributes like quickAppVariables.Dep_Status. Again, this isn’t going to work right now. You’re going to have to wait until the next release. This is going to be a new feature.

Thanks Bill!
If this is for your help, I will attach the entire json file with API Plugins.
Tell me if you want more API files, such as devices, scenes, alarms / devices, voip, weather and so on, there are many of them.
Fibaro_HC3_API_Plugins.json.txt (73.9 KB)

I don’t really need anything else. I made the changes yesterday on my development machine. They will be included in the 3.15.0 release which should be out in a couple days.

I will receive the HC3 in 2 weeks I could be in reinforcement on this box with HR!

Version 3.15.0 is available everywhere except the Apple App Store. It’s waiting for Apple review there.

Attached is a project demonstrating how to use these new Quick App features. This was built using the sample data you provided earlier. All you should need to do to get this example working is update the Password on the Fibaro source.

Fibaro_QuickApp.hrp (3.9 KB)

Hi Bill
Now the buttons work perfectly, but there are some problems with updating the Label (“quickAppVariables.Dep_Status”).
When I start the app, the Label is updated with the correct information, but if I then press the buttons, the Label does not react with the new information.

If it is to work properly, this label must also respond to changes from QuickApp’s variables. For example. in Manual mode, “quickAppVariables.Dep_Status” is continuously updated every minute until a certain time has elapsed.
When programming the time in the HR app, the response to this Label must be immediate without delay.
Now it seems that the communication with my QuickApp is one-way.

I have also tried adding different Triggers to the Label, but it has not worked (or I have done wrong).

Manual start and 9 minutes left.

The Home Remote only does a full refresh on startup. After that, it monitors changes using “/api/refreshStates?last=”. This helps keep things fast & efficient. Sounds like your quick app is not sending notifications that the device has changed. Check the Fibaro forum for support on this one. Quick Apps are still new to me so I don’t know what you need to do to enable these.

Bill, thanks for all the help.
Now the car heater works the way I want it to work.
I could not use QuickApp’s own variable so I created a Global variable where HR Label can retrieve information.

A final detail that would increase clarity is that the “Auto” and “Manual” buttons change the background color when the button (command) is active. I have tried, but it did not work because those buttons are not switches. I had thought that the background color would be controlled by a variable that can have the value “Auto” or “Manual”, but I have not succeeded.

The picture shows an HR app intended for my wife’s mobile.

You can use DataTriggers to update the Background on your Button controls.

Hi Bill
First I want to say that it now works with changing the background color of the buttons. I had accidentally tried to use QuickApp’s local variable which did not work.

Then I would like you to take a closer look at the problem with QuickApp’s local variables.
I have asked the expert “jang” on Fibaro’s forum about this and his answer is that it should work to use them. Here is jang’s answer:

If you set a QA’s quickAppVariables with “self:setVariable(name,value)” (which I have done), a trigger is generated in the HC3 that can be captured with “/refreshStates”.
The condition is that it is a new value, ie differs from the value that the variable currently has.

Since HR seems to be able to capture it at startup, it should work later as well.
Fibaro HC3 posts all quickAppVariables for a QA when a variable changes value.

I have also done tests with the command “http://192.168.1.27/api/refreshStates?last=1” several times.
I changed the local QA variables several times, and each time the command was executed I saw that the variables in the json file changed.
So the Label in HR should be updated, because the json file was updated correctly.

I would be grateful if you would review your code again to see if the issue can be resolved.
Since a QuickApp has its own variables, it would be great if you could use them. It’s like “crossing the river for water” if you have to use Fibaro’s Global Variables.

Calling “refreshStates?last=1” is not a valid test. It’s important to understand how that request actually works. “last” is an ID field that represents the data version of the JSON. “1” is the very first version so almost everything has probably changed since version “1”. The controller will likely return every device you have from that request. The current data version the controller is going to be much newer. To do an accurate test, you need to call refreshStates, get the current actual “last” value. Then call refreshStates again with the “last” value you obtained from the previous request.

The “last” value that is used is constantly changing. Each time “refreshStates” is called, we read the new “last” value that was returned & then use it for the next call. That loop repeats itself over & over. To test this accurately you need to be doing the same.

You should spot “last” near the top of the returned JSON data. After you make a call, copy that value & paste it into the search bar for your next call. Make sure you are always updating that parameter.

What you were doing with a fixed value really defeats the whole purpose of using refreshStates. Remember, this should only be returning the changes. We don’t want anything extra that hasn’t changed.

I’m sorry I did not understand what the parameter “last=1” meant, but now I have tested again in the way you described.

I ran the command “http://192.168.1.27/api/refreshStates?last=” several times and each time changed the value of “last” according to your instructions. The QuickApp variable “Dep_Status” then displayed the value “Standby”.

Then I clicked the “Auto” button and ran the command again with the latest “last=” value.
In the json file that I am now attaching, you can see on lines 297 and 625 that the value of “Dep_Status” has been changed from “Standby” to “Avresa: 12:00 / Auto”.

Line 297
“name”: “Dep_Status”,
“value”: “Avresa: 12:00 / Auto”

Line 625
“{“name”:“Dep_Status”,“value”:“Avresa: 12:00 / Auto”}”

The Json file has thus been updated correctly, but the HR app still statically shows the old value, but if I restart the app it will be updated correctly.
So, what is it that causes the HR app not to be updated?
refreshStates_QA_2020-12-23.json.txt (9.6 KB)

I think I may see the issue, or at least 1 issue. The JSON is invalid. Look at line 3. That line with Ändrad till Auto Avresa 12:00 is not formatted correctly. JSON parsers will not be able to load that.

Did you modify this file at all or is this the actual output from “refreshStates”?

Just to be clear, all it takes is 1 bad line to fault the parser. While the rest of the data may be good, it will never be processed because of that bad line at the top.

And where did Dep_Status come from?

It’s not in the “api/devices” you sent me earlier.
http://192.168.1.27/api/devices/191

I’m trying to do my best to emulate your environment but I’m only going to be as good as the data I’m given. If this is a new value you added you need provide post that data too.

It would be best if you could download the “api/devices” data first. Then start your “api/refreshStates” process & make your change.

The way the Home Remote works, is it 1st downloads “api/devices”, then begins its “api/refreshStates” loop. I am using both of these files to emulate your controller: Properties_QA_191.txt & refreshStates_QA_2020-12-23.json.txt. So you should pick a value to change that exists in both.

The addition on line 3 is my own note. I did many tests so I wrote this note to know what I did.
Dep_Status was added when I created the Global variables. I’m sorry if they’ve been misleading to you.
It’s late tonight now but tomorrow I can create new json files for you that you can work with.
As you can see, I’m concerned that there will be good HC3 support for Home Remote. ImperiHome was a fantastic tool, but I see that HR can be even better because you can create the layout you want and that HR also has support for Fibaro HC3.

1 Like