I have written about home automation on this blog for years. In 2019, I published a collection of home automation ideas that worked well for my family. The important part was never a particular hub, protocol, or brand. It was the logic behind each idea and whether it quietly made everyday life easier.
That original post kept growing in my head. A long list of ideas is useful for inspiration, but it is not a great format for explaining everything that makes an automation dependable: what triggers it, which conditions matter, how someone overrides it, and what happens when a sensor or service fails.
That is why I built Home Automation Cookbook. It gives each household job enough room to become a reusable recipe rather than a platform-specific trick.
The problem I wanted to solve
Most smart-home content begins with technology. It starts with a hub, a product, or a feature and then looks for something to do with it. I wanted to reverse that.
The Cookbook starts with an ordinary burden:
- Remembering to move laundry after the washer finishes.
- Checking whether the garage door was left open.
- Adjusting the thermostat when a window is open.
- Reaching for a light switch while carrying something through the house.
Only after the job is clear does the recipe discuss sensors, switches, platforms, or products. This makes the idea easier to adapt, and it prevents the site from becoming a catalog of gadgets looking for a purpose.
The other problem is that an automation can work perfectly for the person who created it and still be bad for everyone else. My family is the real QA team. Kids, guests, and anyone who did not configure the system should still be able to use the house without learning an app or remembering special rules.
A useful automation should remove work without removing control.
The wall switch is part of the design
One principle appears throughout the site: the physical control should keep working.
If motion turns on a light, the wall switch should still behave like a wall switch. If the hub is restarting, the internet is unavailable, or the automation made the wrong decision, nobody should be trapped behind the technology.
I learned this through normal household use. An automatic bathroom light that turns on a fraction too late can collide with muscle memory. Someone reaches for the switch just as the automation turns on the light, and their tap immediately turns it off again. The rule technically worked, but the experience did not.
The fix was not to explain the automation more carefully. It was to move the sensor and make the response fast enough that the room behaved naturally.
This is also why the site emphasizes local execution where a platform supports it. Cloud services and voice assistants can be useful extras, but basic household behavior should degrade gracefully when they are unavailable.
Recipes instead of walkthroughs
I have personally used Amazon Echo with Alexa, SmartThings, and Hubitat. Hubitat is what I use today. Those experiences inform the site, but the core recipes remain platform-neutral.
A typical recipe describes:
- The trigger that begins the automation.
- The conditions that must also be true.
- The action the house should take.
- Any wait or timeout.
- The condition that stops or reverses it.
- The manual override.
- The likely failure modes.
That structure is deliberately close to plain English. A reader can understand the behavior before translating it into a Hubitat rule, a SmartThings routine, an Alexa routine, or another system.
Platform notes are supporting material rather than the recipe itself. I also distinguish between firsthand experience and technical fit. For example, I have not personally run Home Assistant, so the site does not present Home Assistant guidance as a hands-on walkthrough.
How the site is built
The implementation is intentionally simple. Home Automation Cookbook is a static Jekyll site made primarily from Markdown, HTML, CSS, JavaScript, YAML data, and shared layouts.
Visual Studio is my workshop
I built the site in Visual Studio. That may sound like an unusual choice for a Jekyll site, but it gives me one workspace for the entire project: Markdown recipes, Liquid layouts, YAML data, CSS, JavaScript, images, and Git history. I can make a site-wide change, review the diff, run the site locally, and push it without switching between a collection of specialized tools.
Visual Studio is not a requirement for contributing to the site, and it is not part of the production runtime. It is simply the workshop I prefer. Jekyll turns the source into static pages, and GitHub Actions deploys them to GitHub Pages after I push to the main branch.
The source is public in the Home Automation Cookbook GitHub repository. A push to the main branch runs a GitHub Actions workflow, builds the production site with Jekyll, and deploys the result to GitHub Pages.
Static generation is a good fit for this project. The pages are fast, the content is easy to review in a pull request, and the repository contains the history of how the guidance changes. There is no application server or database to maintain just to publish a recipe.
The site currently contains 49 automation recipes across lighting, climate, safety and security, appliances, notifications, entertainment, and daily routines. Shared Jekyll layouts keep those pages consistent, while structured category data powers the recipe directories and starting points.
The automation directory is organized around the reader's goal rather than the implementation. Instead of asking which integration someone uses, it asks whether they want to stop checking an appliance, move through the house more easily, reduce repeated adjustments, or coordinate a household transition.
Writing the failure before calling it finished
The happy path is usually the easy part of home automation. The more useful questions are:
- What if the sensor stops reporting?
- What if its last known state is stale?
- What if someone manually changes the device?
- What if a guest behaves differently from the person who built the rule?
- What remains available when the hub or internet is down?
Every substantive recipe includes failure modes because a rule is not complete until the household knows how it fails. A notification should not claim success when the final state was never confirmed. An unavailable contact sensor should not silently remain "closed" forever. A manual change should not immediately be undone by an overconfident automation.
This way of writing also improves the automations in my own home. Explaining a rule exposes assumptions that are easy to miss while looking at a visual rule editor.
The site is a cookbook, not a blueprint
A recipe is a starting pattern. Every home has different rooms, routines, tolerances, devices, and people. The goal is not to copy my house. It is to understand why a pattern works, identify the signals it needs, and adapt it without losing the fallback behavior.
I recommend beginning with one small, reversible win. Motion lighting in a hallway or a washer-finished notification is easy to observe and easy to override. Run it for a week. Watch how people actually use it. Change one assumption at a time.
That loop is how the site grows too. I started the repository in November 2025, and it has evolved through hundreds of small revisions to its recipes, navigation, safety guidance, platform notes, and visual design. The work is less about declaring an automation complete and more about making each explanation clearer and more dependable.
What I hope the site becomes
I want Home Automation Cookbook to be useful to someone before they buy a device and after the novelty of that device is gone.
Before buying, it should help define the household job and the capabilities required to solve it. After installation, it should help test the rule, preserve manual control, recognize failure, and adjust the behavior as the household changes.
Most of all, I want the site to keep the technology in a supporting role. The lasting benefit is not that a home contains more smart devices. It is that there is less to remember, fewer repeated checks and adjustments, and more confidence that ordinary controls will still work.
You can browse the recipes at homeautomationcookbook.com, or inspect and contribute to the source on GitHub.
Comments
What did you think?