Hi all,
I’m configuring ESPhome with api: for the HASS workload, toghether with MQTT to be used by MCU/linux light clients I develop to have full control even if the HASS server is down, as my MQTT server is on the OpenWrt High Available mirrored routers.
It would be nice to be able to write ESPhome API servers in “C” (not python), so I can simplify the setup and rely only on the ESPhome API without MQTT.
Any hint?
Thanks,
Piero
@nickrout thanks, but this is the server side (ESPHome).
To control ESPHome via API using other devices/processes, thus avoiding the MQTT redundance, I need the “C” client side, the one used (in python) by HASS.
IMO it would be nice to use the API and not needing a MQTT broker, which is rock solid but remains a singe point of failure.
Yes I understand now. Partly confusion on my side about which is the server and which is the client in the esphome api case. Thanks for reminding me.
You may be overthinking this. If ha or mqtt is a single point of failure, make sure they don’t fail. There is a high availability ha implimentation on the forum.
@nickrout my MQTT broker is already High Available, as it’s composed by two redundant OpenWRT in HA setup with separate UPS, power supply and switches.
I experimented some HASS.io redundancy the last summer, using HASS.os
I even evaluated a k3s+gluster clustering solution on the PI4, but I didn’t dedicate enough time to this.
As HASS HA, did you mean the HAHA thread? Sounds nice, I will try it.
HAHA sound cool, I tryed a similar approach but using k3s instead of Docker swarm.
Will try it in the next days using three PI4 just arrived.
Thanks @nickrout
can you share with us your code of k3s deployments like esphome and so on