Help with QAs..

[747 18]

Hi Everyone,

 

I have just managed to go from HC2 to HC3 and im having problems to port a Froggit weather station (using Ecowitt API) to use QA.

The HC2 implementation was to query Ecowitt API and store all information into global variables but since i now understand i should instead use QA and child devices to store these instead, i have looked into several tutorials but for me its a bit messy and i cannot fully grasp the "QA" way yet.

 

So i was hoping if a kind soul could help me (Im getting old) with a simple way of creating a QA with a child device and then how to create the label, updated with values?

 

The net.HTTPClient works so i can fetch all devices and values but is there someone who can explain how i create, initialize, a child device and also how i populate it from the API response? 

 

BR

[tinman 1,071]

39 minutes ago, 747 said:

So i was hoping if a kind soul could help me (Im getting old) with a simple way of creating a QA with a child device and then how to create the label, updated with values?

 

i have created QA for Froggit / Eccowitt, however haven't released it to public. Generally only for DP2000 Pro 7-in-1 version,

Please login or register to see this link.

but of course it can support other models too. What not yet supported is automatic detection of extra attached sensors, so when need to add them extra in code.

I will send you PM with the QuickApp. 

 

 

[747 18]

@tinman That sounds great!

Many thanks for that!

 

BR

[lux 14]

 

[cag014 731]

On 10/30/2025 at 3:33 PM, 747 said:

Hi Everyone,

 

I have just managed to go from HC2 to HC3 and im having problems to port a Froggit weather station (using Ecowitt API) to use QA.

The HC2 implementation was to query Ecowitt API and store all information into global variables but since i now understand i should instead use QA and child devices to store these instead, i have looked into several tutorials but for me its a bit messy and i cannot fully grasp the "QA" way yet.

 

So i was hoping if a kind soul could help me (Im getting old) with a simple way of creating a QA with a child device and then how to create the label, updated with values?

 

The net.HTTPClient works so i can fetch all devices and values but is there someone who can explain how i create, initialize, a child device and also how i populate it from the API response? 

 

BR

I am curious, what for you need child device? To my opinion create two QAs, better control and monitor

[747 18]

When i read the tutorial from Fibaro, i understood it as i should use childs for different sensors.

Like a Weather station which is the parent, and then create childs for all the different sensors, Wind, Temp, Humidity, rain, etc. but i could of course have misunderstood it..

 

BR

[cag014 731]

29 minutes ago, 747 said:

When i read the tutorial from Fibaro, i understood it as i should use childs for different sensors.

Like a Weather station which is the parent, and then create childs for all the different sensors, Wind, Temp, Humidity, rain, etc. but i could of course have misunderstood it..

 

BR

I don't see any reason why... in any case you need to control the child to send the data of the sensors, Full QAs allow complete control over GUI elements, logic, and device behavior.

A single QuickApp (QA) in Fibaro HC3 can handle all communications and update other QAs using hub.call(). This centralized approach is powerful, especially for advanced users who want full control over logic and messaging. In addition, it is reducing overhead: No need to manage child device states or metadata.

You cannot add custom buttons, labels, or sliders to the child device’s UI.

You cannot define custom views or layouts for child devices.

Just make sure to create proper type of QA (switch, sensor, energy meter and etc.)

But at the end it depends on your needs.

 

Edited November 1, 2025 by cag014

[jgab 2,647]

Actually, child devices do support custom UIs like ordinary QAs since some time ago, that's why we have the copy JSON view button in the editor.

But, I do think that it's much more efficient to use main QA and children than just a bunch of QAs.

Each QA on the HC3 runs its own linux process and its own Lua vm. If we have children, all the Lua code runs in the "mother" QAs process and Lua vm.

[cag014 731]

10 minutes ago, jgab said:

Actually, child devices do support custom UIs like ordinary QAs since some time ago, that's why we have the copy JSON view button in the editor.

But, I do think that it's much more efficient to use main QA and children than just a bunch of QAs.

Each QA on the HC3 runs its own linux process and its own Lua vm. If we have children, all the Lua code runs in the "mother" QAs process and Lua vm.

You are absolutely correct. But the children are also bunch of QA.

Regarding the "Copy JSON View" button in the editor as far as I know does not work for child devices directly. It only applies to the parent QuickApp you're editing.

I do think that in some cases you need to use children lik Multi-device integrations, modular control, cloud APIs it is easier to manage large systems where many devices share a common backend.

 

Edited November 1, 2025 by cag014

[jgab 2,647]

Yes, but the saving is that they share lua vm and linux process...

For the custom UIs

 

[tinman 1,071]

5 hours ago, cag014 said:

I am curious, what for you need child device? To my opinion create two QAs, better control and monitor

 

that is definitely bad advice, two or more QAs accessing the same weather gateway via http, instead of one calling all updates and refreshing child devices.

Generally some http/tcp devices does not support multiple calls, or udp can bind only one port ... the overhead to let multiple QAs to work in such cases properly is much higher than understand and create QAs with child devices.

Edited November 2, 2025 by tinman

[cag014 731]

4 minutes ago, tinman said:

 

that is definitely bad advise, two or more QAs accessing the same weather gateway via http, instead of one calling all updates and refreshing child devices.

Generally some http/tcp devices does not support multiple calls, or udp can bind only one port ... the overhead to let multiple QAs to work in such cases properly is much higher than understand and create QAs with child devices.

Not at all, read carefully: I suggest that just one QA accessing weather gateway via http, and updates others. Same as you update and refreshing child devices. Use hub.call(QAID, funcName, parameters....)

Edited November 2, 2025 by cag014

[cag014 731]

Just go through the forum and see how many users have problems with creating and update/refresh children.

🧩 Option 1: Two Separate QuickApps

Pros:

• Clear separation of concerns: Each QA can have its own logic, lifecycle, and purpose.

• Independent updates: You can modify one QA without affecting the other.

• Modular testing: Easier to isolate bugs or performance issues.

• No shared UI: Each QA has its own interface, which can be confusing for users.

Cons:

• Harder communication: You need to use hub.call() or global variables to sync state

🧩 Option 2: One QA with Child Devices

Pros:

• Centralized logic: All control and updates happen in one place (onInit, loop, etc.).

• Simpler communication: Use self:getChildDevice(id):updateProperty(...) directly.

Cons:

• More complex parent QA: Logic can get dense if you manage many children.

• Limited child UI: You can’t add custom buttons or sliders to child devices.

• Harder to reuse: Child devices are tightly coupled to the parent QA.

 

[tinman 1,071]

10 minutes ago, cag014 said:

Not at all, read carefully: I suggest that just one QA accessing weather gateway via http, and updates others

 

but in that case you wasting resources and create unnecessary load. And what about 10 QA limit on HC3L or YH? The weather QA the OP is talking about is using already 10 child devcies ...

[cag014 731]

11 minutes ago, tinman said:

 

but in that case you wasting resources and create unnecessary load. And what about 10 QA limit on HC3L or YH? The weather QA the OP is talking about is using already 10 child devcies ...

The question raised about HC3 not HC3L or YH. By the way these hubs are limited for number of devices also and doesn't support Zigbee

As I said, this is an option that you don't need to mess with children. 

 

Edited November 2, 2025 by cag014

[cag014 731]

On 10/30/2025 at 3:33 PM, 747 said:

Hi Everyone,

 

I have just managed to go from HC2 to HC3 and im having problems to port a Froggit weather station (using Ecowitt API) to use QA.

The HC2 implementation was to query Ecowitt API and store all information into global variables but since i now understand i should instead use QA and child devices to store these instead, i have looked into several tutorials but for me its a bit messy and i cannot fully grasp the "QA" way yet.

 

So i was hoping if a kind soul could help me (Im getting old) with a simple way of creating a QA with a child device and then how to create the label, updated with values?

 

The net.HTTPClient works so i can fetch all devices and values but is there someone who can explain how i create, initialize, a child device and also how i populate it from the API response? 

 

BR

@747

 May I suggest using AI to deal with children? Believe me AI knows all you need about HC3, AI actually can write for you the code and it does work.

In my case I use Microsoft Copilot (free of charge) which is bult-in in windows and Edge browser.

Takes just a few seconds to get code and answer. Use Smart (GPT-5) option

Works like a charm....

 

Edited November 2, 2025 by cag014

[SmartHomeEddy 1,007]

12 hours ago, cag014 said:

🧩 Option 1: Two Separate QuickApps

Pros:

• Clear separation of concerns: Each QA can have its own logic, lifecycle, and purpose.

• Independent updates: You can modify one QA without affecting the other.

• Modular testing: Easier to isolate bugs or performance issues.

• No shared UI: Each QA has its own interface, which can be confusing for users.

Cons:

• …

I thought cag014 was a user of flesh and blood. But now we know cag014 is the first AI Bot on the Fibaro forum. Yesterday The Terminator was on Dutch television. it's getting very close now. 

[jgab 2,647]

Yes, the options list must have been AI generated as it didn't make much sense ...
Also what gave it away was the AI self bragging

Please login or register to see this code.

  

Edited November 2, 2025 by jgab

[cag014 731]

5 hours ago, SmartHomeEddy said:

I thought cag014 was a user of flesh and blood. But now we know cag014 is the first AI Bot on the Fibaro forum. Yesterday The Terminator was on Dutch television. it's getting very close now. 

I am flesh and blood and not afraid or intimidated by AI.

 

[747 18]

Ok, thanks to @tinman and of course the very good suggestion from @cag014 to use copilot i think ive got some progress now and understands a bit more when playing around with QuickApps and Childs.

I do however have some problems when trying to generate child instances.

For example i get the below error:

 

Class for the child device: 4189, with type: com.fibaro.temperatureSensor not found. Using base class: QuickAppChild

 

Which i dont understand since "com.fibaro.temperatureSensor" is spelled correctly and i have tried to create the classes both in the "onInit" function and also outside of it.

And i shouldnt be needing to have 2 child classes pointing to the same device (temp sensor).

 

The below only creates the first instance (MatsalTemp) but with above error..

 

class 'TMatsal' (QuickAppChild)

    function TMatsal:__init(device)

        QuickAppChild.__init(self, device)

        self:debug("TMatsal init")  

    end

    function TMatsal:updateValue(value)

        self:updateProperty("value", value)

    end

 

    class 'HMatsal' (QuickAppChild)

    function HMatsal:__init(device)

        QuickAppChild.__init(self, device)

        self:debug("HMatsal init")  

    end

    function HMatsal:updateValue(value)

        self:updateProperty("value", value)

    end

 

self:debug("Creating child devices..")

    -- Temperature Sensor

    local MatsalTemp = self:createChildDevice({

        name = "Matsal Temperature Sensor",

        type = 'com.fibaro.temperatureSensor',

        unit = "C",

        initialProperties = {

            value = 0.0

            }

    }, TMatsal)

 

    -- Temperature Sensor

   local BeasementTemp = self:createChildDevice({

    name = "Basement Temperature Sensor",

    type = "com.fibaro.temperatureSensor",

    unit = "C",

        initialProperties = {

            value = 0.0

            }

    }, HMatsal)

 

 

[tinman 1,071]

21 hours ago, 747 said:

 

Class for the child device: 4189, with type: com.fibaro.temperatureSensor not found. Using base class: QuickAppChild

 

Which i dont understand since "com.fibaro.temperatureSensor" is spelled correctly and i have tried to create the classes both in the "onInit" function and also outside of it.

And i shouldnt be needing to have 2 child classes pointing to the same device (temp sensor).

 

 

sounds like you are doing init with wrong names instead of class, try following:

 

 

Please login or register to see this code.

 

 

 

Edited November 13, 2025 by tinman