Considerations (updated 03/2026) #35
Tom-Bom-badil
started this conversation in
(en) devs
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Edit: All done. Time to mark this old discussion as 'solved' and close it.
Last edit/update: 2026-03
Edit/update: 2025-12
Original post 2025/06:
After testing the revised integration submitted by @dobby5 over the past two days, I'm still stunned by the excellent code quality and readability. Sincere thanks again for that, dobby! 😊
That said, a few thoughts came to mind -let’s say inspired by lessons learned from similar projects in the past- while digging deeper. We didn't communicate the way ahead between the dev's so far, so here are my items I am thinking about:
Fallback token:❌ Not needed anymore - separate Docker container became obsolete in v2025.10It would be great if the config flow could offer a simple fallback token input (a string the user can copy/paste from the browser the old-fashioned way), which would be used in case regular token renewal fails. I absolutely appreciate the elegance of the always-updated token system through the container, but I’m 100% certain this will be the main source of support requests from end users.
[ Side note: ] I can do that and also do the documentation, if ok for dobby, just confirm.
Polling frequency: ✅ Done
Based on my experience from other integrations, this is a tricky one. The typical “triggerfinger” user expects instant updates. We should consider whether it's possible to split off CPU/RAM/Temperature queries (those items that change rather quickly) into a separate coordinator and run that every 5–10 seconds instead of every 60s (I am almost certain that is what the UGreen App is doing as well).
Multi-NAS support: ⌨️ Roadmap 2026 ✅ Done
I noticed that the integration already allows adding more than one NAS (perhaps by design, perhaps not 😄). Just add the same device again to find out. In two of my other HA integrations, refactoring to support more than one endpoint would require HUGE efforts, because each instance would create the same entity names - BIG drama.
On the other hand, I’ve seen several users (on Discord, Facebook, etc.) already owning more than one Ugreen NAS - and the number is growing. We may want to address this before things become too complex down the road, and consider the specific device in the name of the entities (or some other solution for this - like e.g. replacing the currently fixed 'UGreen_NAS_' with the name of the device etc).
Just my two cents - really looking forward to your thoughts, discussion very much welcome. 😊
/tom
All reactions