BREAKING: Homie is about Lightweight topic discovery

[davidgraeff]

• $stats is fully optional
• Remove $fw, $mac and $localip completely. Those are all for firmware updates but at the same time not sufficient for a firmware update. Requires another spec, independent of how topics are announced.
• Remove "retained" column where applicable. Because "retained" is per default on, as specified in the header. Makes the spec easier for the eyes.

[ThomDietrich]

remove $fw, $mac and $localip

I get your point regarding firmware update but are those not also good for simple self-announcement?

[davidgraeff]

I don't think so. The Mac is required at the moment, but is not useful in an mqtt network where the broker can be in a different subnetwork. The localip attribute is flawed. Because an interface usually has more than one IP address nowadays. And it is the local IP only which is again not so useful for mqtt. And the $fw node is wrongly named, because a homie Linux client is technically not a firmware.

I'm not really sure what the benefit is for a controller to know those information.

An administrative tool would usually want to know about the firmware to perform ota. That's why I think we should make this an add-on convention that specifies exactly all information for ota to work.

[boc-tothefuture]

Are you proposing that we keep $implementation?

[davidgraeff]

Yes, but optional. There might be quirks in some implementations and knowing the implementation together with the homie version might help a controller to overcome those quirks.

[boc-tothefuture]

Would we want an optional implementation version as well? Using the quirks scenario you would need that if the implementation evolved at a different rate than the homie version.

[davidgraeff]

Might be a good idea, but is not part of this PR

[boc-tothefuture]

I can open a PR on it, after this one is merged.

[timpur]

Im with @ThomDietrich for $fw, $mac and $localip

MAC and IP are already required for the IP stack so why not just send them. Maybe make these optional ?

FW I think has quite alot of value actually. Maybe Implementation type makes more sense idk ?

Maybe these just need shuffling around where they should sit ?

Not sure the pros over come the cons here. But I'll let you guys discus.

[davidgraeff]

My controller and device implementations are both not homie compliant, because I don't publish or subscribe to those attributes and I'm not encouraging other device implementers to do so if they ask for the minimum compliance level.
I really thing this should be at least optional yes. Soon.

[boc-tothefuture]

@timpur The problem is, which mac and IP address should be sent and does that have value in all situations? If you have multiple interfaces and ip addresses, one can do some work with UDP sockets and figure out which IP and therefore interface the OS will use to get to the broker. That may have value, but that value reduces in many situations. For example, if your client is running in a docker container and routing out via a NAT and is not addressable on the network.

For firmware, lets say my I am fetching and publishing weather information from weather.com over the homie convention. What would my firmware be? The API version of the weather.com device I am fetching data from? I think there are a lot of use cases where firmware doesn't make sense to be required.

I think all of these values should be optional attributes under implementation because they are implementation specific.

[Thalhammer]

MAC and IP are already required for the IP stack so why not just send them. Maybe make these optional ?

No, they are not. IP does not require a mac to be present and many technologies which have no mac (almost everything which is not BT, WLAN or LAN). The most prominent example being 2G/3G/LTE.

[timpur]

So lets all agree on what and where these things should go.

I think all of these values should be optional attributes under implementation because they are implementation specific.

I really think this should be at least optional yes.

So optional values sitting under implementation ?

Also regarding foks who pointed out it doesnt always have to the mac and ip, why dont we reimagine these to allow for for options? eg address = "IP: 192.168.0.2, MAC: AB:12:CD:34:EF:56" (for standard IP networks) or address = "RF: 42" (for RF networks), also we could show the mqtt identifier "MQTT: esp1234". Basically address is some network identifiers ?? It cold contain the full stack of identifiers that the implementation is using ?

[davidgraeff]

@timpur: yeah that's all doable. But this PR is first about getting rid of Mac and localip and the other stuff that not all implementation need to have. Make a pr proposal for address or similiar

[timpur]

@davidgraeff , yeah i agree with that, i can do so, will think a bit more on the matter first though.

[timpur]

Looks good, please change the one comment.

[ThomDietrich]

My thought was to make Mac and IP optional, so that clients can implement them, when meaningful. However this is once again nothing that has to be part of the convention. An implementer/user can always add additional data. I agree to remove IP and Mac.

[davidgraeff]

@timpur Could you re-review and approve?

[timpur]

@davidgraeff , sorry different time zone ....

For anyone interested about the address stuff #129

[marvinroger]

As a reminder, the convention was initially created as part of the homie-esp8266 project, so things like firmware, MAC address and IP address all made sense then.

Now that homie has a broader audience, I'm definitely for these changes!