Disable API reboot timeout.

[hjdhjd]

Would be great if we could have the YAML updated such that the Ratgdo didn't auto reboot every 15 minutes if you don't connect to the native API. Those of us using the web API rather than the native API have to workaround this constraint currently.

Disabling the auto reboot is straightforward in the YAML.

api:
  id: api_server
  reboot_timeout: 0s

@PaulWieland Any chance you can add this to the YAML? It'd be incredibly helpful. Thanks!

[PaulWieland]

No, thats not in the plan. The reboot is quite intentional to help with unstable networks.

From the ESP Home FAQ:

ESPHome reboots on purpose when something is not going right, e.g. wifi connection cannot be made or api connection is lost or mqtt connection is lost.

You can simply clone the project and update yaml to suit your needs. You can also initiate a connection to the API socket just like Home Assistant does and that will prevent it from rebooting.

[hjdhjd]

That's already what I do. I just find it inelegant. 😄

Appreciate the clarity on your plans. Thanks and keep up the great work!

[rlowens]

You don't even need to clone the project, just put that in your own device .yaml in the api: section that already exists.

substitutions:
  name: ratgdov2-11999c
  friendly_name: ratgdo
packages:
  ratgdo.esphome: github://ratgdo/esphome-ratgdo/v2board_esp8266_d1_mini.yaml@main
esphome:
  name: ${name}
  name_add_mac_suffix: false
  friendly_name: ${friendly_name}
api:
  encryption:
    key: iWx8Hghy47j8zEC4IVqJousY+SZI+U1S0X1VWLp3Zz8=
  reboot_timeout: 0s

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

[hjdhjd]

You don't even need to clone the project, just put that in your own device .yaml in the api: section that already exists.

substitutions:
  name: ratgdov2-11999c
  friendly_name: ratgdo
packages:
  ratgdo.esphome: github://ratgdo/esphome-ratgdo/v2board_esp8266_d1_mini.yaml@main
esphome:
  name: ${name}
  name_add_mac_suffix: false
  friendly_name: ${friendly_name}
api:
  encryption:
    key: iWx8Hghy47j8zEC4IVqJousY+SZI+U1S0X1VWLp3Zz8=
  reboot_timeout: 0s

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

I'm aware. That's not really my point. 😄

Nothing should default to auto rebooting every 15 minutes. I find it inelegant. I understand the functional reason why, of course, I just don't agree that it should be the default. But it's not my project. I will work around it with my own project (I write and maintain the Homebridge plugin for Ratgdo) for my user community. I just don't agree that it's user-friendly to:

1. Presume everyone wants to use HomeAssistant by default with the ESPHome Ratgdo.
2. Have the reboot watchdog enabled by default that only checks for connections to MQTT (which isn't enabled in this configuration by default) or the native API before forcing a reboot every 15 minutes.

I understand why the choices were made and respect the opinionated nature of them. I just find them unfortunate defaults for my community to contend with and have to workaround. I can/do workaround them - I just don't like the inelegance of needing to do so based on the default presumption that HomeAssistant is the most likely automation mechanism for Ratgdo - there's a sizable Homebridge community that uses it as well.

[PaulWieland]

I am not presuming everyone uses Home Assistant (I myself don't use it). ESP Home just wants to make sure something is communicating with it, and if not, it reboots to try and correct the situation.

If you integrate with it via the native API or MQTT, it will know that everything is fine and stop rebooting. Integrating via the http protocol is the least elegant solution available IMO, but even still all you have to do is connect to the API's port and it will stop rebooting.

FWIW, this project demonstrates a "third party" integration with the ESP Home API. I'm currently testing it with ratgdo to replace MQTT in my own setup.

[hjdhjd]

I am not presuming everyone uses Home Assistant (I myself don't use it). ESP Home just wants to make sure something is communicating with it, and if not, it reboots to try and correct the situation.

If you integrate with it via the native API or MQTT, it will know that everything is fine and stop rebooting. Integrating via the http protocol is the least elegant solution available IMO, but even still all you have to do is connect to the API's port and it will stop rebooting.

FWIW, this project demonstrates a "third party" integration with the ESP Home API. I'm currently testing it with ratgdo to replace MQTT in my own setup.

I think the web API is the most, not the least, elegant approach. 😄 Standards based, easy to develop for, monitor and troubleshoot directly, etc. But I do respect and understand your POV...I just see the world differently.

If ESPHome is going to provide a fully supported API endpoint, then they should have their API watchdog support it properly. I think this is more a functional gap in ESPHome itself, in my opinion - the watchdog timer should account for RESTful/EventSource API usage.

Re: HomeAssistant - good to know, and appreciated.

[Goose66]

I know this is closed by I wanted to add a +1 for setting the reboot_timeout to zero. Seeing how it appears the MQTT firmware is no longer being updated and the problems that exist with it, the users of integration are hoping for a new solution to be able to use their ratgdo devices. The ESPHome firmware with the REST/EventSource API seems like the most accessible and most elegant transition from MQTT. But it certainly doesn't make sense to use the firmware if it's going to reboot itself every 15 minutes. And if I have to use the native API to keep it from rebooting, then that seems to defeat the purpose.

[Goose66]

@hjdhjd What was your solution here? Did you end up implementing a firmware that supports use of the REST/EventSource API?

[rlowens]

The ESPHome firmware with the REST/EventSource API seems like the most accessible and most elegant transition from MQTT.

Or just enable the mqtt: service in ESPHome?

[Goose66]

The ESPHome firmware with the REST/EventSource API seems like the most accessible and most elegant transition from MQTT.

Or just enable the mqtt: service in ESPHome?

That would certainly work too! But it appears that MQTT is not enabled while the REST/EventSource is. I'm assuming that the REST/EventSource API and Native API (HomeAssistant) must be enabled as a package.

[Goose66]

Here's an apropos post from the Native API "documentation":

Advantages over MQTT

The ESPHome native API has many advantages over using MQTT for communication with Home Automation software (currently only Home Assistant and ioBroker). But MQTT is a great protocol and will never be removed. Features of native API (vs. MQTT):

• Much more efficient: ESPHome encodes all messages in a highly optimized format with protocol buffers - for example binary sensor state messages are about 1/10 of the size.
• One-click configuration: ESPHome just needs one click to set up in Home Assistant - no more messing around with retained MQTT discovery messages and alike.
• One less single point of failure: In the ESPHome native API each ESP is its own server. With MQTT, when the broker shuts off nothing can communicate anymore.
• Stability: Since ESPHome has far more control over the protocol than with MQTT, it’s really easy for us to roll out stability improvements.
• Low Latency: The native API is optimized for very low latency, usually this is only a couple of milliseconds and far less than can be noticed by the eye.

[Goose66]

I am also going to assume that use of the Native API prevents use of both Home Assistant and other integrations at the same time. The MQTT and the REST/EventSource API both allow simultaneous access.

If anyone comes up with a simple, lightweight method that could be spawn in its own thread and periodically ping the native API to keep the ratgdo alive, that would probably be the most expeditious solution.

[rlowens]

I am also going to assume that use of the Native API prevents use of both Home Assistant and other integrations at the same time.

The "Native API" IS the Home Assistant integration, so this comment doesn't make sense. Also, why would you assume that using it would prevent using the REST or MQTT services? I use api: and REST is still active, and I don't see anything in https://esphome.io/components/api.html that mentions it not allowing MQTT at the same time. And I just tried adding mqtt: to a test device along with api: and it didn't complain at all. In fact, the top of https://esphome.io/components/mqtt.html mentions removing api: if you are using mqtt: just to disable the timeout reboots, implying that using both works fine otherwise.

If anyone comes up with a simple, lightweight method that could be spawn in its own thread and periodically ping the native API to keep the ratgdo alive, that would probably be the most expeditious solution.

If you aren't using the native api: for anything, just remove it or set the reboot_timeout=0 and then it won't cause reboots. No need to have something fake the connection.

[Goose66]

I am also going to assume that use of the Native API prevents use of both Home Assistant and other integrations at the same time.

The "Native API" IS the Home Assistant integration, so this comment doesn't make sense. Also, why would you assume that using it would prevent using the REST or MQTT services? I use api: and REST is still active, and I don't see anything in https://esphome.io/components/api.html that mentions it not allowing MQTT at the same time. And I just tried adding mqtt: to a test device along with api: and it didn't complain at all. In fact, the top of https://esphome.io/components/mqtt.html mentions removing api: if you are using mqtt: just to disable the timeout reboots, implying that using both works fine otherwise.

I am saying that it appears two different integrations - specifically my UD Plugin and Home Assistant - can't use the Native API simultaneously.

If anyone comes up with a simple, lightweight method that could be spawn in its own thread and periodically ping the native API to keep the ratgdo alive, that would probably be the most expeditious solution.

If you aren't using the native api: for anything, just remove it or set the reboot_timeout=0 and then it won't cause reboots. No need to have something fake the connection.

I am not doing a one-off for myself. I am writing an integration for the UD ecosystem to interface with the ratgdo ("plugin" in the vernacular). It will be used by thousands (...ok, dozens) of people. I don't want to have to fork the ESPHome firmware and adjust yaml files and maintain a separate firmware version just for my integration. I am trying to use what's in the user-installable ESPHome firmware like it is.

[hjdhjd]

@hjdhjd What was your solution here? Did you end up implementing a firmware that supports use of the REST/EventSource API?

Yep…the same solution I had already implemented before I opened this issue - and I keep a connection to the native API open regularly so it’s happy. It works…but inelegant, as I said. Feel free to look through the homebridge-ratgdo repo to see how it’s done. 😄