Defining implementation Attributes for FW and Address

[timpur]

In #120 some Attributes were removed:

• $fw/name
• $fw/version
• $localip
• $mac

Lets discus about how to reimplement them, but also reimagine these attributes.

FW:

This was discussed to be moved under $implementation.

Address:

This was discussed to be moved under $implementation, with a redesign

Out of that discussion i suggested for ip and mac, maybe something like this address = "MQTT: ESP1234, IP: 192.168.0.2, MAC: AB:12:CD:34:EF:56". Some people mentioned that an address doesn't always have to be the ip stack, thus address = "RF: 42".

The idea is that this attribute can contain every address for the stack used for a particular implementation.

Format for $address: = {addressType}: {addressValue} with , separated.

Looking for feedback. :)

[Thalhammer]

This would also allow one to add things like cellular phone numbers. Do you plan on defining the types in the standard ?

[timpur]

Yeah if thats part of the implementation stack, then sure. I think we'd define the structure of the attribute , but not lock it down. Might also have some examples/recommend values ...

[fermuch]

address might also refer to a physical address (floor number, room name). In the context of a physical address, it is common to use ,. A better separator might be |.

Some concerns I have:

• Are spaces ignored? Is it valid if I write IP: 192.168.0.2, MAC: AB:12:CD:34:EF:56" (three spaces between IP and MAC)
• : might be difficult to parse in a microcontroller without regexes, since for example it is both used as a describer (MAC:) and as a separator for MAC addresses (AB:). It might be easier to use a format like IP(192.168.0.2) MAC(AB:12:CD:34:EF:56)
• This feels like expressing nodes/properties inside a property itself, so why not use homie properties? For example:

$address/ip -> 192.168.0.2, 192.168.25.31, 2001:0db8:85a3:0000:0000:8a2e:0370:7334
$address/mac -> AB:12:CD:34:EF:56

That way you can also subscribe to IP changes without having to re-parse everything.
We could also use homie's arrays for ips.

[davidgraeff]

Why not combine this with the $location proposal that was made in #3, pardon #78? The device, a node and attributes are allowed to have a $location. Location can have sub-topics like:
homie/device123/$location/IPs
homie/device123/$location/telno
homie/device123/$location/MAC
homie/device123/$location/geo
homie/device123/$location/text
homie/device123/$location/relative

Because IP, MAC, telefon number seem to be used for locating the device.

[timpur]

See this is why we discuss, good ideas guys. Do we want to seperate network addresses and physical location ? Id like to see a division between the 2 TBH but lets discus.

[Thalhammer]

I don't think it would be necessary to separate them but if they were separarted I wouldn't complain either. At least in bigger networks they are almost equivalent anyway since ips are given out based on the physical location inside a building.

[davidgraeff]

Do we need this defined for Version 4? If not, I'd like to remove it from the Project https://github.com/homieiot/convention/projects/1

[Thalhammer]

Do we need this defined for Version 4?

Don't think so, since we could also add it as an extension later if needed.

[davidgraeff]

@timpur: In different proposals you tried to invent a syntax to express a "map" like structure, also in this one. Maybe we should instead introduce a new data type: "json object"? (Almost) every embedded platform has a JSON parser/builder.

[timpur]

@davidgraeff true, but i dont like the idea that homie requires a device to have a JSON formatter, when it can be avoided.

Maybe IP and Mac falls under stats ??

[ThomDietrich]

Regarding JSON, this might not be closely related but there was a very similar discussion a long time ago: #12 (comment)

I'm generally a big fan of jsonifying stuff but Homie is atm free of it. In fact I'd say that an alternative JSON option to parts of the convention would be very convenient in some situations and we should discuss that for a later major version of the convention. JSON should be avoided for now.

Regarding firmware version, IP address or location: All of those are additional and optional attributes of a device but with reduced importance and with none significance to discovery. Because of this I suggest to move them under a neutral attribute like $details instead of $address or location.

If there are no strong objections, I will prepare a PR in the next couple of days.

[mjcumming]

@ThomDietrich can this be closed?