vague proposal: reconsider OTA updates

[boneskull]

As it stands, the OTA flow is much more akin to a request/response or RPC-style communication model. This can be difficult to work with because of the sequence of messages which need to be sent or received. Sequences of messages don't fit well into the MQTT framework; QoS and retained messages can cause unexpected behavior, and it's awkward to write a client to interact with.

I have a couple suggestions to address this.

1. Eliminate the separate "checksum" topic.

   We can embed it in the $implementation/ota/firmware topic itself, e.g., $implementation/ota/firmware/415bad882596a05b1c99952e5ead5512 with a message containing the firmware blob. A device can then accept or reject the firmware and publish status and progress message(s) accordingly.

2. Support an alternative method of OTA updates.

   Since we can run an initial configuration of a Homie device over HTTP, it suggests HTTP could handle OTA updates.

   HTTP would be a more appropriate protocol to use because of its request/response nature. Multiple requests and responses, if necessary, would be easier to handle. A "transaction" could be modeled by using a cookie. Basic authentication could be implemented as well.

   If HTTP is too heavyweight, CoAP or another request/response-type protocol would be acceptable.

What are your thoughts?

[marvinroger]

Hi,

The first idea is indeed a good one. @jpmens yet another OTA method, sorry, but things will stabilize once 2.0.0 final is released. What do you think?

It would simplify both the ESP8266 and OTA entity code, and still respect the #220 concern, while indeed avoiding RPC.

HTTP updates were available on the v1, but this is a design decision to only allow updates over MQTT. That way, you can benefits from all features with only an MQTT broker. Moreover, the code is asynchronous, and the HTTP client is not (and there's no ESPAsyncTCP implementation available).

[marvinroger]

Please continue here: #346