anyone have extended thoughts using this (DMS?) vs Noctalia? i’ve been running a Noctalia fork for like a year now and I’m quite happy with its development. easy to upstream PRs too!
depends on when that fork happened. noctalia v5 moved away from quickshell and is way more performant and lightweight than DMS even if a bit more limited in what you can do
You can (and should) just segregate your network to have separate paths for IoT/"smart devices" and normal personal/family devices. Makes it all worry free and transparently observable.
I have my IoT on a separate VLAN and I can observe communications for any given device at any given time.. this seems like a much saner solution than outright not buying any IoT devices, though that is also a respectable decision!
It's so important to have a dedicated VLAN (or 2.4g SSID) for IoT devices and block access to your regular VLAN/SSID or enforce some more granular rules on what devices can communicate with each other.
Most non-ancient routers/gateways support this. There are way too many IoT devices running code that's _worse_ than what older LLMs produce.
I agree on the coffee machine. On the thermostat, not so much. We keep pretty irregular hours so being able to control the thermostat remotely, so the house isn’t being heated unnecessarily but is warm on our return, is useful.
It's smart and supports only Z-Wave, not WiFi. So something like a machine running Home Assistant must sit between it and the Internet. And then its up to you to decide how you want to do remote access, but WireGuard overlay networks (e.g. Netbird, Tailscale) basically solve that problem at home-user scale.
This. We should buy Z-Wave or Zigbee as much as possible (Matter over WiFi/Thread can access the internet, so are out) to grow that market. Both are completely disconnected from the internet and you decide how such devices can be accessed.
Reject all the WiFi-connected stuff, unless it's very user-centered and worst case you can upload your own firmware (e.g. a bunch of Shelly devices).
That said, getting a Zigbee or Z-Wave thermostat and have Home Assistant or similar control it is a better option that buying a surveillance-ready WiFi-enabled one.
> Coffee machines don't need internet. Your thermostat doesn't either.
reply
Yours may not, but that's just your personal preference. A lot of folks enjoy these products. An argument could be made that no one needs a coffee machine or thermostat to begin with.
You're about 35 years behind the times about people networking their coffee machines [0]. People might want to know the status of the pot (the OG example), how their ground/bean coffee supply is, or the ability to trigger a coffee or water boiling before they walk to the machine. My coffee making process is entirely manual, and I like it that way, but I can at least see how there are some features that could be nice.
It's not enough to simply have a IoT VLAN that you put all your IoT devices on. Because those devices can see one another. In this case, if the coffee machine can see what type of smart fridge and smart toaster you're using, they can sell that data.
I default to adding IoT devices to a 2.4g "Guest" network where they can't see each other. Exceptions are IoT devices that need to see their friends to do what I bought them for, or devices I want to integrate with HomeAssistant. In those cases I create a separate IoT device per IoT brand. Excessive but necessary.
In those cases I create a separate IoT device per IoT brand.
That requires a lot of SSIDs though and AFAIK it reduces airtime for each SSID on the same router (which may be bad if you also use 2.4GHz for your regular devices).
So far two separate VLAN + SSID (IoT-Good and IoT-Bad) with client isolation on IoT-Bad has worked pretty well for me. In some cases mDNS advertisements have to travel at least from the IoT VLAN to the VLAN HA is on for the devices to be discovered.
There's ways to reduce the expense like changing DTIM interval (for less-frequent broadcasts) and increasing base data rate. Few folks in 2026 have anything at home that requires the 1Mbps base rate of 1999's 802.11b anyway, and slower DTIM can have other advantages, so these tend to work well at increasing available airtime for more SSIDs.
There's an additional trick that can also be used, though: Wifi client isolation. This lets the IoT widgets share an SSID and VLAN with which to talk to the HA machine and/or their cloud-based mothership(s) or whatever, but without being able to see eachother on the SSID.
It still needs set up right lest stuff walk right by it, but it's an available feature.
A smart coffee machine may need to talk to some kind of controlling endpoint (whether local or afar) in order to do whatever it does. It does not need to be able to enjoin in a conversation with my light bulb in order to get there. But that doesn't mean that they can't share an SSID. :)
There's an additional trick that can also be used, though: Wifi client isolation. This lets the IoT widgets share an SSID and VLAN with which to talk to the HA machine and/or their cloud-based mothership(s) or whatever, but without being able to see eachother on the SSID.
Indeed, this is what I do on our home network. I have two IoT SSIDs. One with devices I generally trust, where mDNS proxying is enabled and another that is excluded. I've found that the worst devices are generally not locally controllable anyway and always want to go through the cloud, even when you control them through HA or your phone.
I hope to be able to find the time and motivation to re-do the wifi stuff at home this weekend. I'll try to adopt the good-and-bad model of having two IoT SSIDs.
Takes some getting used to: Only fill to the escape valve (3/4 of the way up, you can see it from the inside), fill with boiling water from the kettle, put it on a low heat, turn off the heat as soon as it starts to gurgle.
I have a firewall that tells me how much data each device is uploading and downloading. One particular device pulled down 6GB a week and uploaded 1.5GB doing absolutely nothing. I mean literally nothing, I use the local API to communicate with it. Blocking the one domain it was doing this to dropped traffic to essentially zero with no loss in functionality.
reply