Repository navigation
Replies: 3 comments
|
Update from this side: your HTTPS port migration fix is now merged as #1226, cherry-picked from your develop branch with you as co-author. Your tests for it pass unchanged on our tree, which made the whole thing trivial. That was the patch your FORK.md lists as generic and worth offering. The other small groups look just as offerable whenever you feel like opening PRs:
Self-contained PRs for any of those are welcome. The UniFi offer above stands, too. |
|
Follow-up: with no answer in a week we went ahead and integrated your three groups ourselves - #1333, just merged. Your authorship is preserved end to end: the four commits carry your name and the squash carries the Co-authored-by trailer. DHCP reservations, mDNS host records and the vendor/matching rework (camara via OUI, Xiaomi by name, whole-word short tokens) are in; agents carry them as of 3.0.15. Conflicts against the current tree resolved keeping the newer classify work (cctv/aspirador/videoportero types). The UniFi offer from this thread still stands whenever you feel like it. |
|
A full review of your UniFi integration from this side (all 14 commits: client, adapter, http layer, settings, tests): the quality is genuinely high. Read-only client, password never leaves the server, cached inventory that survives a controller reboot, and the topology seal follows the same shape as the Proxmox one we merged in #940. It would fit the codebase well. The honest blocker on our side: none of us runs a UniFi controller, so we cannot test it end to end - and your branch is now ~150 commits behind, so the touch points (live.go, Settings, the integrations hub) have moved. A straight cherry-pick would not land clean. So here is the offer: if you bring it as a PR against current main, we will review it fast and work with you on the one real mismatch - your settings card vs our integrations hub (#968), which needs a server-side on/off toggle the integration does not have yet. You run this daily; a PR from you lands tested. If we do not hear from you by 28-Oct, we will integrate it ourselves, the same way as #1333: adapted to the hub and to current main, with your authorship preserved end to end (Co-authored-by), and documented as community-maintained. |
Uh oh!
There was an error while loading. Please reload this page.
First-class UniFi controller integration (read-only): turn APs/switches managed by a UniFi controller into NetPulse-visible devices, seal the topology past the router with the controller's view, and configure it from Settings (the password stays server-side).
There is a complete, production-tested implementation in the community fork borky/netpulse@develop: 13 commits (read-only controller client, one node per device, settings endpoints + form, topology sealing, agent-kind fixes). The fork's own FORK.md marks the whole group as "offer upstream: yes - generic".
@borky - your UniFi series looks excellent and clearly written to be offered upstream. Would you like to open a pull request? You run it against a live controller, which we cannot test ourselves (no UniFi hardware), so you answering UniFi bug reports would make this sustainable. If you prefer, we can cherry-pick the series ourselves with attribution - either way, thank you for the work.
Moved from issue #944 to keep the issue tracker for bugs and in-flight work. Originally posted by @gnacho.
All reactions