Implementation topic should support optional values

[boc-tothefuture]

As discussed in #120 the implementation topic should support optional sub topics containing implementation specific items such as ip, mac, implementation version, etc.

Putting this in as a placeholder until #120 is merged as it does not make sense to create until merger.

This is to track this idea so it is not lost from view once #120 is merged.

[ThomDietrich]

Please correct me if I misunderstood the issue.

Additional topics, e.g. homie/super-car/$myspecialinfo can always be defined by the implementer/user of the convention.

[boc-tothefuture]

@ThomDietrich -
My understanding of the discussion was that we are taking many of the required properties out of the device section and they would potentially find a better a home as implementation specific properties. To me, that would fall under homie/$implementation/#

The convention already states:

You can use any subtopics of $implementation for anything related to your specific Homie implementation.

I was going to do a minor update stating that some previously required attributes are now implementation subtopics and provide some examples such as implementation verison, IP, HW Address, etc.

Although, we could decide that we don't need examples for any optional sub topics.

[davidgraeff]

It's a different discussion if you want to introduce an $implementation-version or similar and that mac, localip, fw attributes will be removed. They will go for now and will not be resettled to a different topic, because they are not thought through to the end.
Everything required for ota should be discussed in the relevant issue instead :)

[boc-tothefuture]

@davidgraeff ota?

Edit:
ahh.. Over The Air.

My only thought with this issue was to further expand on what possible things will go as a subtopic under implementation. It will be a minor clarification/hint in the spec.. Nothing major.

[Thalhammer]

I don't think $implementation is the right place to put such things and if it is I don't think it is the job of homie to specify how. As you already quoted:

You can use any subtopics of $implementation for anything related to your specific Homie implementation.

Maybe I'm wrong but the way I interpret this is: Do whatever you wan't below this topic, which means that any specification there would be a breaking change.

Things like IP and mac are not specific to a single implementation either but are quite universal. I'm not entirely sure where to put them, but $implementation seems the wrong place. Maybe $stats ?

[boc-tothefuture]

I am not sure that MAC and IP are universal. If you see the other PR, there are many situations where MAC and IP don't make sense. May make sense for an ESP device, but provides little value for a pure software implementation running in a docker container whose network is NATd.

I was not going to propose required implementation details under $implementation. Rather attempt to provide some examples of optional topics such as implementation version, MAC, IP, etc that may be under $implementation.

[timpur]

Shoot, didnt see this till just then.... i made #129. Should i close for this ?

[boc-tothefuture]

@timpur
Sure - since we have some of the same discussion going on here already.

[fermuch]

I would like to add to the discussion:

My implementation uses a bridge over PJON to send its data over cable and LoRa. Since PJON doesn't have any kind of concept for MAC nor IP, I don't see how I would add it if it is required. If they are marked as required, please add an IP and a MAC indicating it is not meant to be accessible, like 192.0.2.0/24

I would very much preffer if these attributes are declared by each use case on $implementation, since any kind of communication to your devices (on the scope of the Homie convention, at least) should be only over MQTT IMHO.

[davidgraeff]

Right now, I don't see a usecase for an "ip" attribute. The device-id is the unique identifier for a homie device, and the controller doesn't need to know anything more.

Manufacturers actually start to restrict visibility of hardware addresses and assigned addresses.
On Android for example as an App you cannot access the MAC address anymore and the enumeration of interface IPs only with specific permissions.

For me only "$implementation/version" makes sense somehow. That could be specified in the convention so that people don't start to have "$implementation/ver", "$implementation/version_number" and so on.

Personally I would suggest to unite name and version in the currently existing "../$implementation" topic. For example "ImplementationName - ImplementationVersion" and don't specify anything more.

[Thalhammer]

In addition to this there isn't a lot of use for ip (and even less for mac) even for OTA since there are numerous ways to do OTA, all of which do not require knowledge of the devices IP.
In addition to this many times the IP sent by a homie device wouldn't be reachable by the controller anyway since it would very seldom be a public IP.

[davidgraeff]

I think I found your use case guys. You need the IP for your esp in your local network, to access the hosted webpage for configuration. I'd say the right solution would be upnp or bonjour discovery instead.

[Thalhammer]

You need the IP for your esp in your local network, to access the hosted webpage for configuration.

I don't think this is the job of homie. And how do you configure it to use the homie broker if you don't have its IP already. I do however agree that there might be usecases, thats why $implementation is there in the first place. To allow implementers to add features where they make sense.

[davidgraeff]

@boc-tothefuture Could you come up with a concrete proposal with use-cases, please.

[boc-tothefuture]

@davidgraeff
Will do, its on my list now that #120 has been merged.

[boc-tothefuture]

I am closing this issue. #129 has the active discussion on the same topic.