All Activity

try with lux as optional condition and not as trigger : { conditions = { { id = 80, isTrigger = true, operator = "==", property = "value", type = "device", value = true }, { id = 82, isTrigger = false, operator = "<=", property = "value", type = "device", value = 45 } }, operator = "all" } Btw, ensure you did changed parameter 40 from the motion sensor, with default value of 200 it will not recognize values such low as 45 https://manuals.fibaro.com/motion-sensor/#post-995

I had exactly the same issue last week. 2 Smoke detectors sirene the alarm. One of the at around 9:30 in the morning, and the second one just 6 days later at 4:30 at night. No fire / smoke / high temperature situation at all. Only interesting part is that both of them were installed at nearly the same time at two different location in the house. So I don't believe this has anything to do with dust or a need to clean. I would be very unlikely that both of them reached the same dust level at nearly the same time at two differnt locations. My guess that either some internal timer reached a llimit (do we need to (must) do the smokealarm test at least once a year to avoid this rundowntimer punishing the whole family at 4:30 at night?) or it is some batterylevel trigger (HC3 still indicates the battery as at least 90% full after 2-3 years). Maybe someone from Fibaro (smoke detector firmware) team knows what really got the alarm triggered.

Jan, the debug screen is rolling over my screen with the new version the info in the debug window I see for the first time If I go back a version I see my normal debug screen with rules execution. All er7 a'as are doing this HC3 is very slow now>> going back to perevious version Will keep bedroom as version to answer your questions

I don't know what you mean with scrolling? ER can't control the scrolling of the console on the HC3...??? The version is printed when ER starts up, before loading rules, (it's part of :onInit() ) [08.06.2026][16:46:35][DEBUG ][EVENTRUNNER75555]: EventRunner 7, v0.1.40 [08.06.2026][16:46:36][DEBUG ][EVENTRUNNER75555]: =========== Loading rules ================ [08.06.2026][16:46:36][DEBUG ][EVENTRUNNER75555]: ✅ RULE1: registered: @@00:00:05 => log[({'red','green','yellow'})[rnd.. [08.06.2026][16:46:36][DEBUG ][EVENTRUNNER75555]: =========== Load time: 0.028s ============ [08.06.2026][16:46:36][DEBUG ][EVENTRUNNER75555]: tick! [08.06.2026][16:46:41][DEBUG ][EVENTRUNNER75555]: tick! [08.06.2026][16:46:46][DEBUG ][EVENTRUNNER75555]: tick!

Jan, V1.0.38 >>>> can't see screen scrolling, if previous ER version stopped this version v1.0.37 is normal debug can print also version inhere? [08.06.2026] [14:37:13] [DEBUG] [QUICKAPP663]: =========== Load time: 1.473s ============

So, how does the rule look like that prints the log message? Sorry, debug message left. Fixed in v0.1.39 I mean v0.1.40

Ok I have a scene that is only meant to turn on a light when PIR trips and the LUX is less than 45 the light should turn on. Problem is the light turns on no matter what the Lux is, even if I set it to Lux == 3 it still turns on. I have tried this with several Magic Eyes. { conditions = { { id = 80, isTrigger = true, operator = "==", property = "value", type = "device", value = true }, { id = 82, isTrigger = true, operator = "<", property = "value", type = "device", value = 45 } }, operator = "all" }

Jan this is scrolling over my screen on that way I can't look back what is/was happening. Can I stop that? [08.06.2026] [16:07:36] [DEBUG] [QUICKAPP662]: Device 628 value changed to 0, last change was 1s ago [08.06.2026] [16:07:36] [DEBUG] [QUICKAPP662]: Setting false [08.06.2026] [16:07:36] [DEBUG] [QUICKAPP662]: Device 492 value changed to 0, last change was 1s ago [08.06.2026] [16:07:36] [DEBUG] [QUICKAPP662]: Setting false [08.06.2026] [16:07:36] [DEBUG] [QUICKAPP662]: Device 613 value changed to 0, last change was 1s ago [08.06.2026] [16:07:36] [DEBUG] [QUICKAPP662]: Setting false [08.06.2026] [16:07:36] [DEBUG] [QUICKAPP662]: Device 618 value changed to 0, last change was 0s ago [08.06.2026] [16:07:36] [DEBUG] [QUICKAPP662]: Setting false [08.06.2026] [16:07:36] [DEBUG] [QUICKAPP662]: Device 634 value changed to 0, last change was 1s ago [08.06.2026] [16:07:36] [DEBUG] [QUICKAPP662]: Setting false [08.06.2026] [16:07:38] [DEBUG] [QUICKAPP662]: Device 155 value changed to 234.12, last change was 10s ago [08.06.2026] [16:07:38] [DEBUG] [QUICKAPP662]: Setting false [08.06.2026] [16:07:39] [DEBUG] [QUICKAPP662]: Device 156 value changed to 0.21, last change was 10s ago [08.06.2026] [16:07:39] [DEBUG] [QUICKAPP662]: Setting false [08.06.2026] [16:07:41] [DEBUG] [QUICKAPP662]: Device 86 value changed to 19.8, last change was N/As ago [08.06.2026] [16:07:41] [DEBUG] [QUICKAPP662]: Setting false [08.06.2026] [16:07:44] [DEBUG] [QUICKAPP662]: Device 155 value changed to 234.21, last change was 6s ago [08.06.2026] [16:07:44] [DEBUG] [QUICKAPP662]: Setting false [08.06.2026] [16:07:45] [DEBUG] [QUICKAPP662]: Device 156 value changed to 0.09, last change was 6s ago

Sorry, in 0.1.38 the comment support is back

What you are describing usually happens when the system is not simply “reading” the ceiling sensor, but actually using it as part of a control decision after the firmware update. Even if the temperature shown at the ceiling is above the cooling setpoint, the controller can still switch the aircon OFF if that sensor is tied into automation logic, a zone controller, or a feedback loop that was modified in the newer firmware versions. The fact that everything worked on 5.141.59 but started failing from 5.150.15 strongly suggests a change in how sensor inputs are interpreted rather than a physical temperature issue. In many modern office HVAC setups, especially where ceiling sensors are part of a broader zoning or BMS-style control, the wiring and logic relationship matters more than the visible reading. A sensor can look “independent,” but still be assigned indirectly through scenes, safety overrides, or energy-saving rules that trigger shutdown when readings change rapidly or appear inconsistent. This is also where installation design becomes important, because routing, zoning, and controller mapping need to stay consistent even after software updates. Some practical context on how these systems are typically structured in real installations is reflected in SoCool’s aircon setup approach, and related system design considerations can be seen through their installation information, which highlights how sensor placement and system layout often influence overall control behavior more than expected. Given the pattern you described, the most likely explanation is a firmware-side change in automation priority or sensor handling rather than the ceiling sensor itself being faulty. If reverting the firmware immediately stops the issue, that would essentially confirm it.

Slaves support for 3.0 engine was introduced in 5.170 GA (November 2024) -> Migration to new 3.0 engine also supports GC setups.

Jan I get still errors when I fa use --comment in a rule. Is it not done anymore in ER7?

Jan, For my grandchildren (and myself) I do: rule([[licht_show == true => fibaro.call(media.Licht_Show,"turnOn","Singapore"); log.dodgerblue('>>>>>>>>>>>> Licht_Show scene >>> Singapore'); wait(00:03:02); fibaro.call(media.Licht_Show,"turnOn","Disturbia"); log.dodgerblue('>>>>>>>>>>>> Licht_Show scene >>> Disturbia'); wait(00:03:02); fibaro.call(media.Licht_Show,"turnOn","Zandvoort"); log.dodgerblue('>>>>>>>>>>>> Licht_Show scene >>> Zandvoort'); wait(00:03:02); and so on Can I do something similar with NextScene? Also possible to start randome?

ok, a compromise. v0.1.37. opts = { check = ''success" } will only log the success. opts = { check = ''failure" } will only log the failures. opts = { check = true } will log success & failure

toggle is still there - works for me. Some special kind of light? Do you still see event logs in the console? The event listener may have stopped? For roomzone QAs there is a nextScene and prevScene commands implemented in 0.2.65

Well, your QA seems to do some heavy processing (home table with 409 devices?) initially which keeps it busy. The web frontend meanwhile tries to call the Lua engine (your QA) to get the UI to display. It doesn't get it and logs the warning. It will retry and eventually it succeeds and everything should work. So it's harmless. Maybe the warning message could be more informative. (This has always been an issue if the lua engine is too busy to answer the frontend...)

Hi Jan, Small question about Yahue v0.2.62: did the child method toggle() get removed or renamed? After updating, my external EventRunner/Matrix rules still trigger correctly, but calls like this no longer seem to work: fibaro.call(yahueChildId, "toggle") turnOn, turnOff, and setValue still appear to exist, so I can work around it by doing my own state check and calling turnOn/turnOff. Just wanted to ask if this was intentional, or if toggle() should still be part of the child API. Thanks again.

Hey, As I remember slaves worked only under z-wave 2.0. Is this upgraded to 3.0, too? Any experience?

Same problem - The MUTE button does not work. Great work! Can you share your .fqa?

Hi, I've created a quick app for reading data from the Growatt SPH inverter and its dongle—no converter needed! Data is downloaded in real time directly from the dongle and displays useful information that can be used for further automation. All you need is the latest version FW of the dongle and to set the device’s IP address. I recommend setting a static IP on your router. Here’s a demo of what it can do: in the add-on settings, select the IP, interval, and language (Czech or English). QA will automatically install the add-on. You can start using it right away. I’d appreciate any suggestions for improvements. Growatt_Dongle_Test.fqax

If you think this approach makes sense, would you consider adding nextScene/prevScene and dimStep to Yahue? No pressure of course. I really appreciate the work you put into these QAs.

Jan, I am using several daylight scenes in each room. I want to do it for all zones/rooms with: rule([[$Verlichting_Dagdeel == 'Opstaan_Sjaak' & $Verlichting_Kleur_Van_De_Dag ~= 'Concentreren' | test5=> $Verlichting_Kleur_Van_De_Dag = 'Concentreren'; fibaro.call(zithoek.Zithoek_Verlichting,"SetScene","Concentreren"); log.dodgerblue('73-A - zithoek.Zithoek_Verlichting - Scene - Concentreren'); log.pink('73-A >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> $Verlichting_Kleur_Van_De_Dag = Concentreren'); wait(0) ]]) rule([[test11 => zithoek.Salontafel_Lampen:setDim= 50; log.pink('73-B - Check >>> zithoek.Salontafel_Lampen set 50 procent >>> %s procent',zithoek.Salontafel_Lampen:value); wait(0) ]]) Perhaps it's wrong because it does't work If I add before setDim to switch on it switch on but with the previous color setting. How to correct?

With the last version, I have now the following errors during the QA process in vscode: [06.06.2026][07:02:07][INFO ][PLUA]: Starting helper server on 192.168.1.32 8082 Fibaro SDK, online, (0.7281s) [06.06.2026][07:02:07][DEBUG ][HOMETABLE5555]: ---- onInit() starts ---- [06.06.2026][07:02:07][DEBUG ][HOMETABLE5555]: QA HomeTable id:5555 starts [06.06.2026][07:02:07][DEBUG ][HOMETABLE5555]: --------- onInit( ends --------) [06.06.2026][07:02:08][DEBUG ][HOMETABLE5555]: ======================== update of HomeTable starts ======================== [06.06.2026][07:02:08][DEBUG ][HOMETABLE5555]: -------- Getting Device list -------- [06.06.2026][07:02:11][DEBUG ][HOMETABLE5555]: #devListAll 409 [06.06.2026][07:02:11][DEBUG ][HOMETABLE5555]: #devListVisible 409 [06.06.2026][07:02:11][DEBUG ][HOMETABLE5555]: #aQ less VoipUsers= 404 [06.06.2026][07:02:49][DEBUG ][HOMETABLE5555]: 156 Escalier_Grenier . Lum_Escalier_Grenier_ = 195 [06.06.2026][07:02:49][DEBUG ][HOMETABLE5555]: HomeTable[ Escalier_Grenier ][ Lum_Escalier_Grenier_ ] id= 195 WARNING:plua.fastapi_process:\U0001f527 QuickApp 5555 not found [06.06.2026][07:03:09][DEBUG ][HOMETABLE5555]: 248 Communs . Lum_Communs = 324 [06.06.2026][07:03:09][DEBUG ][HOMETABLE5555]: HomeTable[ Communs ][ Lum_Communs ] id= 324 [06.06.2026][07:03:11][DEBUG ][HOMETABLE5555]: 253 Grenier_Pignon . Lum_Pignon_Grenier = 329 [06.06.2026][07:03:11][DEBUG ][HOMETABLE5555]: HomeTable[ Grenier_Pignon ][ Lum_Pignon_Grenier ] id= 329 WARNING:plua.fastapi_process:\U0001f527 QuickApp 5555 not found But at the end of the QA process, the HomeTable is correctly created and also displayed in the webUI as a table. What can create such Warning message?

When check=true then log displays all rules involved with the state change of a device like below: [05.06.2026] [20:14:08] [DEBUG] [QUICKAPP769]: 👍 lumVestibule_16: #device{"id":389,"value":true,"old":false,"property":"value"} [05.06.2026] [20:14:08] [DEBUG] [QUICKAPP769]: 👎 lumVestibule_17: #device{"id":389,"value":true,"old":false,"property":"value"} [05.06.2026] [20:14:08] [DEBUG] [QUICKAPP769]: 👍 lumVestibule_14: #device{"id":341,"value":true,"old":false,"property":"value"} [05.06.2026] [20:14:08] [DEBUG] [QUICKAPP769]: 👎 lumVestibule_15: #device{"id":341,"value":true,"old":false,"property":"value"} [05.06.2026] [20:14:08] [DEBUG] [QUICKAPP769]: 👍 lumVestibule_45: #device{"id":341,"value":true,"old":false,"property":"value"} [05.06.2026] [20:14:08] [DEBUG] [QUICKAPP769]: 👍 lumVestibule_14: #device{"id":316,"value":true,"old":false,"property":"value"} [05.06.2026] [20:14:08] [DEBUG] [QUICKAPP769]: 👎 lumVestibule_15: #device{"id":316,"value":true,"old":false,"property":"value"} [05.06.2026] [20:14:08] [DEBUG] [QUICKAPP769]: 👍 lumVestibule_45: #device{"id":316,"value":true,"old":false,"property":"value"} [05.06.2026] [20:14:08] [DEBUG] [QUICKAPP769]: 👍 lumVestibule_14: #device{"id":436,"value":true,"old":false,"property":"value"} [05.06.2026] [20:14:08] [DEBUG] [QUICKAPP769]: 👎 lumVestibule_15: #device{"id":436,"value":true,"old":false,"property":"value"} [05.06.2026] [20:14:08] [DEBUG] [QUICKAPP769]: 👍 lumVestibule_45: #device{"id":436,"value":true,"old":false,"property":"value"} What I want to do is eliminating logs which are false (👎). Since I am using EventRunner 4->6->7, I have a strange issue: the 3 Wallis of LustreB light are going "on" without manual action of any switch or QA. I a trying to isolate logs of only the switches and QA involved in the management of this light when the condition is true. The rules are: --groupe ruleVestibB rule("(lumB1-2):central.keyId == 2 & (lumB1-2):central.keyAttribute == 'Pressed' => if lumB1:isOff then LustreB:on else LustreB:off end",{name="lumVestibule_11"},{group="ruleVestibB"}) rule("(lumB4-2):central.keyId == 2 & (lumB4-2):central.keyAttribute == 'Pressed' => if lumB1:isOff then LustreB:on else LustreB:off end",{name="lumVestibule_12"},{group="ruleVestibB"}) rule("(lumB5-2):central.keyId == 2 & (lumB5-2):central.keyAttribute == 'Pressed' => if lumB1:isOff then LustreB:on else LustreB:off end",{name="lumVestibule_13"},{group="ruleVestibB"}) rule("LustreB:isOn => lumQaB:on",{name="lumVestibule_14"},{group="ruleVestibB"}) rule("LustreB:isOff => lumQaB:off",{name="lumVestibule_15"},{group="ruleVestibB"}) rule("lumQaB:isOn => if LustreB:isOff then LustreB:on end",{name="lumVestibule_16"},{group="ruleVestibB"}) rule("lumQaB:isOff => if LustreB:isOn then LustreB:off end",{name="lumVestibule_17"},{group="ruleVestibB"}) rule("LustreB:isOn => wait(00:45);LustreB:off",{name="lumVestibule_45"},{group="lumToT"}) The above rules work perfectly when any of the 3 Wallis (lower switch) is manualy activated or the QA when using the Yubîî application. I am sure there is a better way to do this, because I have dual log of each rule and I have not find why.

If anyone wants any integration made by Nice / Fibaro, anyone can reach via more.fibaro.com. I believe that Official plugin is compatible with previous Philips HUE gateway with current firmware? Btw, even Cotnrol4 does not have driver for new Philips Hue gateway and 3rd party driver, which is paid btw, is needed and they have support for previous HUE Gateway. @m.roszak, any plans for more.niceforyou.com?