All Activity

In theory full close shoud hit the end limit switch, slats returs back to previous position but staring from absolute 0% - so this should handle the synchro anyway. Maybe for some reason Close is not hitting the limit switch but this would be strange.

Hm, I just tried with a scene and closed position is not enough - it does lower the blinds to 0%, but the slats open back to the angle before lowering the blinds, so I have to add the slats angle if I want to keep them fully closed. And I also reach full bottom position daily with my scene, but I think this bottom position is based on timing and not on limit switch/actual bottom. I would need the scene to close the blinds -> set the slats angle to 0° -> after hitting 0° hold the signal for 1 second, this would make sure it is really limit switch stopping the blinds and are fully closed.

Just Close action will allign that, regarless of the next slats control position. As the bottom position (end limit switch) means closed shutter and the slats - this is the moment motor has absolute position 0, any position change from that moment between end limit switches will work on timing. So reaching full bottom position from time to time will be enough.

So I understand opening/closing and slats angle as two different settings. Therefore my scenes first close the blinds (in case they are open more than e.g. 30%) and then set slats angle to 0°. Is this the correct way?

Full closure will guaratnee the sychronisation, so hitting bottom limit switch (or upper should also work). So upening the whole blind just a bit and then closing it fully should allign that.

Hi @tinman, I am also interested by your QA as I just bought / start to use Ecowitt with HP 2561. Thanks in advance for your support. With BR, Dan

I understand the error comes from timing. I often angle them just 30° so yes, with fully opening the error would not be that visible. Blinds should be stopped with physical switch on the motor instead of when reaching the 0°, that would be the best solution if possible (and this is what I do when I correct the slats angle rotation time). But I can try with that 10% opening next time.

Shutters will correct slats angle staring point after normal movement of the shutter, its one motor controlling both angle and position. If you just move the shutter up and down the error will be compensated, there is no way of keeping the timing correct for the whole device life (speed changes depending on the temperature, dust and a lot of other factors during lifecycle). Maybe just make a scene which will open them up to 10% and close again fully once in a week and thats that.

Hi, mostly I am just tilting venetian blinds 0° -> 90° and 90° -> 0° instead of opening them. Over time it happens, I believe due to the small errors in timing, that the slats angle is not correct anymore. Usually I notice it, when the slats do not close completely anymore and this can take from a few weeks to a couple of months to be noticeable. Then I have to go to the device settings, correct the slats angle rotation to minimum and rotate them to "90°", then set the correct time and close it to 0° and it is fine again for a few weeks. Can I somehow do that with a scene, maybe some delay to not look for an angle but for a set time? Ideally, every time the slats go to 0°.

Try this and you will see the start order - it's always the same - as listed in UI. Whatever you do. If one need order of --%%file appearance in plua you need: 1) upload application (no start order guaranteed) 2) set --%%project to uploaded ID 3) run in plua and stop 4) update application (now, you can expect the same order as file directives). There's no fix of plua necessary - there is a solution only little longer. test_order.fqa

Well, we know nothing certain about the module loading order, and even less about the order in which QuickApps start. My impression is that whichever one manages to push its way through first is the one that starts first. Is that why you didn’t implement ER a client–server application? It’s a different topic, but I couldn’t resist asking after my recent "server-side experiences". Your request from six years ago didn’t attract any interest. My SVG proposal – which significantly improves the quality of communication with the user in a simple way – attracted four interested people...

Dear Jan, Enjoy the holidays... no screen for a couple of weeks sounds good. Upgraded to 0.49 and tried above, still got some errors on the reboot, no rush, posting it, as I just looked into it. Node-red work & temperature was error from my side, accidently created a table in my HomeTable. Thanks & "See you" end of Aug / early Sept [27.07.2026] [10:07:00] [DEBUG] [QUICKAPP859]: Restart HC3 [27.07.2026] [10:07:00] [ERROR] [QUICKAPP859]: ❌ RULE4: Undefined variable: 'hc3api' hc3api.post('/service/reboot',{recovery=false}) ^^^^^^ src: @10:07 & wday('mon') => _creds = fibaro.basicAuthorization('admin','password'); log('#C:red#Restart HC3'); hc3api.post('/service/reboot',{recovery=false}) [27.07.2026] [10:07:00] [ERROR] [QUICKAPP859]: ❌ RULE4: Disabled src: @10:07 & wday('mon') => _creds = fibaro.basicAuthorization('admin','password'); log('#C:red#Restart HC3'); hc3api.post('/service/reboot',{recovery=false})

Yes, it looks like the installation is broken. It trying to load dkjson.lua instead of plus's own builtin json lib is a bad sign. Google "force an install with scoop ?" and follow the guidance from the AI answer...

I'm on vacation and will not be coding again until second week in August...

It used to be a bit random. It may be that after they fixed the QA file load bug some time ago that the order has become more predictable. However, if that was the case I would assume that they had a way to allow us to reorder the files in the edit UI ? ER7 uses a module system where each module sets a priority. < 0 loads before main code runs and > 0 loads after. There are many ways to solve it. As I proposed in the post 6 years ago we could agree about a model to make it easier to use each others modules, but there were no believers at that time.

If I'm wrong with my opinion, I think the load manager should be very easy to write. File ONE (file order - no matters): MODULES = MODULES or {} MODULES.database = function() --whole content of the module, even thousands of lines -- like: Database = {} local cache = {} function Database.read(id) return cache[id] end function Database.write(id, value) cache[id] = value end end File TWO (file order - no matters): MODULES = MODULES or {} MODULES.compiler = function() -- whole compiler content -- functions, locals end ...and all other files of the project. Finally, load manager: MODULES = MODULES or {} local loadOrder = { "database", "compiler", -- and more components in desired order } function QuickApp:onInit() for _, name in ipairs(loadOrder) do local loader = MODULES[name] if not loader then error("Missing module: " .. name) end print("Loading module: " .. name) loader() end MODULES = nil -- and more code of project end This ensures controlled order of loading. Name scooping behaves practically the same as not function-enclosed. * One trap: in each module do not forget final end

I think we can assume that the files are launched in the same order in which they appear in the box interface. And what I described above seems to happen repeatedly.

You can’t rely on the load order of QA files on the HC3. The only given is that :onInit() is called after all files are loaded.

Good morning, I’ve encountered some unexpected behavior in PLUA. Is this a bug? In my opinion, it would be worth fixing. When selecting Run Task/upload current file as QA, if the file contains --%%file=... directives, the files are not loaded into the QA in the same order as the --%%file directives. This can matter. In my case, it did. However, if a project file is created first, which, to my knowledge, essentially means starting a debugger session, and then Run Task/update QA is selected, the files are loaded in the same order as the file directives.

In fact, I think that something went wrong during the last update as when launching a old QA code which was perfectly working before, I am getting the following message: Process started Detected host IP: 192.168.1.34 ╭──────────────────────────────────────────────────────────────────────────────╮ │ Python:3.14.2, Lua:5.4 │ │ API:8080 │ ╰──────────────────────────────────────────────────────────────────────────────╯ Fibaro SDK, offline, (0.3965s) no field package.preload['dkjson'] no file 'C:/Users/bruvi/scoop/apps/python/current/Lib/site-packages/lua/dkjson.lua' no file 'C:\Users\bruvi\scoop\apps\python\current\dkjson\init.lua' no file 'C:\Users\bruvi\scoop\apps\python\current\..\share\lua\5.4\dkjson.lua' no file 'C:\Users\bruvi\scoop\apps\python\current\..\share\lua\5.4\dkjson\init.lua' no file '.\dkjson.lua' no file '.\dkjson\init.lua' no file 'C:\Users\bruvi\scoop\apps\lua\current\bin' [C]: in function 'require' [C]: in function 'xpcall' [string "<python>"]:1: in main chunk I tried to reinstall plua and I am getting at then end of the TERMINAL log: ... Requirement already satisfied: colorama in C:\Users\bruvi\scoop\apps\python\current\Lib\site-packages (from click>=7.0->uvicorn>=0.30.0->uvicorn[standard]>=0.30.0->plua) (0.4.6) Requirement already satisfied: colorama in C:\Users\bruvi\scoop\apps\python\current\Lib\site-packages (from click>=7.0->uvicorn>=0.30.0->uvicorn[standard]>=0.30.0->plua) (0.4.6) Requirement already satisfied: colorama in C:\Users\bruvi\scoop\apps\python\current\Lib\site-packages (from click>=7.0->uvicorn>=0.30.0->uvicorn[standard]>=0.30.0->plua) (0.4.6) Requirement already satisfied: httptools>=0.6.3 in C:\Users\bruvi\scoop\apps\python\current\Lib\site-packages (from uvicorn[standard]>=0.30.0->plua) (0.7.1) Requirement already satisfied: python-dotenv>=0.13 in C:\Users\bruvi\scoop\apps\python\current\Lib\site-packages (from uvicorn[standard]>=0.30.0->plua) (1.2.1) Requirement already satisfied: pyyaml>=5.1 in C:\Users\bruvi\scoop\apps\python\current\Lib\site-packages (from uvicorn[standard]>=0.30.0->plua) (6.0.3) Requirement already satisfied: watchfiles>=0.13 in C:\Users\bruvi\scoop\apps\python\current\Lib\site-packages (from uvicorn[standard]>=0.30.0->plua) (1.1.1) WARNING: Ignoring invalid distribution ~lua (C:\Users\bruvi\scoop\apps\python\current\Lib\site-packages) WARNING: Ignoring invalid distribution ~lua (C:\Users\bruvi\scoop\apps\python\current\Lib\site-packages) Do I have to reinstall everything using scoop?

hi @jgab, I just started a new QA for controlling a new High Loal module from Nice, id 818 and I am getting the following error when using fibaro.getValue(818;"name") or api.get("/devices/818"): Process started Detected host IP: 192.168.1.34 ╭──────────────────────────────────────────────────────────────────────────────╮ │ Python:3.14.2, Lua:5.4 │ │ API:8080 │ ╰──────────────────────────────────────────────────────────────────────────────╯ Fibaro SDK, online, (0.7574s) [C]: in upvalue 'original_error' [C]: in function 'xpcall' [string "<python>"]:1: in main chunk This is the first time I get this... F5 was with "Plua Run Current Fibaro File with Debugger" As the line print("sunSet at",fibaro.getValue(1, "sunsetHour")) is working now, I need to check if my request has the correct format... I have corrected the format of my requests and it is working now but I wonder why I did not get previous error message with line number where the error occurs.

802.Growatt Open API v4 monitor & control for Fibaro HC3 Download v1.0.0: 802.Growatt_v4.fqa Marketplace link: https://marketplace.fibaro.com/items/802-growatt-api-v4 I'd like to share 802.Growatt v4, a QuickApp for Fibaro HC3 that discovers and monitors every Growatt inverter in a plant through the official Growatt Open API v4, and optionally lets you control them. What it does: - Discovers every inverter serial and exact device type in your Growatt plant/account (optionally filtered to one Plant ID). - Polls production data per inverter: current power, today/month/year/lifetime energy, PV1/PV2 input details when supplied by the API. - Creates stable standard meter child devices per inverter: <serial> Power, <serial> Energy Today, <serial> Total Energy, and PV1/PV2 power meters when available. - Parent device totals sum current power and energy across all discovered inverters, so the parent's Power/Energy properties represent the whole plant, not a single inverter. - Guarded write controls: Inverter On/Off, active-power limit (0-100%), and VPP charge/discharge target (-100% to +100%). All of these require a continuous 3-second hold on Apply before anything is sent, and every command is verified by reading the setting back afterwards. - Adaptive polling: uses your configured PollSeconds during daylight and automatically switches to a slower night interval between HC3's sunset/sunrise, capped so it changes exactly at the boundary. - Daily production stats: peak power with timestamp, first/last production time, duration, and a rolling history of completed days. - Highest combined AC output record since installation or last Factory Reset. - Optional fire-alarm safety action (Force ON/Force OFF) triggered by an HC3 custom event via EventLib. - Supports both Classic (HTML card) and New (physical label row) HC3 view layouts; switching is a 5-second hold on Change View. - Reinstall-safe configuration: on first install or reinstall, the QA restores BaseUrl/PlantId/DeviceSn/PollSeconds/AutoUpdateTime/debug (and the API token) from a same-plugin HC3 global-variable backup, written automatically once per day. On restore, the API token is written to the QA's own internal storage only, never back into the visible ApiToken QuickApp variable, so it doesn't show up in QuickApp-variable exports. Note the HC3 global variable used for the backup itself is still plain system-wide storage - see the README for the full caveat. Requirements: - Fibaro HC3 with internet access to the Growatt Open API. - A Growatt-issued Open API token (Growatt Cloud / OpenAPI access), entered once in the ApiToken QuickApp variable. - PollSeconds between 60 and 3600 seconds (default 300). - Growatt inverter (only tested with Neo 800) (https://server.growatt.com/) Setup is just: install the QA, fill in ApiToken, optionally PlantId/DeviceSn, and enable it. Everything else (child creation, discovery, view layout) is automatic. Keeping it up to date: This QA updates itself through jgab's QA Dist Manager - https://forum.fibaro.com/topic/80052-qa-dist-manager/. Install that QA once (any of jgab's or my other QA Dist Manager-enabled apps will detect it automatically, no configuration needed). After that, this QA's Updates section gives you: - Check Update: only checks whether a newer release is available, never installs anything. - Auto Update: installs the available release automatically at the time set in AutoUpdateTime (default 03:33). - Update Now: asks QA Dist Manager to install the available release immediately. If QA Dist Manager isn't installed, the Updates section shows "QA Dist Manager is unavailable" and update checks are simply skipped; everything else keeps working normally. Full technical documentation, API endpoints used, and behavior details are in the bundled README. Feedback, bug reports, and feature suggestions are very welcome here. Source code: https://github.com/Brors94/802.Growatt-v4 Support continued development: If you find this QuickApp useful, donations would be greatly appreciated. Contributions will help cover more AI token usage while developing, testing and improving this and future QuickApps. Donate through PayPal: https://www.paypal.com/donate/?hosted_button_id=VUADCH6HQCYM2 Disclaimer: this is an independent, community-made QuickApp. It is not affiliated with, endorsed by, or supported by Growatt, Shine, or any of their subsidiaries. "Growatt" and related names/trademarks belong to their respective owners. Use of the Growatt Open API is subject to Growatt's own terms and account permissions. Thanks for reading!

I agree, zigbee is not always stable - hopefully NICE will go finally to Alpha (not Beta)

Hi, I run a SONOFF SWV (ID 260, battery-powered) for garden irrigation on Yubii Home Pro 5.210.12. Three months flawless — then two problems: Problem 1 — hub.call() fire-and-forget: After a command flood (watchdog sending turnOff 50x in 1h — my own bug), the valve stopped accepting any remote commands. Physical button and status messages still worked. Fix: batteries out for minimum 5 minutes (60 seconds not enough). Question: Has anyone found a way to make hub.call() more reliable for ZigBee battery devices? I now send turnOff 3x with 2s gaps — any better approaches? Problem 2 — Device parameters: The device JSON shows autoOffDefaultTime: 900 but the Auto-off toggle in Yubii is greyed out for this device. When the valve is open and I manually enable Auto-off, it works — but resets to off after the valve closes. Question: Is there any way to set device parameters like autoOffDefaultTime permanently via Lua (hub.call or API)? The device supports it — Yubii just won't let me activate it persistently. Setup: Yubii Home Pro 5.210.12 · SONOFF SWV · ZigBee · battery-powered

Hi, Nice/elero has a very useful feature in Yubii Home Pro: "Synchronize all devices" which forces the gateway to actively poll all devices and update their status. ZigBee has nothing equivalent. There is no network map, no forced sync, no mesh heal — and the mesh heal function that existed in older firmware has been removed. Is there any plan to re-introduce a ZigBee mesh management tool — even a basic one? Active polling or a network map would make a huge difference for diagnosing ZigBee issues. Setup: Yubii Home Pro 5.210.12, 4 ZigBee repeaters, mix of battery and mains-powered ZigBee devices.