All I Wanted Was to Add a Smart Device Without Downloading Yet Another App

I have enough apps

Buying a smart device should be boring.

Power it up. Pair it. Give it a sensible name. Use it.

Instead, the normal consumer-smart-home path often asks for another app, another account, another privacy policy and another cloud dependency before Home Assistant can control the thing anyway.

At some point I stopped asking whether a device had an app.

I started asking why I needed the app at all.

Home Assistant is already the place I use to control the house. If I buy a sensor, dimmer, switch or small controller, I primarily want the device.

I do not automatically want the software ecosystem attached to it.

The rule became local first, not local only

This is not an anti-cloud project.

Some products are better because of the service behind them. Ring remains a cloud service in this house because the service is part of the product I chose.

The rule is simpler:

Local by default. Cloud where it adds real value.

If a device can do its useful job entirely on the LAN, I would rather keep that control path local.

If the existing vendor path works and is not causing a problem, I am also not replacing it merely for ideological purity.

That is why the house still contains a mixture of Zigbee, Wi-Fi, MQTT, cloud integrations and odd bits of legacy RF.

The goal is not protocol purity.

The goal is to make the useful control path mine.

That became the LAN of Things

The name is deliberately LAN of Things - LoT.

I am not trying to put more Things on the Internet.

I am trying to keep useful devices on the LAN, translate whatever protocol they actually speak, and expose the useful bits to Home Assistant.

Conceptually:

device
   |
   +-- Zigbee -----\
   +-- Wi-Fi -------+
   +-- IR ----------+-- local adapter / MQTT -- Home Assistant
   `-- Legacy RF ---/

Home Assistant remains the household front end.

The LoT layer is the lower-level plumbing: onboarding, protocol translation, device-specific controls, diagnostics and the boring bits I do not want scattered across manufacturer apps.

Small adapters beat one giant clever box

Cheap ESP32-class boards make it tempting to build one device that does everything.

I prefer the opposite.

A Zigbee coordinator should coordinate Zigbee.

An IR node should send IR.

The Smiths bridge should speak the strange legacy RF language the heaters understand.

A Varilight controller should talk to Varilight dimmers.

MQTT can be the common middle where that is useful.

The extra hardware is cheap.

Debugging one board with six unrelated responsibilities is not.

Small adapters give me clearer failure boundaries and make the system easier to replace one piece at a time.

MQTT is the boring middle

That is a compliment.

I do not want every home-built integration to invent its own house-wide API.

MQTT gives small controllers a simple common language:

• publish state
• accept commands
• expose availability
• retain useful current values
• let Home Assistant discover devices cleanly

The implementation can stay narrow enough that I can still understand it six months later.

And the device-specific protocol can remain where it belongs: inside the adapter that understands that device.

State has to be honest

The Smiths heater project taught me an important rule:

A command is not feedback.

Those heaters can receive a radio command but cannot report their physical state back.

So the UI must not pretend a command magically became a verified sensor reading.

Other devices can do better.

The Varilight dimmers, for example, report their actual brightness back to the local controller. Physical changes at the wall therefore flow back through MQTT and appear in Home Assistant.

Same LoT philosophy, different capability.

If the device can confirm state, expose it.

If it cannot, say so.

A clean UI is not an excuse to invent certainty.

The Varilight rabbit hole is the best example so far

The three existing V-Pro Smart dimmers are probably the clearest example of where this idea leads.

I wanted to keep the hardware and its stock firmware, but I did not want to run a much larger SUPLA software stack on a fairly modest Proxmox box just to operate a few lights.

So I investigated what the dimmers actually needed from the server side.

That escalated into a local controller speaking the small subset of the protocol the tested dimmers use, with MQTT, Home Assistant discovery, device enrollment and a local management UI.

Naturally, that deserves its own story.

Read: All I Wanted Was to Control Three Dimmers Locally ->

What exists today

The LoT idea is no longer just a diagram.

The current house includes:

• Home Assistant as the main control and automation surface
• the Smiths ESP32/CC1101 heater bridge over MQTT
• the local Varilight controller for compatible V-Pro Smart dimmers
• a local LoT management interface
• the existing Zigbee gateway, still doing useful work
• planned HA-native Zigbee and IR paths when there is a real reason to add them

The important bit is that these are not all being forced into one implementation.

They share a design principle, not necessarily a codebase.

Why not just use the vendor apps?

Sometimes I do.

The useful question is:

what value is the extra dependency buying me?

If the answer is a genuinely useful service, fine.

If the answer is that a basic switch needs an account because that is how the product was designed, I am less enthusiastic.

A light switch should outlive an app redesign.

A temperature sensor should outlive a startup.

And a heater should not stop heating because somebody changed an API on the other side of the Internet.

The unexpected benefit

Avoiding another app started as convenience.

The bigger benefit is that the house is becoming easier to reason about.

More and more of the control path looks like:

physical device -> local protocol -> local adapter -> Home Assistant

rather than:

physical device -> vendor cloud -> internet -> vendor integration -> Home Assistant -> hope

That does not remove complexity.

Clearly.

I appear to be building a LAN of Things platform in my spare time.

But it puts the complexity somewhere I can inspect, document, test and change.

Was this necessary?

Absolutely not.

I could have downloaded the app.

Instead I now have MQTT, protocol bridges, Zigbee boards, RF hardware, a local device platform and a Varilight controller that started because three dimmers seemed to require more server than I wanted to run.

Which rather proves the point of this website.

All I wanted was to add a smart device without downloading yet another app.

Then it escalated quickly.