Native API Client

[clinta]

Describe the problem you have/What new integration you would like
A custom component that can control other esphome devices using the native API

Please describe your use case for this integration and alternatives you've tried:
I have a wall switch running esphome, and a light running esphome. Currently the switch turns the light on and off via the homeassistant.service component. I'd much rather have the switch be able to use the esphome API to communicate with the light directly, that way the switch can still control the light even if homeassistant goes offline.

Additional context

[nagyrobi]

Duplicate of #46

[clinta]

@nagyrobi can you explain how this is a duplicate. I just read through #46 and it seems like a different issue. Though I understand if the existing API is removed entirely in favor of the design in #46, this request may become impossible. But my goal with this request was to have direct p2p control between esphome devices when homeassistant is unavailable.

[nagyrobi]

That FR discusses longly that direct p2p connections using the API would be possible one day, it's low priority though.

Until then, see #52

[ssieb]

I think this could stay open. It's much clearer than the other ones and I think it's a bit different than them as well. I certainly wouldn't consider it a duplicate of #46.

[RoganDawes]

I have a naive implementation of this (built for use over uart) that might be worth reviving. It's missing the more recent changes to implement noise encryption etc, but maybe useful even just for inspiration.

https://github.com/RoganDawes/esphome/tree/api_client

[nagyrobi]

Can you describe in a few words how is it supposed to work via uart?

[RoganDawes]

I had an implementation of esphome compiled for stm32, but it has no network capability, essentially just a port expander. I built the client api (and modified the api server code) to allow an esp32 to use the API over a uart, rather than trying to create yet another protocol.

Entities in the stm32 are interrogated via api, and registered in the esp32 as effectively local entities. (ie every remote entity needs a corresponding local entity acting as a surrogate. The surrogate identifies the remote entity by the entity_id, making it a bit fragile to bitrot or changes.) The ESP32 subscribed to updates from the STM32, so eg sensor values would be visible in the esp32 without polling, and external activation of eg buttons or switches in the esp32 would trigger an api call to the stm32.

I never really got it to be as reliable as I would have liked. The two ends could get desynchronised, and it was difficult to resync (but uart makes that more difficult than tcp, I guess!) A general purpose implementation would need to deal with peers disappearing and reappearing randomly, and reestablishing connections.

I'm not 100% sure that tcp is actually the best way to implement this, but it might be good enough. I suspect that UDP might end up being the better transport in the end.

[avilleret]

In the meanwhile the UDP component might be a good workaround : esphome/esphome#6865
But it requires to update the two devices and to explicitly declare each variable you want to expose over UDP.

A native client as described by @clinta would work out of the box with any esphome device which is much nicer.
Also native API allow discovery (we can enumerate device entities), this is not possible with UDP component.