But/and… I do made some progress I found.
After clicking the homey.views.js away I was able to partially add the ugreen. 2 parameters (CPU/MEM) were added in insights. No devices, no flows, etc etc.
I recommend removing the address bar part from all of your screenshots, they contain your Homey Cloud ID, a unique identifier allowing anyone to reach your Homey remotely
First of all, I am really sorry for the late reply! I have been working hard to figure out this issue since your last message.
To reproduce and fix the bug, I am running the app under the exact same scenario and setup as you do. However, since my technical knowledge in this specific area was a bit limited to solve it completely on my own, I reached out and asked for help from two of my friends who are much more professional and experienced in this field.
We are currently working on it together, and I truly believe that we will have this issue completely sorted out over the weekend. As soon as the new test version is ready and deployed, I will immediately tag you here so you can test it.
Thank you so much for your patience, continuous support, and great feedback!
Quick update: I’ve tracked down and fixed the pairing issue reported here (Error 409: Another pair session is already active / Invalid Pair Session ID, missing elements on the pairing screen), which mainly showed up on self-hosted or reverse-proxied Homey setups (e.g. behind Nginx Proxy Manager / a custom domain, like @Alex_Bloemendal’s case).
Root cause: the pairing screen’s script was calling into the Homey SDK before it had actually finished initializing. On slower or proxied connections, that race condition could fail silently and leave the pairing session stuck open on Homey’s side — which is exactly what caused the 409 / invalid-session errors on retry. I’ve rewritten it to use the standard onHomeyReady() entry point, and added a 20s client-side timeout so the “Connecting…” button can no longer get stuck forever if a request hangs.
While I was in there, I also fixed an inefficiency where the app was opening a brand new HTTP connection to the NAS on every single request (including every 10s poll) instead of reusing one — this should make things noticeably more reliable for anyone running their NAS behind a reverse proxy too.
Both fixes have been tested live against a real Ugreen NAS and are running stable.
This is submitted as v1.2.6 and currently pending Homey certification. If you’ve been affected by the pairing issue (especially self-hosted/reverse-proxy users), it’d be great if you could try the test build before it goes live and let me know how it goes:
Thank you for the screenshots and the diagnostics report — they pointed me straight to the problem!
Root cause: The pairing screen was loading the Homey SDK script with a wrong data-origin value (views instead of pair). The my.homey.app web client uses that value to decide which SDK bundle to load, so it tried to fetch a file that doesn’t exist (/js/homey.views.js) — which is exactly the error in your screenshot. That’s why the pairing screen never initialized, no matter what. This mainly hit users pairing through the web client (my.homey.app), which is why it kept slipping past my own tests on the mobile app.
I see you have auto-update enabled for the test app, so it may already be on your Homey — just check that the app shows v1.2.7 before trying. Then simply try adding the device again via my.homey.app.
Homey dump: c42d973e-8cd1-4c13-bfd2-39764aa0240c
(note: not at home yet, and will not be for the next comming days; so still not able to give you any backend log-file-entries).
Great app; the setup went smoothly, too. I would really like to have another Flow card, though—specifically a “Then” card. I’d like to turn off my NAS when I go to sleep. It would be cool if you could add something like that.
@Alex_Bloemendal — thank you, that second screenshot was the missing piece of the puzzle! Your test actually proved v1.2.7 did what it was supposed to (it now looked for the right file), but it revealed the real root cause underneath: according to the current Apps SDK documentation, a custom pairing view should not include the /homey.js script at all — the Homey object is injected automatically by every client. That include is only meant for app settings pages. On regular setups the extra include was harmlessly tolerated, but your Homey Self-Hosted Server doesn’t serve the /js/homey.pair.js file it requests — hence the error you saw. I’ve removed that include completely, and the pairing screen now uses the injected Homey object directly, with a safety net that re-checks right when you press “Login & Add Device” — so the “Still connecting to Homey” dead-end is gone too. Just make sure the app shows v1.2.9 before trying, then add the device again via my.homey.app — whenever you’re back home or have remote access, no rush at all. Since this was the last gap between your setup and the SDK’s intended behavior, I’m quite hopeful this one does it. Thanks again for your patience through these iterations!
@wepa — thank you for the kind words, and great suggestion! v1.2.9 also brings two new “Then” Flow cards:
Shut down the NAS — exactly for your use case, e.g. power off the NAS when you go to sleep
Reboot the NAS — added while I was at it
One small heads-up: after a shutdown you’ll need to power the NAS back on manually or via Wake-on-LAN, so keep that in mind when building your bedtime Flow. Let me know how it works for you!
Wow, that was fast. Awesome, thanks. And it works exactly the way I wanted—including restarting via WOL. I’ve got another idea for an “AND” condition, though: checking if a backup is currently running (if that’s even possible) and only shutting down after the backup is complete.
Great to hear it works exactly as you wanted — including the WOL restart! And another good idea, thank you.
I looked into a true “backup is running” check, but UGOS’s local API unfortunately doesn’t expose the backup task state (I verified this against every community reverse-engineering project of the UGOS API). So I went with the next best thing, which in practice catches exactly the same situation: a running backup always shows up as sustained disk and/or network activity.
v1.3.0 is now on the test channel with three new “And” condition cards:
Disk activity is (not) above X kB/s — read + write combined
Network activity is (not) above X kB/s — download + upload combined
CPU usage is (not) above X % Ugreen NAS | Homey
For your bedtime Flow you can use: WHEN it’s bedtime AND Disk activity is not above 500 kB/s THEN shut down the NAS. If your backup runs over the network, add the network card too. Let me know how it works for you!
I’m sorry that I haven’t been very active here over the past month.
About a month ago, I fractured my right wrist. Since it is my dominant hand, using a computer and working on the app has been quite difficult. Because of this, I unfortunately haven’t been able to keep up with the forum or respond to your messages as I normally would.
I’ve now seen the recent posts and feedback, and I’m recovering well. I’m planning to go through the reported issues and requests this coming weekend and start working on them.
Regarding the request for German translations for the Flow cards: unfortunately, I don’t speak German myself. I could of course generate translations using AI, but since I wouldn’t be able to properly verify whether the translations are accurate and natural, I don’t currently plan to add German translations. I would rather avoid adding translations that I cannot personally validate.
Thank you very much for your patience, understanding, and for continuing to test and support the app. I really appreciate all the feedback, and I’ll start catching up with everything this weekend.
Thanks for your patience while I was recovering — my wrist is much better, and I’ve now worked through the reports from the past weeks. v1.3.5 is available on the test channel:
Fixed: login failing on accounts with two-factor authentication
@byackee1 — this was your issue. Your NAS answered with “The client is not compatible with the firmware, please update the client!”, which is misleading: it is not a firmware or version problem at all. UGOS rejects the login when the app doesn’t opt into the two-factor handshake, and your account has 2FA enabled. That is now handled properly: if your account uses 2FA, pairing asks once for a code from your authenticator app, and Homey is then registered as a trusted device on the NAS — so you won’t be asked again. Please give it a try and let me know how it goes.
New: “A backup task is running” Flow condition
@wepa — this is the check you originally asked for, and I owe you a correction. I said earlier that UGOS doesn’t expose the state of backup tasks. That was wrong: it does, and the app now reads your Backup Center tasks directly. So you can build exactly what you had in mind: WHEN it’s bedtime AND a backup task is not running THEN shut down the NAS. The activity-based cards from the previous test version stay available for setups that don’t use Backup Center.
New: Repair
If the connection ever stops working — after a password change, or when 2FA is enabled on an account that was added earlier — you can now use Device settings → Repair to sign in again instead of deleting and re-adding the NAS. Your Flows and Insights history are kept.
Also in this release: the app now identifies itself properly to the NAS.
If this version works well for you, I’ll submit it for certification so it reaches the stable channel. Feedback before that is very welcome — thanks again to everyone testing and reporting.
And another good idea, thank you.
