Topology is too limiting

[bggardner]

I see the device/node/property topology to be very limiting. I've struggled with creating the proper topology in my implementations, and feel that an "infinite" hierarchy would be more flexible. That is, there would still be a root topic, but everything in between that and properties is just a Node. It would be a hybrid between a Device and the current Node, but allow for a hierarchy of parent/child Nodes. The conflict would then be how to determine which next-level topics are properties vs. child nodes. This could be solved a few ways, but I propose that child nodes are just another type of property (datatype of "node", maybe?) (or an opposite way: include properties in the node's $children attribute with $type of "property").

While this may seem like a major change, it can also be seen as a simplification, as we would be reducing the number of defined elements from three (Device, Node, Property) down to two (Node, Property). The positives are obvious to me, but I'm interested to hear how this would negatively impact implementations. One negative would be that it would invalidate using wildcard subscriptions, specifically for home/device-id/node-id/+/set. Thoughts?

[piegamesde]

While this would conceptually simplify the homie spec, I fear this comes with a lot of added complexity on the implementation side. But before discussing all the downsides, please explain the benefits of an unlimited tree hierarchy some more. I'm absolutely fine with the fixed depth of 2 and I never had the desire for more nesting*. Some examples might help here.

* I can see use cases where less depth (= having properties on the root level), which is also implied in your proposal, might be desirable. But it's a weak plus since the modeling can easily be adapted to fit the current structure.

[bggardner]

I agree it would add undue complexity on the implementation side. Initially, I thought it would be convenient to break down complex properties (structs) into their own hierarchy, but realized they could just be flattened into multiple properties. Example:

Problem:
Property(name="owner", value='{"fname": "John", "lname": "Doe", "age": 50}') // Homie doesn't like JSON

Solution:
Property(name="owner-fname", value="John")
Property(name="owner-lname", value="Doe")
Property(name="owner-age", value="50")

So, probably case closed. Maybe a similar example to the above could be added to the documentation to address the issue.

[piegamesde]

Homie doesn't like JSON

Yes and no. Just because you don't need any JSON to do Homie does not mean you can't use it at all. There is no need to standardize every possible value for every use case. When passing custom data around between two applications using Homie, using ad-hoc serialization is perfectly fine (to me).

So, probably case closed. Maybe a similar example to the above could be added to the documentation to address the issue.

I'd then suggest closing the issue and opening a pull request if you really think the spec is lacking an example here.

---

P.S.: I still don't understand the motivation for your example. Out of curiosity: Why are you putting a person's name and age over MQTT?

[bggardner]

OK, I got the impression that Homie thought JSON was evil and to try to avoid it. I stand corrected.

P.S.: The example was purely theoretical. One of my use cases involves interfacing over a serial bus, in which information containing multiple data types is packed into a single data packet. So, it would just be convenient to treat that data packet as a complex Homie Property with multiple sub-Properties, each with their own data type. Hence, my desire for more levels in the topology.

[ThomDietrich]

Homie thought JSON was evil and to try to avoid it. I stand corrected.

Of course not evil but avoiding a loose JSON structure in favor of a fixed MQTT structure was one of the design goals.

Yet again, just as @piegamesde said, it is of course in your freedom and perfectly fine to send JSON as additional data over MQTT - for the benefit of your use case. Remember that Homie is here to enable device and capability discovery. Beyond that you can add as much complexity as you wish.

[Tieske]

related: https://github.com/homieiot/convention/pull/240