Three layers, each with its own nature
The equipment. A PLC or a controller running firmware. It has one job: do the right thing right now, including when nobody is watching and nothing answers. At Vestfjord Sauna that is an Arduino Opta running firmware written from scratch, reading PT100 probes through LKM264 transmitters and holding the temperature according to which hours are booked.
The connection. Cellular, wifi or cable, and all three are gone sometimes. This layer should have no opinions; it delivers messages, and says so when it cannot.
The cloud. Where the bookings, the users, the history and the rules live. It decides what should happen, and it is the only layer that can see several devices at once.
The mistake people make is drawing this as one system. It is three, with different uptime, different release cadence and different tolerance for failure.
Decide where the logic lives, first
Split the rules into two lists before anyone writes code.
Must work without a network: upper and lower temperature limits, maximum run time, the safe state when a probe drops out, and what happens on start-up after a power cut. This belongs on the equipment, in firmware, and must not be overridable by a message from outside.
Can happily wait: moving a booking, changing a temperature on request, showing a graph, sending an alert, collecting statistics. This belongs in the cloud, where it is easy to change.
Once that split is made, the rest is craft. When it is not made, all the logic ends up in the cloud eventually because that is faster to change – and then you have a heating system that stops working when the mobile network does.
Sensors lie sometimes
A temperature reading is not truth; it is a signal with noise, drift and occasionally pure nonsense. A probe wire working loose tends to produce a value that looks perfectly plausible.
In practice: know the measuring range, discard what is physically impossible, filter rather than react to every reading, and do something sensible when the value is missing entirely. It is also why good probes are read through a transmitter – PT100 elements are accurate, but the signal is small, and the transmitter makes it robust enough to survive a cabinet and a cable run.
Locks do not behave like other APIs
An access integration looks simple and is not, because the consequence of a fault is standing physically in front of the door.
Codes are time-boxed, and “time-boxed” means the clocks have to agree. Some locks are reachable directly, as igloohome are, while others are reached through a platform such as Inlet when you need several brands in one system. And whichever provider you use, you need a plan for the guest standing outside with a code that does not work – usually a human fallback and an alert to somebody who can act.
What a delivery looks like
- Survey. The datasheets, not the brochures: which inputs, which protocols, which APIs, which limits.
- One device, end to end. One measurement up and one control down, in operation, with a log. Everything else is easier once that chain works.
- The rules in place. Firmware logic and cloud logic written separately, with the failure cases written down.
- Field time. The equipment in a real place for a few weeks, monitored. This is where the faults appear.
- Handover. An update path, documentation, access, and monitoring that tells somebody before the customer does.
Vestfjord Sauna runs that whole chain today: booking and payment from a phone, a lock that opens at the right time, and a heater driven by the bookings while a PLC holds the temperature whatever the weather.
If you have something physical that ought to hang together with your system, describe it in the Living Brief – you get an architecture sketch, phases and a range in weeks straight back.