Centralized or decentralized automation?

ESPHome
1

I’m using a combination of Home Assisant, MQTT, and ESPHOME to control all aspects of my motorhome. I’m starting to implement various automations (e.g. ‘go-to-sleep’ or ‘turn on movie mode’) but I’m unsure about how to best architect these automations? Should I centralize all code/logic in Home Assistant or should I fully decentralize all code and have each ESPHOME device react in the right way to each automation action trigger?

I did a write up on this topic: Automation Design - Beastie

What’s the best way to proceed? Where should I store the automation logic? Are there best practices people would recommend?

2

I’ve thought about this as well, but in my use case there is always strong (improving) connectivity within my maturing internal network (I just finished moving everything iot over to its own dedicated VLAN).

With that situation, I have decided to keep all logic centralized to keep it simpler for development and administration.

I have upon occasion run into a situation where one or more devices have trouble connecting or are not triggered properly, etc. That in and of itself is a valid reason to have the logic within some devices for the automation to talk locally to each other, but the better way to resolve such issues are to do what is needed to resolve the root cause. That is a double-edged sword because sometimes there is no way to resolve the root cause, but in that case you are stuck with thinking outside the box to use workarounds or slowly upgrade the hardware. And keep all the firmware up to date.

Local logic within devices to talk to each other directly in many cases might be more reliable and faster - but there are always drawbacks - when that is between Yolink devices for example, those two devices then cannot talk to any other Yolink device or HA. Even if you can use your own custom code in a device, such as with Shelly scripting, there is a limit to how much code can be used.

For any home automation, if it is across an entire household the entire situation is only as strong as it’s weakest part. Even if all of the equipment is top notch, one device going south can cause a network storm and bring the whole thing to its knees. (That’s just one of the reasons I switched over to a separate VLAN for IOT.) Therefore I have found the improvements that have the most effect are those which improve the speed and reliability of the entire network. My latest fix for instance, has to do with a bunch of Wemo smart plugs in a master bedroom. They would lose connectivity and cause no end of low WAF (Wife Approval Factor) when there is no power going to lamps which the spouse cannot then turn on. I do plan on replacing those smart plugs, but what turned out to be a major improvement was to replace the wireless access point to which they connect. In beefing up my network I had ‘temporarily’ (for about a year) instead of buying another WAP, had an old router in wap mode connected to my wired router. Replacing that old device with another centrally managed wap drastically improved the connectivity for those Wemo devices.

Even with centralized control I have found one scenario where local code is required. For a Shelly dimmer 2, for a light switch connected to it, for the switch to still be able to just turn the light on and off without HA or the Shelly app, a localhost API call within the dimmer configuration itself for “on” or “off” switch presses is required in the config for the dimmer to make a call to itself, but that is a unique case.

I can go on and on but just to clarify the above point, I am disliking the Wemo smart plugs because it takes them forever (if they do at all) to reconnect to a network, for example when a router is rebooted.

I digress here but one holy grail I am looking for is to make table lamps smart at the light bulb socket switch itself, such that if it is off, it can be turned on either remotely and also locally at the socket. With a smart plug that is turned off that’s not possible - and with a smart bulb that is not possible - and when the person is trying to turn it on, they are actually turning it off such that when the power through the smart plug is turned on the lamp then still does not go on because the person had just turned it off, etc. And even if a Shelly is put at the end of the wire near the outlet or in the basement of a lamp, the wire going from the lamp to the outlet needs to be at least three leads, never two, etc…

This may be an unending journey for some of us!

1 Like
3

I would say it depends. I read another post about this recently, but can’t find it now.

To use an example: I built a sprinkler replacement recently. Originally, I wanted to keep the hardware dumb with everything controlled from Home Assistant. In other words, the device was just some switches controlling relays. In the end, I went for ESPHome’s sprinkler component, which means I can still schedule a run from Home Assistant and monitor it, but running a full cycle all happens on the device. I can send one command to the device and it will run a full cycle.

So, what I’m saying is: Think of devices as standalone systems if you’d like said system to be able to operate without connectivity.

You could then also ask: Would you want e.g. a wake-up routine run directly on a smart bulb? In this case I’d say no, because you might have several bulbs and you wouldn’t want to duplicate the logic and have the overhead of updating multiple devices in case of a rule change. A bulb is a bulb. It’s purpose is to make light. Being used as a wake-up mechanism is something secondary (an application), so that logic for me doesn’t belong with the device.

There’s probably more to debate, but that’s how I think about it.

1 Like
4

Agreed wholeheartedly - and also think that if you have logic that is constantly running that is something that might be better to hand off to a dedicated other piece of hardware and not clog up say a very busy RPI running HA and the like, that is a consideration as well

1 Like
5

Indeēed! The power of esphome is that everything is possible. My first steps were with ZigBee and these types of devices are black boxes and often have their own behaviors and limited update frequency.

My rule is to have everything on the esphome node which can be locally executed and I always take care that I have a manual control/overwrite. That way even when HA is down all my devices are operational and controllable.

With the power of esphome it is even possible to check if HA (native api) is connected and when not trigger a remote device directly (rest-call/web server).

One more check could be if the esphome node is connected to WiFi and if not send the command to the remote esphome node directly via esp-now or bt-home (external/custom component needed).

1 Like
6

These are all great observations! I take it that there is no ‘best solution’ for a situation like this. The answer, as is so often the case, is …‘it depends’.

Thinking about this a bit more, I’m inclined to go with the decentralized solution, where the logic mainly resides inside the esphome devices.

I built the entire system to be independent of Home Assistant. That’s why all communication is handled by MQTT and not by using the native HA API. The reason for that is twofold:
1/ If, for whatever reason, my HA instance has issues, I still want to be able to turn on lights, set the thermostat, etc.
2/ I don’t think it’s great design that you’d have to train someone in HA in order to be able to operate the motorhome. All critical functions should be accessible using (smart) switches and a touchscreen. Even my touchscreen (NSPanel) runs esphome and implements a thermostat function that operates independently of HA.

So, given that, it feels wrong to then build all the automation logic inside Home Assistant and create a new dependency.

Of course the counter argument is that I’m not really that independent of HA. Mosquitto runs on the same server as HA, so if the server goes down, so does MQTT. And I’m using the Mosquitto integration in HA, so I’m not even sure that MQTT will still run if HA goes down. But these things can be fixed down the road. I could set up a separate MQTT server or potentially even create an MQTT cluster with failover, even though that might be a bit over the top for a simple motorhome use case :slight_smile:

7

That alot of times is not applicable:

Any wall switches that I have that are connected to shelly relays behind the switch allow you to turn the light on or off remotely - but also just by using the physical switch itself. They both work seamlessly together.

I have never heard of a thermostat that you could not walk over to and turn on or off or change it’s settings that can only be controlled by HA. Mybe there are some out there that I have not seen -

Where it is applicable:

On the other hand, your point is valid in a scenario where a relayt that is contrlled remotely turns the power on or off to say a table lamp. If there’s no juice going to the lamp - there’s no way you can rerach over to it to turn it on. (I have several of those plugged into smart outlets for example.)

I find the power of being able to control everything from one spot allows you to be so flexible it far outweighs the negatives. For instance, I have a weather station and also window sensors connected to HA (completely different manufacturers) and if it starts raining when any window is open a notification about each specific window that is open is sent to all of us living in the home. That is a simple example - you can for instance have a huge number of different devices all from different manufacturers - trigger riduiculous logic to do anything you want. I don’t really use this but but for fun I have old automations running that place data into a google sheet whenever my sump pump goes on and another that populates the same sheet with weather and rainfall data, and display that in graphical form in a dashboard to show the relationship between the two. The only limit to what you can do once it is all tied together is your imagination, and THAT is the biggest advantage of all. You can have a combination of both local and centralized control, which is the best of both worlds.

1 Like
8

My situation is a bit different in that I completely redid the electrical in my motorhome and significantly reduced overall wiring. All switches are momentary push buttons connected to a Shelly. The relay is rarely used. All end points (lights/appliances) also have a Shelly (in which case the input is not used). 3-way switches are also replaced by momentary push buttons and use software to implement the 3-way switching capability. There are no wires running from the buttons to the end points. All Shellies run ESPhome. So, for the system to work, I have to either rely on HA (using native API to connect ESPHome devices to HA) or rely on MQTT, which is what I ended up doing.

9

No. More options do exist that don’t need a broker

or even can work without WiFi Access Point.

10

That’s great to know. Need to research this a bit more. Could indeed be a nice fallback if for whatever reason either my server or WiFi access point goes down. And it’s an extra argument to build the automation logic inside ESPhome to make it more robust and resistant to any HA, Server, or even WiFi issues.

11

My approach is to put as much I can to ESPhome device - like inching, thermostat, …
All can happen inside single device - will happen in ESPhome software.
And delegate to HA communication between devices, between sensors and switches, f.e.

1 Like
12

Exact what I do with the addition that my esphome nodes check for HA api connection and in the rare case it is not present it will trigger the remote (esphome) device directly.

This takes care of the single point of failure and allows a backup path in case HA is down (like restarting for an update)

13

Is this the package you use to implement espnow communication in esphome?

14

Can you share some sample code of how you achieve this? I did more research on espnow and it’s not that straighforward. There is no standard integration with esphome; i did find some libraries here and there but i think there are lot of details to overcome (e.g. both sender and receiver have to be on the same wifi channel, but that is not guaranteed when your wifi network works but HA is down).

Also, as for the discussion about centralized vs. de-centralized, I finally decided to go with the middle option, ie, write the automations for the esphome triggering device. I write them as esphome scripts, so they are all sitting in the same ‘scripts’ directory, hence benefiting from a centralized model, without relying on Home Assistant. When I trigger an automation (push a button), the appropriate script get executed and pushes out a series of MQTT messages to esphome endpoints. Updating a particular automation only requires 1 firmware push, which is much better than having to update all endpoints.

15

Indeêed - I robbed the snippet from this very forum actually:

Yes, you need to work with a custom component like the one you linked from @afarago

16

Thanks, I understand the logic from the YAML snippet you shared. I was hoping for an example of an implementation with espnow, ie. turn on the lights with HA but if HA is down, connect to the light directly with espnow (with all the details of what that entails … starting a connection, picking the right wifi channel, etc.). I would love to see if someone has actually tried to do this. I couldn’t find any examples of this.

18

Its really not necessary to revive a dead post for the sake of making the same argument 10 other people made before you.

1 Like