Home Automation with Asynchronous Microservices

In this 2017 GOTO talk, Fred George describes a home-automation experiment using small asynchronous microservices. He presents it as a personal exploration of changing requirements, not a universal architecture for every home or production system.

George distinguishes problems with predictable cause and effect from complex situations where teams must experiment and observe. He argues that uncertain home-automation goals are a useful setting for trying ideas incrementally.

He demonstrates changing lights in his home and describes a collection of devices with different APIs. The challenge is to combine them without tying every higher-level behavior directly to one vendor’s interface.

His design uses small services and an asynchronous event bus. Device-facing services publish observations and receive commands, while other services can react without directly calling every device-specific implementation.

He calls the shared event stream the “rapids,” filtered streams “rivers,” and stored current-state views “ponds.” This is a way of thinking about event flow and queryable state, not a guarantee of ordering or delivery.

In his “need” pattern, a service publishes a request without assuming a particular listener will respond. Asynchronous systems must handle missing responses and other failure cases explicitly.

George separates hardware access from higher-level scenes and cross-device behaviors. Monitoring services observe the event stream and can flag conflicting commands or failed components.

His “sticky colors” example polls light state, publishes it and reapplies a desired color when a light comes back in a different state. Several small services cooperate without a central orchestration service.

He favors fast experimentation and abundant messages for developer productivity. In his home experiment he also argues for deploying without some tests; that tradeoff should not be generalized to systems where failures can harm people or cause significant loss.

George connects the approach to agile values, suggesting that teams working on uncertain problems may organize around experiments and feedback. He describes potential future work on sensors and smaller hardware.