Mini Project: Hallway Plus Office, Your First Layered Smart Home Logic

Mini Project: Hallway Plus Office, Your First Layered Smart Home Logic

Module 11 · Lesson 10

Every single concept from this module, triggers, conditions, actions, modes, delays, and debugging, finally comes together in one genuinely real mini project spanning both your hallway and your office. This lesson closes Module 11 by building three coordinated automations, one careful rule at a time, exactly as this entire course has consistently approached everything else so far.

The entity set for this mini project

Gather together everything this module and the two modules before it have built, your hallway motion sensor and ESP32 LED, your ESPHome button, your Zigbee smart plug, and your office temperature sensor. If any single entity is genuinely missing or was quietly renamed since it was first introduced, pause here and confirm its exact entity ID in developer tools before continuing further, since every automation below depends entirely on referencing these correctly from the start.

The final rule: build one automation at a time

Resist the temptation to build all three of this lesson's automations back to back before testing any single one of them, this module has repeated the one-thing-at-a-time principle deliberately and consistently, and a mini project combining several entities is exactly where skipping it causes the most genuinely confusing problems. Build the first automation completely, test it thoroughly and patiently, and only then move on calmly to building the second.

Automation 1: evening motion, LED, 30-second delay, restart

Rebuild this module's signature hallway automation one final time, motion triggers the LED on, a condition restricts it to evening hours, a 30-second delay turns it back off, and mode is genuinely set to restart. Every piece of this automation has already appeared individually across earlier lessons, this is simply the first time all four pieces exist together inside one single, complete, working automation.

Automation 2: the button toggles LED or smart plug

Wire your ESPHome button as a manual override, a single press toggles the LED, while a genuinely distinct long press, if your button configuration supports one, toggles the smart plug instead. This automation deliberately gives you manual control that coexists peacefully alongside Automation 1's automatic behavior, exactly the manual-plus-automated pattern this module has emphasized since its very first lesson.

Automation 3: office temperature threshold signals the LED

Trigger off your office temperature sensor crossing a genuinely meaningful threshold, and rather than controlling the plug directly, have this automation briefly flash the same hallway LED as a simple, low-stakes visual signal that the office needs attention. This cross-room connection is deliberately the most novel part of the entire mini project, one room's sensor genuinely, directly affecting another room's indicator.

Mapping how all three rules genuinely cooperate

Sketch a simple diagram in your notebook, three boxes for the three automations, with arrows showing which entities each one reads from and which it changes. Notice that the LED is genuinely shared across all three automations, which is exactly why understanding modes and the loop trap from earlier lessons matters so much right here, several automations touching the exact same entity is a considerably more advanced situation than any single automation running entirely alone.

A contingency plan if the LED starts misbehaving

If the shared LED ever starts flickering unexpectedly or behaving in a way none of the three automations seems to fully explain, disable all three immediately from their three-dot menus, then re-enable them one at a time, testing thoroughly after each single one, to isolate genuinely which specific automation, or which specific combination of them, is actually responsible for the odd behavior.

A documentation table for all three automations

Extend your notebook's automation table with rows for all three of this lesson's automations, name, trigger, condition, action, mode, and delay, exactly the same columns this module has been building toward since Lesson 6. A complete table at this point genuinely represents your entire automation setup at a single glance, considerably more useful and reliable than trying to remember every detail from memory alone.

A closing checklist for Module 11

Before considering this module genuinely finished, confirm all three mini project automations are enabled and tested, confirm your notebook table is fully up to date, and confirm you can genuinely explain, out loud, in one plain sentence each, exactly what every single automation you've built throughout this module actually does.

How to genuinely disable an automation, revisited

As a quick refresher before the module closes, open any automation and use the toggle in its three-dot menu, or the toggle directly on its card in the automations list, to disable it instantly without deleting any of its underlying configuration. This is genuinely the safest first response to any unexpected behavior, considerably safer than editing a still-active automation while it might unexpectedly fire again mid-edit.

What genuinely does not count as finishing this module

Simply reading through this module's lessons without genuinely building anything real does not count as completion, nor does building automations you've never actually tested carefully with real triggers. Module 11 is finished only once all three mini project automations exist, run correctly when tested, and are properly documented in your notebook exactly as this lesson has described.

A final test: three rules, back to back

Trigger all three automations in quick succession, motion for Automation 1, a button press for Automation 2, and a manually adjusted temperature reading for Automation 3, and confirm each one behaves exactly as documented in your notebook without interfering with the others in any unexpected way. This final test is genuinely the closest this whole module comes to a real smart home working exactly as fully intended.

What can genuinely go wrong in this mini project

The most common issue is two automations both targeting the shared LED at nearly the exact same moment, producing a result that looks genuinely confusing until you check each one's individual trace. A second common issue is forgetting the evening-hours condition on Automation 1 entirely, leaving the hallway light firing at inconvenient times of day you genuinely never intended.

A quick map back through this module's lessons

Lesson 1 introduced triggers, conditions, and actions from the ground up. Lessons 2 and 3 built your first real automations and introduced conditions properly. Lessons 4 and 5 added temperature and button triggers. Lesson 6 brought in the smart plug. Lessons 7 and 8 covered modes and delays. Lesson 9 covered debugging. This lesson, finally, brings every single one of those pieces together into one coherent, working whole.

A hands-on exercise for this lesson

Build all three automations exactly as described above, test each one individually, then run the final combined test described above, and only mark this exercise complete once every single automation behaves exactly as your notebook documentation says it should, with no unexplained surprises remaining anywhere in the mix.

The minimum end state for a genuinely finished Module 11

At minimum, you should genuinely have three working, tested automations, a complete notebook table describing each one, and a calm, confident understanding of triggers, conditions, actions, modes, delays, and all four debugging tools, well enough to explain each single concept in your own plain words to somebody else entirely.

Why this specific pairing of rooms was chosen

A hallway and an office were deliberately chosen for this mini project because they genuinely represent two very different kinds of smart home logic, a hallway is a transient space where quick, automatic reactions make sense, while an office is a space where you actually spend extended time and want gentler, more considered automation. Building for both at once forces you to genuinely think about which style of automation fits which kind of space, rather than applying one single pattern everywhere by default.

Testing Automation 1 in isolation first

Before building Automation 2 or 3 at all, spend a few minutes genuinely confirming Automation 1 behaves exactly as this module's earlier lessons described, motion during evening hours turns the LED on, the light stays on continuously through repeated motion thanks to restart mode, and it turns back off roughly 30 seconds after the last detected movement. Only once this first, familiar automation is confirmed working should you move on to building anything new.

Testing Automation 2 without disturbing Automation 1

With Automation 1 confirmed working, add the button automation and test it during hours when Automation 1's condition would genuinely block the motion trigger, this way you can confirm the button's manual toggle works correctly without Automation 1 simultaneously reacting to your own movement in the room and muddying the result. Once confirmed, test again during evening hours to see both automations coexist as genuinely intended.

Testing Automation 3's cross-room signal

Adjust your office temperature sensor's reported value, either genuinely by changing the room's actual temperature or by briefly overriding it in developer tools for testing purposes, and confirm the hallway LED flashes exactly as Automation 3 describes. Pay close attention to how this flash interacts with whatever Automation 1 or 2 might be doing to the same LED at that exact moment, this interaction is precisely why the earlier lessons on modes and the loop trap matter here.

Choosing sensible mode settings for each automation

Automation 1 genuinely wants restart mode, exactly as established earlier in this module. Automation 2, the button toggle, is perfectly happy with the default single mode, since a button press is a discrete, one-off event rather than something needing to interrupt itself. Automation 3's temperature flash similarly suits single mode well, a brief flash rarely needs to be reset mid-flash by a second temperature reading arriving moments later.

Using trace to confirm all three cooperate correctly

Once all three automations are enabled together, deliberately trigger all three within a short window and then open each one's trace individually, confirming each ran with the trigger, condition, and action you genuinely expected, and that none of them were unexpectedly blocked or overridden by one of the others competing for the same shared LED entity.

Extending the mini project further, if you'd like

Once all three core automations are genuinely working, consider a few optional extensions entirely on your own, a fourth automation that logs every LED change to your notebook automatically, or a condition on Automation 3 that only flashes the LED if someone is actually detected in the hallway to notice it. Neither extension is required to finish this module, but both are genuinely good practice for the concepts you've already learned.

Reflecting on how far this module has taken you

Ten lessons ago, an automation was an entirely unfamiliar concept, trigger, condition, and action were just three new words. Now you've genuinely built, tested, debugged, and documented three coordinated automations working across two separate rooms, sharing entities safely, and behaving exactly as you intended. That's a considerably larger leap than it might feel like from the inside, take a moment to genuinely notice it before moving on.

A note on scaling this pattern to more rooms

Nothing about this mini project's structure is genuinely specific to a hallway and an office, the exact same pattern, motion-plus-delay for transient spaces, manual overrides for shared entities, and cross-room threshold signals, extends naturally to a kitchen, a bedroom, a garage, or any other combination of rooms in your own home. As you add more rooms in the future, keep returning to this lesson's core discipline, one automation at a time, tested individually, before ever combining several together.

Revisiting the one-sentence rule one final time

Before closing this module out entirely, write a plain-English, one-sentence description for each of the three mini project automations and read all three out loud together as a genuinely complete picture of your hallway and office's automated behavior. If any single sentence sounds even slightly surprising once said aloud, pause and reconsider that specific automation before treating the module as finished.

Celebrating a genuinely working smart home logic layer

It's genuinely worth pausing here, even briefly, to appreciate what's actually running in your home right now, real sensors triggering real automations, coordinated safely across two rooms, fully documented, and fully understood rather than copied blindly from somewhere else. That combination of working and understood is exactly what this entire module has been building toward from its very first lesson.

One last look at your notebook before moving on

Flip back through every notebook entry this module has asked you to make, entity names, one-sentence rules, mode and delay columns, and the safe-test checklist, and confirm nothing was skipped along the way. This notebook, more than any single automation, is genuinely the lasting artifact of Module 11, the resource that will actually help you six months from now, far more reliably than memory alone ever possibly could.

Key takeaways

This mini project combines every Module 11 concept, triggers, conditions, actions, modes, and delays, into three coordinated automations spanning two rooms.

Build and test one automation at a time, never all three at once, especially once several automations share the same entity.

A complete notebook table and a final three-rule test together confirm the module is genuinely finished, not just read through.

Disabling an automation from its three-dot menu remains the safest first response to any unexpected shared-entity behavior.

What's next: Module 12, helpers

Module 12 introduces helpers, scenes, and scripts, giving your automations reusable building blocks, timers, toggles, and input values, considerably more powerful than anything a single automation could hold entirely on its own, and one more genuinely useful, well-earned step deeper into a home that thinks for itself.

Finished this lesson?