HomeSeer: The Platform Behind All of This
The Platform Behind All of This
The Platform Behind All of This
A little context for anyone reading these plugin posts and wondering what HomeSeer actually is, and why I have apparently spent a substantial portion of my life teaching it new tricks.
I have been using HomeSeer since essentially its inception, going all the way back to the original HS1 era around 1999.
That sentence probably deserves some context.
Today, “smart home” usually brings to mind phone apps, Alexa, Google Home, HomeKit, cloud-connected light bulbs, and little hubs you plug into your router.
In 1999, none of that existed in anything resembling its present form.
Wi-Fi itself was barely becoming a household technology.
There were no smartphones.
No Alexa.
No Nest.
No Philips Hue.
No consumer cloud full of devices waiting for an app to discover them.
If you wanted a house to do something automatically, you generally had to assemble the pieces yourself.
And one of the more interesting pieces that appeared around that time was HomeSeer.
In the beginning, there was X10
HomeSeer began life in 1999 as software originally called AutoHome, created by Richard Helmke under the company name Keware.
Not long afterward, the product and company became HomeSeer.
The early software primarily worked with X10, which was one of the few practical consumer home-automation technologies available at the time.
X10 sent control signals over the electrical wiring already inside the house.
It was clever.
It was inexpensive.
And, depending on the electrical topology of the house and the mood of the appliances currently plugged into it, occasionally somewhat aspirational.
But it gave ordinary people the ability to do something remarkable for the time:
Have a computer control the house.
That fascinated me.
Home automation before the “smart home”
What made HomeSeer interesting was not simply that you could click a button on a computer and turn on a lamp.
A remote control could already do that.
The interesting part was the automation engine.
HomeSeer could maintain devices and states.
It could watch for conditions.
It could execute events.
It could combine time, device state, schedules, and logic into behaviors.
Instead of:
Press this button to turn on the light
you could begin thinking in terms of:
When this happens, and these conditions are true, do these things.
That is a fundamentally different idea.
The house stops being a collection of remotely controlled gadgets and begins becoming a system.
That distinction is still important to me today.
I stayed
I started using HomeSeer in those early days and never really stopped.
The software evolved.
HS1 became HS2.
HS2 became HS3.
HS3 eventually became the current HS4 generation.
The hardware around it changed even more dramatically.
X10 gave way to technologies such as Z-Wave.
Then came Insteon, Zigbee, network-connected devices, IP cameras, media systems, smart thermostats, lighting platforms, voice assistants, Wi-Fi appliances, and an ever-expanding parade of things containing tiny computers for reasons both excellent and questionable.
Some of those technologies flourished.
Some disappeared.
Some companies disappeared.
Some clouds disappeared while leaving perfectly good hardware behind.
HomeSeer remained.
That continuity is a large part of why I still use it.
It has effectively become the operating system of my house
That is probably the easiest way I can explain what HomeSeer is to someone unfamiliar with it.
For me, HomeSeer is less a “smart-home hub” than the automation operating system for the house.
The individual devices come and go.
The automation layer remains.
A light switch may be Z-Wave.
Another might be Lutron.
A sprinkler controller has an HTTP API.
A television speaks something completely different.
The bed has a cloud service.
The Roku has ECP.
A receiver has its own network protocol.
Wemo speaks UPnP.
None of those things needs to understand any of the others.
HomeSeer sits in the middle and gives them a common place to exist.
Once they are represented there, an event can combine them in ways their manufacturers never contemplated.
That is where things get interesting.
A device does not have to be a device
One of the concepts I have always liked about HomeSeer is that a “device” in the system does not necessarily have to correspond directly to one physical object.
It can represent:
A switch.
A temperature.
A room state.
A media player.
Someone being in bed.
A satellite being visible.
A receiver volume.
Whether it is astronomical night.
Whether irrigation is paused.
Whether the washing machine has finished.
Whatever information is useful to the automation system.
That abstraction is powerful because the event engine does not particularly care where the information came from.
Once HomeSeer knows:
Someone is in bed
an event does not need to understand the Sleep Number API.
Once it knows:
The Roku is playing Plex
the event does not need to know anything about Roku ECP or Plex sessions.
Once Astrolabe says:
Astronomical twilight has ended
the event does not need to understand solar geometry.
The difficult translation happens once, at the integration boundary.
Everything above that gets to work with concepts.
That is where plugins come in
A HomeSeer plugin is essentially a translator and extension module.
It teaches HomeSeer how to communicate with something HomeSeer does not understand natively.
The plugin deals with whatever peculiarities exist underneath:
APIs.
Network protocols.
Authentication.
Discovery.
Certificates.
Serial ports.
WebSockets.
UPnP.
Infrared.
Cloud services.
Undocumented endpoints.
Occasionally malformed HTTP generated by discontinued embedded hardware.
HomeSeer does not need to know about any of that.
The plugin translates the device or service into HomeSeer’s world.
That plugin architecture was one of HomeSeer’s important ideas very early on.
An open API and SDK allowed third-party developers to add support for technologies HomeSeer itself did not directly support.
That meant the platform did not have to anticipate every future device.
It merely had to provide a way for somebody else to teach it.
More than twenty-five years later, I am apparently one of those somebodies.
Quite a lot lately.
Why I started writing so many of them
Most of the plugins I have been writing did not begin with:
I would like to create another software product.
They began much more simply:
I have this thing, and I want HomeSeer to understand it better.
Or:
There is already an integration, but it does not expose what I need.
Or:
The manufacturer abandoned this perfectly functional hardware.
Or, perhaps most dangerously:
I wonder if this is possible.
That last question has consumed a surprising amount of time.
The Roku plugin came from wanting better control and media information.
That exposed the problem of not knowing the actual downstream AV state, which helped create the much larger AV project.
The Wemo plugin came partly from having a pile of perfectly functional Wemo Minis whose official cloud and app had reached the end of the road.
The Sleep Number plugin began because the bed contains an unusually useful occupancy sensor.
HDHomeRun became much more than simply channel control.
OpenSprinkler grew from wanting a maintained integration that properly handled the controller I actually have.
Astrolabe began because I wanted more astronomical information than sunrise and sunset.
Astrolabe has since become a cautionary tale about asking:
“How accurate could I make this?”
They all started with a real use.
The scope occasionally wandered afterward.
Why not just use the manufacturer's app?
Because a collection of apps is not automation.
If I have:
One app for lighting.
Another for irrigation.
Another for the bed.
Another for the television.
Another for the receiver.
Another for the thermostat.
Another for cameras.
Another for whatever arrived last Tuesday...
...I have remote controls.
Potentially very attractive remote controls.
But each product still lives in its own little universe.
The interesting thing happens when they share state.
If both sides of the bed become occupied late at night, HomeSeer can know that it may be time to change the behavior of the entire house.
If the media system starts playing a movie, the lighting can react.
If a water sensor trips, the house can speak through Alexa.
If the Sun reaches a particular twilight boundary, exterior behavior can change.
If irrigation is paused because of rain, other systems can know why.
The individual manufacturers do not need integrations with one another.
They need an integration with the common automation layer.
That is the role HomeSeer has played here for a very long time.
Local control has always mattered to me
Another reason HomeSeer has remained attractive is that the core automation engine runs locally.
The Internet can be useful.
Cloud services can be useful.
I use both where they make sense.
But the basic automation of the house should not stop simply because the Internet connection does.
That philosophy is increasingly important as more consumer products become dependent on manufacturer-operated services.
A cloud integration may be perfectly reasonable.
But I prefer it to be a dependency of that particular feature, not a dependency of the house itself.
If the Hubspace cloud is unavailable, Hubspace devices may temporarily be unavailable.
That is inherent in the platform.
If the weather service is unavailable, Astrolabe can fall back to local astronomical models and standard atmospheric assumptions.
If CelesTrak cannot be reached, the last valid satellite data does not instantly evaporate.
If the Internet connection fails entirely, local lighting and automation should continue behaving like lighting and automation.
The cloud should extend the house.
It should not hold the house hostage.
HomeSeer has historically fit that approach quite well.
Twenty-five-plus years creates perspective
Using one platform for this long also means I have watched a lot of ideas come and go.
I have watched technologies that were going to revolutionize home automation vanish completely.
I have watched cloud services disappear.
I have watched manufacturers abandon products that still physically work.
I have watched protocols evolve.
I have watched integrations break because somebody far away changed an API on a Tuesday.
And I have watched the definition of “smart home” repeatedly get reinvented by companies convinced the industry began shortly before their press release.
Through all of that, the basic automation problem has remained surprisingly consistent:
Observe state.
Decide what it means.
Do something useful.
The protocols change.
The products change.
The interface changes.
That underlying problem does not.
I also know where the bodies are buried
Using HomeSeer for this long does not mean I think every design decision in it is perfect.
Quite the opposite.
Spend twenty-five years with any software platform and you accumulate opinions.
I have seen things I think HomeSeer does extremely well.
I have also seen things I would design differently.
There are architectural choices that made perfect sense years ago and feel less natural now.
There are places where newer event-driven approaches are preferable to polling.
There are areas where plugin development can be more awkward than I would like.
There are old assumptions living alongside newer technology.
And occasionally I find myself looking at something and thinking:
We really don't have to do it this way anymore.
That is not dislike.
It is familiarity.
You do not spend this much time with a system without learning both what makes it valuable and where its sharp edges are.
I have a soft spot for HomeSeer precisely because I have lived with it long enough to know both.
And that influences how I write plugins
A lot of the design rules I have described in these posts come from experience rather than theory.
Do not make an IP address the permanent identity of a device.
Do not silently change HomeSeer device addresses after release.
Do not make an optional optimization into a hidden dependency.
Do not treat “could not verify” as “verified good.”
Do not duplicate state another system already owns.
Do not assume two related protocols are identical merely because they share ancestry.
Do not make Internet access a requirement when local operation is possible.
Do not repeatedly poll something that can tell you when it changes.
And when a platform does something strange, capture what actually happened before deciding what it means.
Most of those rules have a story behind them.
Some have scars.
The advantage of having used the automation platform for this long is that I am no longer designing merely for:
Can I make this work?
I am increasingly designing for:
Will I still be happy with the way this works five years from now?
That is a much harder question.
It is also the more useful one.
So why am I still here?
Because despite all the changes around it, HomeSeer still provides something I value enormously:
A locally controlled, extensible automation environment where I can make disparate systems behave like parts of the same house.
If something is unsupported, there is a path to support it.
If an integration does not expose enough information, I can extend it.
If a manufacturer walks away from useful hardware, sometimes local protocols let me keep using it anyway.
If I have an unusual idea, I do not have to wait for somebody else's product roadmap to include it.
I can build it.
That freedom has probably done more than anything else to keep me using HomeSeer all these years.
It also explains the growing pile of plugins.
Which brings us to all these posts
If you have been reading these development posts without knowing much about HomeSeer, hopefully this provides the missing piece.
Roku, Plex, Wemo, Lutron, Sleep Number, OpenSprinkler, HDHomeRun, Astrolabe, and the others are not intended to be isolated applications.
They are ways of bringing more of the world into the same automation environment I have been using since the beginning.
Some solve practical problems.
Some replace abandoned integrations.
Some expose information I always wanted HomeSeer to know.
Some are experiments that got slightly out of hand.
And at least one now cares about the current polar motion of the Earth.
But they all come from the same basic idea that attracted me to HomeSeer in the first place:
The interesting part is not controlling the individual device.
The interesting part is what becomes possible once the house understands it.
Twenty-five-plus years later, I still think that is the fun part.