In our first smart buildings article, we looked at energy savings, warehouse monitoring and the business case for a pilot. This one goes back to the beginning: the first technical decisions we made at RemSoft.Dev, and the lessons I would carry into a new project today.
When we started with automation at RemSoft.Dev, the temptation was to build one universal system for everything: a house, an office, a warehouse, a farm. It took a few sites to understand that this was the wrong starting point. A two-bedroom apartment and a 3,000 m² warehouse can share a philosophy while needing different architectures. Our first real decision was to split the work into tiers.
If you are starting with the business case, read Smart Buildings for Business: What Could Your Warehouse Save? first.
For small properties, wireless devices can be enough: Tuya, Sonoff, Shelly, a vendor's cloud and a mobile app. The attraction is speed and a manageable initial cost. Owners can handle some simple device replacements themselves; work on mains wiring still belongs with a qualified installer.
For a large house or a small business, we moved to a local hub, usually Home Assistant, with wired connections wherever the walls were still open. This is where we began treating the building as a system with its own logic, rather than a collection of devices and apps.
For warehouses and production sites, our default became a wired backbone: Shelly Pro devices and Modbus-connected equipment for some mid-range projects, or KNX and Loxone-based solutions where the budget and expected service life justified them. These are different technologies and ecosystems, so the final choice still depends on the equipment, integration needs and people who will maintain it.
The mistake we see most often in other people's installations is a large site built on the assumptions of a small one: dozens of wireless devices, three vendor clouds, and nobody who knows what talks to what.
If essential building functions depend on an internet connection or a vendor's cloud staying available, that dependency belongs in the architecture discussion from the start.
Our principle is local control first, with cloud services as a convenience. Specify what must keep working during an outage, then test that behavior. Installing a local hub is only part of the answer; the devices and integrations it relies on must support the intended offline operation too.
Where cables run, how many circuits reach the panel, and whether there is a neutral conductor at a switch all shape what can be automated later. These decisions are easiest to get right during construction. Software cannot substitute for missing wiring, and retrofitting it can be disruptive.
I would bring the electrical designer and the automation team into the same conversation before the walls are closed.
Sensors should not need to know which app displays their data. The interface should not need to know which protocol a relay speaks. Give each layer a clear responsibility and a defined connection to the others.
When a vendor disappears or a device needs replacing, that separation gives you a better chance of replacing one layer without rebuilding the other two.
A relay called switch_14 leaves the next person guessing. A relay called warehouse_B_lighting_row_3 gives them a place to start.
Agree on naming before the first device is mounted, then keep the device list, locations, circuit references and control relationships together. Documentation should help someone other than the original installer understand and maintain the system.
The owner of a warehouse rarely starts by asking for lighting scenes. A more immediate question is why the energy bill went up in February.
Plan metering for significant circuits and loads while the electrical design is still being developed. Installing it at that stage can avoid later rework. Combined with operating schedules and weather data, those readings give the team a way to investigate changes in consumption and assess whether adjustments actually helped.
The most useful lesson is not technical: the client does not buy sensors. They buy the feeling that the building is under control. Every architectural decision should be checked against that expectation.
Can they understand what is happening? Can someone respond when something goes wrong? Can the next person maintain it? Those questions matter as much as the device list.
In the next posts, I will go deeper into our experience with Tuya: where it works surprisingly well, where it falls apart, and what we learned about building on top of someone else's cloud.
If you are planning automation for a house, a warehouse or a farm, or you have an existing system that nobody dares to touch, get in touch with RemSoft.Dev. I am happy to talk through the architecture.
Our engineers can help map this to your stack.
