All-in-One Scene: How to do it Better

[Rover 47]

On 12/27/2025 at 5:22 PM, cag014 said:

I mean jM line that has the timer command.... 

for example:

{,"sensor", state="true", falseAct={"light","turnOff","timerTest,30"}}},

{"`SmartIn2`",{state=">8", lineState="if {&tSlotUitgeschakeld=Nee}",
    trueAct={  {"&pushoverBody","setGlobal","&%device=&PushoverDevice&%priority=0&%title=Waarschuwing Voorpoort&%sound=gamelan&%message=Slot Voorpoort al 4 uur uitgeschakeld timerSlot,?4x60x1000?", "if {&PushoverDevice<>Geen}"},
        --{"&pushoverBody","setGlobal","&%device=&PushoverDevice&%priority=0&%title=Waarschuwing Voorpoort&%sound=gamelan&%message=Slot Voorpoort al 4 uur uitgeschakeld timerSlot,?4x60x1000?", "if {&tSlotUitgeschakeld=Ja and &PushoverDevice<>Geen}"},
~&%device=&PushoverDevice&%priority=0&%title=Waarschuwing Voorpoort&%sound=gamelan&%message=Slot Voorpoort al 4 uur uitgeschakeld", "if {&tSlotUitgeschakeld=Ja and &PushoverDevice<>Geen}"},
        {"&tSlotUitgeschak4","setGlobal","Nee"},
        {"&tSlotUitgeschak4","setGlobal","Ja timerSlot4,?4x60x1000?"}, --Waarschuw na 4 uur slot open
        {"`Beveiliging`","setIcon,`IconSlotUit`"}, --Zet icon naar Slot uitgeschakeld
        {"&pushoverBody","setGlobal","&%device=&PushoverDevice&%priority=0&%title=GEEN Beveiliging Voorpoort&%sound=gamelan&%message=Slot Voorpoort Uitgeschakeld", "if {&PushoverDevice<>Geen}"}, --Bericht
}}},

[cag014 731]

Ok, I see what went wrong… you’re using x as the multiplication sign, which is incorrect.

{"&tSlotUitgeschak4","setGlobal","Ja timerSlot4,?4x60x1000?"}

should be
{"&tSlotUitgeschak4","setGlobal","Ja timerSlot4,?4*60*1000?"}

You know this is in seconds, right? I mean, the delay is 240000 seconds!

In any case, I will add a proper description of this error on QA startup.

[cag014 731]

12 hours ago, PSi said:

After the Update, my log if flooded with these lines, can you help? 

aoqVer=21.8

 

[28.12.2025] [14:32:12] [ERROR] [QUICKAPP98]: QuickApp crashed

[28.12.2025] [14:32:12] [ERROR] [QUICKAPP98]: main.lua:4769: attempt to concatenate a nil value (local 'newValue')

Please download attached version

Please login or register to see this attachment.

 

Please let me know if it works, so I can publish this version on the forum.

[Rover 47]

On 12/28/2025 at 10:18 PM, cag014 said:

 

Ok, I see what went wrong… you’re using x as the multiplication sign, which is incorrect.

{"&tSlotUitgeschak4","setGlobal","Ja timerSlot4,?4x60x1000?"}

should be
{"&tSlotUitgeschak4","setGlobal","Ja timerSlot4,?4*60*1000?"}

You know this is in seconds, right? I mean, the delay is 240000 seconds!

In any case, I will add a proper description of this error on QA startup.

 

TNX, @cag014, for your analysis. Indeed I had used milliseconds and the wrong sign for multiplication! Indeed any error which stops the system should be detected, but that is easier to say than done!

[PSi 9]

thanks, the patch fixed my issues!

[AR27690 19]

@cag014

There is a useful table stored in the webEye variable that I normally view through hcWebEye, but after a recent browser update I’m running into CORS issues because it relies on JavaScript.

My question is: is it possible to display this table directly inside a QA using labels?

This table has been extremely helpful for monitoring Zigbee and Z‑Wave events and identifying problematic devices that flood the network and slow down the hub. Thanks to it, I’ve already reconfigured several devices to stop unnecessary reporting and to use proper thresholds for triggering updates.

Any help would be appreciated. Thanks!

Perhaps other users will find this helpful too and join in supporting this request.

[cag014 731]

On 1/5/2026 at 1:14 AM, AR27690 said:

My question is: is it possible to display this table directly inside a QA using labels?

Yes, it does - work in progress

[cag014 731]

This is the direction

Please login or register to see this spoiler.

It monitors hub load by tracking events per hour, similar to Diagnostics → Z‑Wave, but in this case all device types are included (Z‑Wave, Zigbee, Nice/Elero).

The tool reports load per device and per device family, helping you identify “noisy/chatty” devices that generate excessive traffic.

If slave hubs are defined, their devices and families are monitored as well. Slave‑device monitoring can be disabled by setting the global variable: topActiveAll = false

[747 18]

Hi,

 

Does anyone have a working "reboot HC3 when RAM > 85%" ?

I tried an old example but it complains about password..

 

BR

[cag014 731]

11 hours ago, 747 said:

Hi,

 

Does anyone have a working "reboot HC3 when RAM > 85%" ?

I tried an old example but it complains about password..

The AOQ reboot command worked on HC2, but on HC3 it was removed for security reasons by Fibaro

Because triggering a reboot in AOQ is extremely easy — based on real user experience — I’ve decided not to support the reboot command on HC3. It will likely be removed from the list of allowed commands entirely. Once you start an automated reboot loop, it becomes almost impossible to stop without a factory reset.

For example:
If you set “if RAM > 85% then reboot”, the HC3 will reboot, AOQ will start again, RAM will still be >85%, and the system will reboot endlessly. This “vicious loop” is very hard to break. It’s much better to first understand why RAM usage is high instead of rebooting blindly.

 

Recommended solution:
Create your own scene and call: fibaro.homeCenter.systemService.reboot()

(This command does not work inside a QuickApp.)

The idea is that using a scene forces you to be fully aware of what you’re doing. Just make sure your scene does not trigger another reboot immediately after the system restarts.

In AOQ:

 

define name for scene

jS2n={rebootScene="_73", ......}

{"$RAM",{state=">85",trueAct={"`rebootScene`","startScene"}}} -- run scene 73 

or run directly 

{"$RAM",{state=">85",trueAct={"_73","startScene"}}}   -- run scene 73 

 

I would suggest adding a delay of a few minutes. If something goes wrong, you’ll have a short window to fix the issue before the reboot triggers again.

{"$RAM",{state=">85",trueAct={"`rebootScene`","startScene","180"}}}

Edited January 12 by cag014

[747 18]

Thanks @cag014!

[cag014 731]

@AR27690 and others

The attached files include the updated diagnostic table for the QA UI. This release is unofficial, like Fibaro beta 😀

A few important notes:

• The table refreshes automatically every 10 minutes. If you want to see changes immediately, you can refresh manually by toggling the power switch to OFF.

• Events‑per‑hour values are delayed for the first 5 minutes after startup. This ensures there is enough data for accurate statistical calculations. If you restart the system, a manual refresh is recommended between minutes 5–10.

• Please download and review the updated user guide, specifically Section 10 – Top Active Devices Table.

 

Please login or register to see this attachment.

 

Please login or register to see this attachment.

 

I’d appreciate any observations or insights you can share.

Edited January 14 by cag014

[AR27690 19]

@cag014

I ran the new AOQ version with monitoring table and discovered that my HC3 was constantly switching between “Busy” and “Unstable” status due to a very high number of events per hour.

The monitor table showed two power plug devices with high events‑per‑hour results (marked in RED). These turned out to be the source of the overload. The appliances connected to them (a kitchen oven and a dishwasher) occasionally consume 0.5–1W even when OFF, then drop back to 0W. This tiny fluctuation triggers endless power reports, and unfortunately it cannot be filtered using wattage or percentage thresholds.

As a workaround, I connected a small 1.5W load in parallel, and the excessive reporting stopped immediately.

This reduced my system load from ~1500 events/hour down to ~700. Since then, the HC3 has remained stable for many hours, and—surprisingly—all my Zigbee devices started working flawlessly again.

A simple event‑monitoring table helped me identify the issue, and after fixing it, my entire system is running smoother than ever—something I’ve never experienced before.

Thanks again for the help!

👍

 

[AR27690 19]

In addition also Z-wave devices that had communication problem (device located farway) now back to normal

Edited January 16 by AR27690

[cag014 731]

@AR27690

Thanks for your feedback.

Based on my experience, Zigbee devices start working normally again once the HC3 is no longer overloaded. The HC3’s Z‑Wave engine is relatively heavy, and when a Z‑Wave device floods the controller with frequent reports, it can consume enough CPU time to delay Zigbee processing. This results in symptoms such as:

• Delayed Zigbee LQI updates

• Slow Zigbee device commands

• Zigbee devices appearing “disconnected”

• Scenes triggered by Zigbee running late

I also have an HC3 that runs only Zigbee devices, and it has been working flawlessly for months.

I really hope Fibaro will eventually find a way to run Z‑Wave and Zigbee more independently, or that the next HC generation will include stronger CPU and RAM. Hardware is inexpensive these days, and the system would benefit greatly from more resources.

[PSi 9]

Hi, I have an error with my condition. The value is 0.0 but condition evaluates to true and executes action.

Code:

    {30,"`azzurroProduction`",        

        {state="value>`minSolarProduction`",

        --initOnStartup=false,

        timeSlot="8:30~10:00", --morgens

        trueAct={{"","tts","$dayTime, azzurroProductionEast"},

                {"`blindsEast`","setFavoritePosition,FavoritePosition1"}},

                }},

Log:

[29.01.2026] [08:31:00] [TRACE] [AOQ98]: jM{15}_Is Home Office:Azzurro Production Power Current[0.0^>3000] ➯ setFavoritePosition,FavoritePosition1{blindL,blindBathroomOg,blindPlayE}

[cag014 731]

Please post the entire jM line and I'll look into it

 

[PSi 9]

19 hours ago, cag014 said:

Please post the entire jM line and I'll look into it

 

Hi, I switched the value of minSolarProduction from 3000 to 3000.0 and it worked. Seems to be a type conversion error

[Rover 47]

Some time ago I had read in this forum a variant of the often bespoken case of the motion sensor that has to be stopped after a few minutes, but then with discrimination of the case where the motion sensor breaches and the case where a manual switch puts on the light.

Could someone help me to find this forum item?

Edited February 11 by Rover

[cag014 731]

25 minutes ago, Rover said:

Some time ago I had read in this forum a variant of the often bespoken case of the motion sensor that has to be stopped after a few minutes, but then with discrimination of the case where the motion sensor breaches and the case where a manual switch puts on the light.

Could someone help me to find this forum item?

Do you mean different behavior depending on how the light was turned on — whether it was activated by motion or switched on manually?