automation

HomeSeer: Why I’m Still Here

home automationhomeseersoftware-automation

In my previous post, I talked a little about what HomeSeer is and why I started using it all the way back in the HS1 days.

There is an obvious follow-up question:

Why am I still using it?

After all, the home-automation world looks nothing like it did in 1999.

Today there is Home Assistant.

Hubitat.

Homey.

openHAB.

SmartThings.

Commercial systems such as Control4.

And an enormous collection of manufacturer-specific ecosystems layered on top of Alexa, Google Home, HomeKit, Matter, Zigbee, Z-Wave, Thread, Wi-Fi, and whatever protocol was announced last Thursday.

I am certainly not still using HomeSeer because there are no alternatives.

Quite the opposite.

I have watched a lot of alternatives arrive.

Some are genuinely excellent.

And in several areas, some of them do things better than HomeSeer does.

I am still here because the particular things HomeSeer does well continue to line up remarkably well with what I want from an automation system.

Home Assistant is probably the obvious comparison

If someone asked me today which platform represents HomeSeer’s strongest competitor, I would probably say:

Home Assistant.

Home Assistant has become enormously capable.

Its device support is huge.

Its community is huge.

Development moves rapidly.

Its interface has improved dramatically.

It is open source.

It runs locally.

And if you enjoy extending, modifying, and experimenting with your automation platform, there is an extraordinary amount you can do with it.

There is a great deal about Home Assistant that I genuinely like.

In fact, if I were starting from zero today, I would absolutely evaluate it very seriously.

But Home Assistant and HomeSeer have somewhat different personalities.

Home Assistant evolves quickly.

That is one of its greatest strengths.

New technologies appear quickly.

Architecture improves.

Old approaches are replaced.

Integrations are updated.

The platform is constantly moving.

HomeSeer tends to move more conservatively.

That can absolutely be frustrating when there is something newer I would like it to adopt.

But there is another side to that conservatism:

Things tend to keep working.

And after running an automation system for decades rather than months, I value that a great deal.

There is a difference between a hobby and infrastructure

This is probably one of the larger philosophical distinctions for me.

I enjoy home automation.

Obviously.

I enjoy experimenting with it.

I enjoy building plugins for it.

I enjoy discovering that some obscure device has an undocumented local API and then spending entirely too much time figuring out how it works.

But at the same time, the automation system itself has become infrastructure.

The lights should work.

The thermostats should work.

The irrigation should work.

The security-related automation should work.

The various little conveniences that have accumulated over the years should continue quietly doing their jobs.

There is a point where I want to experiment on top of the automation platform rather than continually experiment with the automation platform.

That distinction matters.

For me, HomeSeer has generally been very good at being the boring layer underneath all the interesting things.

And I mean “boring” as a compliment.

Hubitat gets a lot right too

Hubitat is probably the competitor that most closely shares HomeSeer’s local-control philosophy.

It is a compact appliance.

It supports the common automation radios.

It processes automation locally.

It has a capable rules engine.

And it can be extended with custom drivers and applications.

For someone who wants:

Buy a box, connect devices, build sophisticated local automation, and largely forget about the operating environment underneath it

Hubitat is a very compelling option.

Where HomeSeer suits me better is scale and openness.

HomeSeer is not fundamentally a little embedded hub.

It is software.

I can run it on substantial Windows or Linux hardware.

A plugin can be a fairly serious software application in its own right.

It can maintain databases.

Run background services.

Build rich web interfaces.

Talk to hardware over several different transports.

Perform substantial computation.

And apparently calculate the current polar motion of the Earth if somebody gets carried away.

That distinction has become increasingly important as my plugins have become more ambitious.

Homey probably wins the beauty contest

Homey takes a different approach.

It is polished.

Its visual automation system is excellent.

Its onboarding experience is attractive.

It integrates a remarkable collection of wireless technologies into one appliance.

If I were putting several systems in front of someone completely new to home automation and saying:

“Which one immediately looks like something you would enjoy using?”

I suspect Homey would do very well.

HomeSeer has never really been the beauty contestant in this group.

Its strength is not that every surface has been polished until it glows.

Its strength is that underneath the surface there is a surprisingly open-ended automation environment.

I can forgive a few less-than-glamorous screens if the trade is:

“If it doesn’t do what I want, I can probably make it do what I want.”

That is a trade I have apparently been willing to make for a very long time.

openHAB may be the closest architectural cousin

openHAB is another platform I respect.

It is open source.

Local.

Extensible.

Mature.

And capable of extremely sophisticated automation.

In some respects it may be the closest competitor to HomeSeer as an actual automation framework, rather than simply a smart-home appliance.

The difference is largely one of approach.

openHAB tends to feel like:

A powerful automation framework that you assemble into your system.

HomeSeer tends to feel more like:

A finished automation product that you can extend until it becomes a framework.

For someone who enjoys building from the framework upward, openHAB makes enormous sense.

For me, HomeSeer has historically struck a comfortable balance between:

ready to use

and:

ready to modify.

SmartThings solved a different problem

SmartThings helped push smart-home automation into the mainstream.

It brought together devices from many manufacturers.

It made onboarding easier.

It created a large ecosystem.

And its newer architecture does substantially more processing locally than the early cloud-heavy versions did.

But philosophically, it still feels different from what I want at the center of my house.

I do not particularly want the automation server to be a service somewhere else.

I want it here.

In the house.

Under my control.

Cloud services are fine when the thing being integrated inherently requires one.

Hubspace is a good example.

The platform itself is cloud-based.

The plugin cannot manufacture a local API that does not exist.

But the core automation system should not require that cloud.

If the Internet connection disappears, the house should continue knowing that:

A door opened.

A light should turn on.

It is nighttime.

The thermostat changed.

Someone went to bed.

The sprinkler should stop.

That distinction has become more important to me rather than less.

Local first does not mean “never use the cloud”

I should probably clarify that, because “local” can turn into a bit of a religion in home automation.

I use cloud services.

Some of my plugins use cloud services.

Some devices simply do not offer another useful path.

The question for me is not:

“Does this system ever talk to the Internet?”

The question is:

“What stops working when the Internet disappears?”

Those are very different standards.

Astrolabe is a good example.

Its astronomy works locally.

If Internet access is allowed, it can improve certain calculations with current Earth-orientation data, weather observations, satellite elements, and eventually space-weather information.

If those services are unavailable, it falls back gracefully.

The astronomy continues.

That is how I prefer cloud integration to behave whenever possible:

Useful enhancement, not structural dependency.

Then there are the dealer systems

Systems such as Control4 solve yet another problem.

They can provide an extremely polished, integrated whole-house experience.

Lighting.

AV.

Climate.

Security.

Touch panels.

Professional installation.

Professional support.

For the right customer, there is a lot to like about that model.

But it comes with a fundamentally different relationship to the system.

I do not want to need a dealer every time I have an idea.

I do not want the home-automation system to be a sealed appliance whose vocabulary is limited to what the vendor or installer decided to expose.

If I want the house to understand my Sleep Number bed...

I want to teach it.

If I want it to provision abandoned Wemos...

I want to teach it.

If I want it to understand exactly which Plex client is playing which movie on which Roku...

I want to teach it.

If I decide it really ought to know where Saturn is tonight...

Apparently I want to teach it that too.

HomeSeer lets me do that.

That freedom is worth a great deal to me.

The plugin architecture may be the biggest reason

This is probably the part that has become clearest while writing all of these plugins.

HomeSeer does not require the central platform itself to understand everything.

It gives developers a way to add understanding.

That means a plugin can be much more than:

Driver for Brand X switch.

It can be:

A media-session engine.

A device-provisioning system.

An astronomy engine.

A guide-data proxy.

An AV abstraction layer.

A bridge between several protocols.

A cloud integration with its own authentication lifecycle.

Or something I have not thought of yet.

And once that plugin translates its world into HomeSeer devices, states, actions, and events, everything else in the automation system can use it.

That is an extremely powerful boundary.

HomeSeer does not need to know how the astronomy works.

It only needs to know:

Astronomical twilight has ended.

It does not need to understand the Sleep Number API.

It only needs to know:

Both sides of the bed are occupied.

It does not need to understand Roku ECP and Plex sessions simultaneously.

It only needs to know:

The living-room player is watching a movie.

That separation has aged very well.

And I can sell the weird stuff

There is another practical difference worth mentioning.

HomeSeer has an actual commercial plugin ecosystem.

That creates an interesting incentive.

A developer can spend substantial time on an integration that HomeSeer itself may never have any economic reason to build and still potentially recover some of that effort from the comparatively small group of people who really want it.

That matters for niche software.

Astrolabe may be a perfect example.

I do not expect the entire HomeSeer user base to suddenly announce:

“Finally! I have been waiting for sub-arcsecond planetary positions and current atmospheric refraction!”

That would be surprising.

But for the people who are interested in astronomy, outdoor observation, sophisticated twilight control, satellite tracking, or simply having their automation system know considerably more about the sky...

...there may be real value there.

A commercial plugin ecosystem makes those strange little intersections more viable.

Even if some of us would probably build them anyway because we were having fun.

HomeSeer also carries some history with it

None of this is meant to imply that HomeSeer is perfect.

It is an old platform.

And I mean that both positively and negatively.

There are places where its age shows.

There are architectural choices that made complete sense years ago and would probably be designed differently today.

There is more polling in parts of the ecosystem than I would prefer.

There are areas where the UI could be more coherent.

There are pieces of plugin development that can feel considerably older than the devices being integrated.

Sometimes I look at something and think:

There is a much better modern way to do this.

And sometimes I am frustrated that HomeSeer has not moved faster.

That is real.

But old platforms also accumulate something new platforms cannot manufacture quickly:

scar tissue.

Backwards compatibility.

Migration paths.

Decades of real installations.

Edge cases somebody already encountered fifteen years ago.

Users whose automation has survived several generations of hardware.

That history has value too.

Continuity becomes important after enough years

This may be difficult to appreciate if an automation installation is only a year or two old.

After twenty-five-plus years, continuity starts to matter enormously.

I have automation ideas whose descendants have survived:

Different computers.

Different operating systems.

Different HomeSeer versions.

Different lighting technologies.

Different network architectures.

Different houses full of devices.

The individual hardware has changed repeatedly.

The automation layer has remained recognizable.

That is quite an accomplishment.

It also changes how I evaluate a platform.

The newest architecture is not automatically the best architecture if adopting it means rebuilding the house every few years.

There is value in evolution that does not require demolition.

HomeSeer has generally been good at that.

I am not here because I never looked elsewhere

That is probably the most important distinction.

I am not still using HomeSeer because I installed it in 1999 and somehow failed to notice that other software was invented afterward.

I know the alternatives exist.

Several are excellent.

Several do specific things better.

I would recommend different platforms to different people depending on what they want from the system.

Someone who wants an inexpensive self-contained local hub may be extremely happy with Hubitat.

Someone who wants an enormous open-source ecosystem and enjoys rapid development may prefer Home Assistant.

Someone who prioritizes visual polish may love Homey.

Someone who wants a deeply open automation framework may gravitate toward openHAB.

Someone who wants a professionally installed luxury system may be much happier with Control4.

Those are all legitimate answers.

My answer remains HomeSeer because the combination I care about is a little different:

Local ownership.

Long-term continuity.

A mature automation engine.

Hardware independence.

Extensibility.

An open plugin model.

And perhaps most importantly:

If the system does not understand something I want it to understand, I am allowed to teach it.

That last one is difficult for me to give up.

The house belongs to the automation, not the vendor

Over the years, this has probably become my strongest philosophical preference.

I do not want the house organized around:

The lighting vendor.

The thermostat vendor.

The television vendor.

The irrigation vendor.

The bed vendor.

The voice-assistant vendor.

Each manufacturer naturally sees its product as the center of the universe.

From inside the house, none of them are.

The house is the system.

The devices are participants.

HomeSeer gives me a neutral layer where all of those participants can become part of the same model.

Once they are there, the automation can reason about the household rather than merely operate a device.

That is the part I have valued since the beginning.

And despite all the extraordinary changes in smart-home technology since 1999, I have not found that idea becoming obsolete.

Quite the opposite.

The more disconnected “smart” ecosystems we accumulate, the more valuable the independent layer in the middle becomes.

So why am I still here?

Not nostalgia.

Although after this long, there is admittedly some of that.

Not because HomeSeer wins every comparison.

It does not.

Not because I think everybody should use it.

I don't.

I am still here because after watching the home-automation industry evolve for more than twenty-five years, HomeSeer still occupies a combination of qualities I find unusually useful:

It runs locally.

It lets me own the automation.

It does not dictate the hardware.

It has proven remarkably durable.

It can be extended far beyond what its original developers could possibly have anticipated.

And when I have one of those ideas that begins with:

“I wonder if HomeSeer could...”

the answer is very often:

“Probably, if you're willing to write some code.”

That has proven to be a dangerous answer.

It is also a large part of why I am still having fun with it.