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!
And another good idea, thank you.
