[foepys]

OpenWISP states in its docs that you should be running at least 20 devices to make it worth it. [1] So it's not supposed to be a easy way to manage a few devices for home users.

> However, OpenWISP may not be the best fit for very small networks (fewer than 20 devices), organizations lacking IT expertise, or enterprises seeking open-source alternatives solely for cost-saving purposes.

1: https://openwisp.org/faq/#suitable

[rubenbe]

It's for exactly that reason I started with OpenSOHO. It is targeted towards the typical home and small office network with less than 20 OpenWRT devices. (although there is no hard limit).

https://github.com/rubenbe/opensoho

It is still a work in progress, but it is easy to deploy (one golang binary based on pocketbase)

[pseudosavant]

Very interesting project! I was thinking of something that would fill this gap.

Based on your experience, as OpenSOHO seems to use OpenWISP, what do you wish you knew about OpenWISP before you started this?

[rubenbe]

Initially I fiddled a bit with full Open wisp stack to try to make a smaller edition. But I quickly stopped that. But I know their two daemons well.

The config one is a neat little piece of software. It will merge UCI configs and check the connectivity. You can adjust virtually any file with it (although not always with merging). My main issue with it is that it can't be easily temporary disabled from the central controller (I currently implement it by not sending the config, but that triggers retries on the AP end)

The monitoring one spits out an amazing amount of data, although it needs some post processing to make it actually useful. Unfortunately that one can't be extented to add custom entries. I'm currently missing an easy way to see which MAC address is connected which LAN port since OpenWRT DSA puts everyone one the "br-lan".

The whole thing is polling based. So it is quite chatty on the network since I use lower polling rates to make the updates fast. (I suspect on a setup with 100+ you will have longer polling times). All in all the existence of these daemons saved me a ton of time handling networking corner cases. Kudos to the Openwisp team.

[pseudosavant]

I had a GPT-5 agent help me think through a pull-only controller/agent model for OpenWRT. The controller keeps desired configs in git and serves the current version as a tiny tar/zip over HTTP(S), using the last commit ID as the ETag. Agents poll every ~5s with If-None-Match, so it’s usually a 304 and near-zero overhead; when the version changes they fetch the archive and apply it. The controller location is advertised via DHCP; no long-lived sockets or SSH push.

On the device side, the agent only activates if there’s no WAN (so the main router isn’t a client). A new AP gets a LAN IP via DHCP, discovers the controller, pulls its config, and if none exists the controller can hand back a default Wi-Fi setup to come online immediately. Start with Wi-Fi-only changes (reload instead of reboot), aim for a “plug into LAN + power and it just joins” UX, and avoid OpenWISP complexity. It’s built from boring, reliable primitives: DHCP, HTTPS, git, tar, Lua.

I think I'm going to have an agent start coding this up today and see where it gets.

[rubenbe]

Nice idea!

I do notice quite some people focus the autodiscovery part where for me that's less of an issue (I do agree it would be VERY nice). The OpenWISP configuration on each AP is limited to: set IP address of controller & shared secret and click OK. The rest is all magically done for you by the controller.

I do like the 304 idea, in practice it uses the same conceptual idea as the OpenWISP system: check if the MD5 (instead of SHA1) for the current config and the controller config are still identical and download and apply if not.

An important reason I why chose the OpenWISP is that they "just work", are well tested and included in the OpenWRT package list. My main goal is to keep the OpenSOHO project as small as possible ;)

[pseudosavant]

I've been weighing the pros/cons of using OpenWISP. I considered using DHCP to distribute the controller IP and shared secret.

For now, I like reasoning about /etc config files. I'm more familiar with those than OpenWISP. Adopting an abstraction like that offers some portability and possibly future proofing. But that is just the config format and how it is applied though really.

I think once the router is setup, most SOHO users only ever have to add/replace (provision) APs and manage the WiFi settings. I want to make that kind of provisioning and management automatic. Making the APs as stateless as possible - kind of like a Chromebook. The agent will only have basic dependencies (lua, curl, tar).

For this to really work it'll probably have to grow to support VLAN-backed SSIDs and wireless backhaul links. Wireless links would probably need to be wired for their first time setup. But I'd be happy even if it just solved managing my own APs and SSIDs.

[CursedSilicon]

This looks a lot closer to what I'm after. Bookmarked the git repo :)

[CursedSilicon]

I saw that. Admittedly I'm only interested in a few of its functions. Namely roaming and guest hotspots

I could wire up all of that manually. But I'm excited for the chance to learn something new