The starting point
An ordinary house in Sovata with a solar installation and a battery, two air conditioners, its own network, cameras and a storage server. Nothing exotic — exactly the kind of household we build for.
The problem was just as ordinary: everything had its own app. The inverter in one, the climate control in another, the cameras in a third, the network in a fourth. Nothing knew about anything else, so nothing could be automated in response to anything else.
What we were after
One interface for everything, running inside the house. No subscription, no dependence on a provider, no data sent out.
And one hard criterion: every integration has to work without the internet. If a device can only be commanded through the manufacturer's server, either we find a local route to it or we replace its module.
The architecture
Home Assistant runs as a virtual machine on a Proxmox host in the house. Beside it, in separate containers, sit the network services. The separation is not fussiness: a Home Assistant update must not be able to leave the network without its controller, and a Proxmox snapshot rolls a bad update back in minutes.
The solar inverter is read over Modbus, directly. Around 230 entities come from it: instantaneous production per string, battery state of charge, import and export separately, EMS mode, temperatures. One device, and yet the richest source of data in the house — and the basis for every energy automation.
The air conditioners are commanded on the local network, on their own port, without the manufacturer's server. The factory account is used exactly once, to extract the device key; after that no link to the outside is needed.
The network controller comes in as a presence source: known devices on the network tell the system who is home, with no tracking app needed on anyone's phone.
A real piece of debugging: the air conditioner that handed out addresses
At some point devices around the house started receiving the wrong network addresses. Not all of them, not always, and not in the same way — the kind of fault that is easily blamed on “the network” and stays unexplained for years.
The source turned out to be the factory Wi-Fi module in one of the air conditioners. It was running a DHCP server of its own, handing out addresses from outside the range configured on the router, with a two-hour lease.
The part that makes the fault hard to catch: the module forged the server identifier, putting the router's address in it. The protection in the network controller, which is meant to block precisely this, decides on that identifier — so it saw a legitimate server. We left it enabled, because it does help against a server that does not forge, but here there was nothing it could do.
The measurement was a DHCP query sent from the host with a randomly generated hardware address. Two offers in the reply means the source is still live; a single one, from the router, means it is resolved. The random hardware address matters: with the tool's built-in default the measurement can return a false negative. The source itself is identified by listening to DHCP traffic on the network interface.
A factory reset fixed nothing — and we measured that rather than assuming it. After a full reset and re-registration the server was still running; only its internal range counter had moved, so it handed out different addresses, with the same lease time and the same forged identifier.
Both units ran the same firmware version, and yet only one behaved this way. The manufacturer prefixes of their hardware addresses differed, which points to different hardware revisions. The indoor unit has no network interface, so the server could only be running in the Wi-Fi module itself.
The fix has two parts. In the short term the devices that matter were given fixed addresses: a device with a fixed address never asks DHCP, so the forgery cannot reach it. In the long term the factory module is replaced with an open, ESPHome-based one that needs no cloud — solving the network problem and the dependence on the manufacturer's account with the same part.
What we did not do: block the device in the network controller. The block would have applied at the access point and cut the local control port along with everything else — the unit would have gone “unavailable” in the system with no error message explaining why. The symptom would have vanished and been replaced by a harder one to diagnose.
The result
One dashboard for solar, climate, network and cameras. Automations that lean on each other: the battery charges from the surplus, the water heater starts when production is high, and the air conditioning does not cool empty rooms.
And — most important for what we sell — all of it works with the internet cable unplugged. Remote access and notifications are lost; everything else carries on.
What we learned
The factory module is the weakest part of a good device. The air conditioners work faultlessly; the problem was the ten-euro Wi-Fi card inside them. Since then, with any device, we look first at what its network module does rather than what the datasheet promises.
Measure, do not assume. The factory reset “should have” fixed it. It did not, and only the measurement afterwards showed that. Assuming would have cost us weeks.
A fixed address is a defensive tool, not just tidiness. A device that never asks cannot be given a wrong answer.
And the reason we write this down: if a system is not documented, last year's fault gets diagnosed from scratch all over again. That does not happen here, because it is all written up — which is why you get the documentation at handover too.