The simplest non-trivial control system in the world is the thermostat: read a sensor, compare to a setpoint, drive an actuator. Almost every climate control, lighting control, motor control, and feedback control you'll ever build is some variation on this loop. Now imagine two of them. In the same building. Knowing nothing about each other. That's how most automation actually gets deployed.
Why "independent" beats "centralized"
A naïve architecture would say: one big computer reading all sensors, deciding all outputs. It's simpler to reason about. It's also brittle. If the central computer dies, every room goes uncontrolled. If you want to add a sensor, you re-wire everything to the brain. If the wires get long, electrical noise mounts and the whole system gets twitchy.
The pattern in this demo — two Unos, each reading its own input, each driving its own output, no cross-wires — is the opposite philosophy. It's how every smart light bulb, every thermostat, every space heater with a built-in controller actually works. Each device runs its own loop. Failure of one device affects only its corner of the world.
The simulator is honest about this
When you turn Uno A's pot, Uno A's LED dims. Uno B doesn't know, doesn't care, doesn't react. There is no shared variable between the two AVR cores running in the simulator — they are completely isolated emulator instances, each with their own program memory and SRAM. The canvas hosts both but doesn't connect them. This isn't a UI shortcut; it's the actual model.
You can verify the isolation by looking at the two Serial monitor tabs. Uno A's serial output reports its own pot value, prefixed "A". Uno B's reports its own with "B". They're two separate streams. If you stop Uno A by force-killing its sketch (edit the textarea while running), Uno B keeps running. They are genuinely independent processes.
The teaching value
The most important pattern in embedded systems is: do the thing locally, and only ship out what someone else needs. A motor controller doesn't care about the WiFi state. A keyboard doesn't care about the screen brightness. Each subsystem runs its own loop at its own rate, and only when they need to talk do they talk. Two Unos on a canvas is the smallest setup that lets you see this principle work — and the smallest setup that lets you debug it when it doesn't.