Add more information regarding OTA

[ghost]

Currently, the v2 draft only defines the $ota topic. I think the OTA mechanism from the v2 homie-esp8266 "reference implementation" should be added to the spec. That is, $implementation/ota subtopics should be mentioned.

• $implementation/ota/enabled
• $implementation/ota/payload

I would even suggest to move these topics from the $implementation tree to the $ota tree because IMO Homie firmware updates should not be specific to a particular implementation. Generic tools like homie-ota should be usable out-of-the-box for any Homie device, whether it runs homie-esp8266 or some other Homie runtime.

[marvinroger]

I made this choice because, if you think about it, OTA is very much implementation related. Look at homie-python. This is not actually a firmware blob, the firmware is Python code, so you'll want to update it through git, for example. A Node-RED flow might also be updatable by pulling the latest flow file from an HTTP source. If you build something on a Raspberry Pi running Docker, your firmware could be updated by pulling the latest container layers. There are many, many OTA strategies. I'm even considering removing the top-level $ota property so everything OTA-related would be in $implementation/ota, it just makes more sense.

A GUI could be compatible with all these OTA strategies based on the value of $implementation. Therefore, it could adapt it's behavior.

Do you get the point?

[ghost]

I did get the point :-)

I actually had other embedded systems like Arduinos or mbeds in mind. But, yes, git or docker should definitely stay outside the scope of Homie.

I think moving the $ota function to something like $implementation/ota/version would improve consistency.

[ghost]

@marvinroger Coming back to potentially renaming $ota into $implementation/ota/version or something. Are you still considering this? I could work on a PR for homie-esp8266 and also work on a matching PR for homie-ota. Let me know.

Another question along these lines: having used OTA a lot during the past two weeks it was cumbersome having to change firmware versions all the time just for the version number check to pass. I ended up patching my homie-ota such that it deliberately sends a bad version number. Would it be acceptable if Homie added a convention that an OTA server can force the update by appending an exclamation mark to the version number? In production, the OTA server sends a version number 1.0.0 as of now. During development, the OTA server would send 1.0.0! in order to bypass the version number check. No code change to homie-esp8266 required.

[marvinroger]

I think it would be more consistent, because not every devices require OTA, so that's also implementation related. If you agree, then yes, I'm all for it.

Good idea, I also ended up doing that, so definitely!

[marvinroger]

Actually, if we remove $ota, OTA becomes implementation specific. So the ! at the end would not be a convention in Homie, but in Homie for ESP8266 instead. And as you say, there's no change required there, so it would only be a doc tip.

[ghost]

I agree, consistency is desirable, one way or the other. Since you asked, I have slightly different take on this. I personally think that Homie SHOULD have a generic convention for OTA. I would rather move stuff from $implementation/ota/... to $ota/... and extend the OTA definition to other embedded devices (not the "Docker league").

[marvinroger]

Given what we've done with homie-esp8266, I guess we can close this, right? 😄

[ghost]

Sure.

Only, appending "!" to force the update doesn't work anymore because "!" is not a valid md5 character and we're checking for exactly 32 chars. Anyway. It's easy to invalidate an md5 ;-).