How to announce sub specifications

[Thalhammer]

This is a tracking issue for the discussion started in #109.

How should sub specifications for example to support OTA be announced by a homie device ?
What if the device stops to support those ?

[timpur]

Good question, i can imagine @davidgraeff has an idea??

Side question, can this also allow us to specify (recommendations) on higher level nodes, like a light, relay, or temp sensor ect...? I think it would be nice for the community to also have a place were we can define these things ?? This is also important for Home Automation tools like OH and HA. @davidgraeff , it would be nice to have OH and HA compatible with Homie node definitions IMHO (this is something id like to work with you on)??

[davidgraeff]

Personally I think we need about 4 different documents (each in their own repository with own versioning). I have prepared this for the web page script already in https://github.com/homieiot/convention-website/blob/master/multiversion.yml.

I assume we'll have homie-core, homie-ota, homie-types and homie-stats.
The mentioned order should also form the priority.

I would say each spec publishes its own version like homie/device123/$homie-ota -> 1.0
and has a last-will that erases the version topic.

[Thalhammer]

and has a last-will that erases the version topic.

I might be misstaken, but doesn't allow mqtt only for a single last will ?
This would mean we need to open a separate connection for every doc, which might cause problems on low end devices.

[davidgraeff]

You are right, a last will is not a solution then.
How about overwriting the sub-spec topic for example homie/device123/$homie-ota with a non-retained empty message?

[Thalhammer]

Doesn't work either since a device which doesn't know the subspec can't overwrite it.

I propose adding a device attribute to the core spec which lists all supported subspecs.

$subspecs, required no, retained yes
Format: spec(version),spec2(version) with version being optional. If the attribute is not there it should default to an empty string.

This would be a non breaking change to the core and allow for good detection of supported specs. Could you outline why you don't like it ?
Making it a required topic would be even better, but then it would be a breaking change. Maybe in version 4.0.0 ?

[davidgraeff]

I don't get what you mean.
A client say a esp8266 microcontroller supports Homie, so it publishes to homie/device123/$homie. And it also supports OTA, so it publishes to homie/device123/$homie-ota.

And now imagine someone disables OTA in the configuration page, or the firmware is recompiled without OTA support: The device would just erase (publish an empty string) homie/device123/$homie-ota whenever it starts.

[Thalhammer]

I also propose using reverse domain names (similar to java) for subset ids (i.e. homie.ota for official ota) or it.thalhammer.sample for unofficial/vendor additions.

[davidgraeff]

I like the specification documents to be independent. But I can image that the homie core convention only introduces the homie/device123/$spec attribute and the actual keyword is defined within those other specifications.

[Thalhammer]

Yeah that would work, but what if the device does not have the ability to delete the topic ? For example consider this case:
Firmware supports ota. Update gets installed and new firmware does not support it anymore. $homie-ota will still be there and every controller thinks ota is supported when in fact its not. You can't just delete all non supported subsets since you don't know which one even exist. With a single topic you don't have this problem. And it fits into the rest of the specification as well, just look at $nodes

[Thalhammer]

But I can image that the homie core convention only introduces the homie/device123/$spec attribute and the actual keyword is defined within those other specifications.

Thats exactly what I intended. The subset spec would be completly independent, the only thing that changes in core is a single topic that contains a list of ids with all supported specs to allow for discover

[davidgraeff]

Could you create a PR? I like the idea of reverse domain names. Not so much your "spec-name (version)" syntax which is harder to parse as well as to create in the first place. A single separator should do it. A domain is quite restricted in its allowed character set, a comma might be fine.

[Thalhammer]

Yeah sure, I'll write it up tomorrow and create a PR.

It was just an idea. You can also only list the ideas and provide the version in a topic defined by the individual specs.

[Thalhammer]

#132