Hub vs Device: Where Automation Logic Should Live

The real question is not whether a hub or a device is smarter. It is what must still happen after the hub reboots, takes an update, or loses the network. The short answer is firm: local automation logic owns safety and property protection; the hub owns convenience, schedules, dashboards, and coordination.

Use a humidity-controlled exhaust fan as the test case

Take a small enclosure with a humidity sensor, an exhaust fan, and a hub that can send notifications. The desired outcome is ordinary: run the fan above a humidity threshold, stop it after the air recovers, and tell you if the condition persists.

That sounds like one automation, but it contains two different jobs:

• The fan control loop decides whether the enclosure needs ventilation.
• The hub coordinates that result with other devices, schedules, alerts, and user controls.

Those jobs have different failure consequences. If a notification is late, the system is inconvenient. If ventilation stops while condensation is building, the enclosure, stock, electronics, or finish may suffer. If the fan is protecting a person from heat or fumes, the split is even clearer.

We would put the threshold, hysteresis, minimum run time, sensor-fault response, and any hard cutoff on the device. The hub can mirror the state and add useful behavior around it, but it should not be the only thing deciding whether the fan runs.

A control loop running on the device continues regardless of what happens to the rest of the system. By contrast, automation on a hub stops working when the hub restarts, updates, or loses the network.

Compare hub control, device control, and the split architecture

Do not confuse a relay command with current protection. A relay rated for a fan's running current may still be unsuitable for its inrush current, inductive behavior, switching frequency, enclosure temperature, or fault conditions. A mains load also needs the correct isolation, fusing, clearances, earthing, and enclosure treatment for the voltage and installation method. A low-voltage control board does not make a mains circuit safe by itself.

For a low-voltage fan, the device can usually switch through a suitable transistor or relay stage selected for the actual fan current and startup behavior. For mains equipment, use a properly rated switching component and follow the applicable electrical requirements rather than treating a hobby relay board as a finished safety system.

Put property consequences in the device

The local firmware should own decisions that have a defined safe state. That includes:

• Over-temperature shutdown for a heater, driver, or enclosure.
• A maximum continuous run time for a motor or fan.
• Sensor-out-of-range behavior, such as stopping a heater rather than trusting an impossible reading.
• Current or load fault handling where the hardware can measure it.
• Hysteresis so a fan does not chatter at the threshold.
• A startup state that does not energize a hazardous output until the inputs are valid.

The exact values belong to the hardware and process. A heater cutoff depends on the heater, enclosure, sensor placement, material limits, and the consequence of overshoot. A fan's current limit depends on the motor and switching stage. A humidity threshold depends on the material and the allowable moisture level, not on a universal number.

For a device controlling temperature, measure the actual thermal response instead of guessing from the sensor specification. Log the temperature at a known sampling interval, record the time from output change to measured response, and test the worst credible ambient condition. Then set the cutoff below the material or component limit with enough margin for sensor error, placement error, and overshoot.

Hysteresis is equally practical. If the fan starts at one humidity threshold and stops at the same threshold, noise and small environmental changes can make the output cycle rapidly. Use separate start and stop conditions, then verify the cycle time with the real fan and enclosure. The right gap is the smallest one that prevents chatter while still controlling the condition.

The hub can still expose the threshold, but a hub-adjustable value should not be allowed to remove a device-side limit. A useful pattern is a local hard ceiling plus a hub-requested operating point. The device accepts the request only inside a bounded range.

Leave coordination and convenience on the hub

A hub is the right place for behavior that can wait, retry, or be absent without creating a hazardous condition. Examples include turning on a status light, sending an alert, changing a dashboard tile, coordinating several rooms, or applying a schedule.

This is also where cross-device logic belongs. A humidity sensor can tell the hub to show a warning, while the fan continues to follow its local loop. The hub can request quiet hours, but the device can reject that request if its temperature or humidity limit is active. A manual command can request a run, while the device still enforces its maximum runtime.

Treat hub commands as requests, not unquestionable instructions. The device should report at least:

• Current measured value and sensor validity.
• Output state and the reason for that state.
• Local fault or cutoff status.
• Firmware or configuration version.
• Last accepted hub command, if command history matters.

On reconnection, decide explicitly whether the device keeps its local state, accepts a new command, or requires an operator reset. An automatic restart into an energized state is a design choice, not a default you should inherit from a library.

Decide by quantity—and test the architecture

For one benign prototype, hub-only control is often good enough. That is the against-our-own-interest answer, and it matters. If the fan is only moving air across a test piece and a missed cycle cannot damage anything, building a complete local controller may waste more time than it saves. Do not buy another controller or add a custom board until the failure consequence justifies it.

The answer flips when the device is repeated, unattended, hard to reach, or protecting something costly. A local controller adds firmware, test fixtures, documentation, and a way to update it. Those costs are real at one unit. With repeated units, the same local behavior can be tested once and deployed consistently, while a hub-only design keeps every node dependent on one shared failure point.

There is no honest universal quantity at which the flip occurs. Estimate it from the work your design requires:

1. Count the hours to implement and test the local loop.
2. Count the per-unit hardware and assembly added by that design.
3. Estimate the cost of a failed or missed control event.
4. Multiply hub-side commissioning and recovery work by the number of nodes.
5. Add the cost of maintaining a shared automation that must understand every device state.

If the consequence of failure is safety-related, quantity is not the deciding factor. The rule applies to one unit. If the consequence is only a notification or a convenience action, the hub is usually the economical choice even at a larger quantity.

Do not validate only the happy path. Run the device while deliberately breaking the communication path:

• Restart the hub while the local condition is above the threshold.
• Disconnect the network without removing device power.
• Let the sensor cross both sides of the threshold during the outage.
• Remove or invalidate the sensor if the hardware supports that test safely.
• Restore communication and check whether a queued command creates an unsafe state.
• Remove device power and verify the defined startup output state.

Record timestamps for the sensor reading, local output change, hub state change, and alert. This separates sensor delay from network delay and exposes a rule that appears reliable only because the test never included a restart.

The final acceptance test should be based on the consequence, not the dashboard. If the enclosure stays within its allowed condition during a hub outage, the architecture is doing its job. A green app tile is useful evidence, but it is not a safety function.

Frequently asked questions

Should every sensor have local automation logic?

No. A sensor that only feeds a dashboard or sends a non-critical reminder can report to the hub. Put the decision locally when a missed, delayed, or incorrect command can harm a person, damage property, or exceed a component limit.

Can a hub still change a device's local threshold?

Yes, within limits. Keep a device-side minimum, maximum, timeout, and sensor-fault response that the hub cannot override. Log accepted configuration changes so a later failure can be traced to the actual operating values.

Is device-only control better than hub control?

Not for coordination. Device-only control works well for the immediate loop, but it becomes awkward for schedules, scenes, alerts, and relationships among many devices. The split architecture is usually the best fit: local control for consequences, hub control for coordination.

The Boss Factory builds custom electronics and smart home integration work to order through [/quote].