Regarding simplification and additional node wishes

[davidgraeff]

Tags: Organisation, Convention/Spec document layout

It looks quite immature for the outsider if there are major version bumps of the spec like every some months. A modular system might help:

Thing of a Homie Core 1.0, Homie Device Statistics 1.0, Homie System Information 1.0 and so on. If one of those parts change (version bump), the rest can still be understood by a controller. The current situation is: /home/device/$localip moves to somewhere else or gets a different semantic and because of that and a 4.0 version bump of the entire spec, a controller is not able to do discover device nodes anymore? Doesn't sound right.

The Homie Core 1.0 convention

My suggestion is: Throw everything out of the core spec that is value related. Only device, node and property discovery should be part of the the core. No statistics, no ip, no mac. No suggested/recommended "$type"s.

Homie Device statistics 1.0 spec

I suggest to introduce a new kind of node (prefixed with "_"). Those are defined by a related specification.
Add a "_stats" node with all those optional properties ("cpuload", "battery" etc). The advantage is: No special case for the controller anymore. If battery is a percentage, then set homie/device/_stats/battery/$format=0:100 and the controller knows how to render a property, even if additional properties are specified later on.

The controller might need to know the version. Add homie/device/_stats/$version=1.0.

Homie System Information 1.0 spec

Basically all those ip, mac, soc, app version, os version, service ports and so on information. Stuff that is party necessary for updates or direct communication.

The controller might to know the version. Add homie/device/_system/$version=1.0.

Homie Node Types 1.0

Define some node and property types for controllers to render nodes and properties correctly. Something like:

• light homie/device/mk12a/$type=light: Needs "power". Optional: "color", "dim"
• switch homie/device/gang1/$type=switch: Needs "power".

Split the convention into multiple files

The core document should link to those other files in prominent places but should not contain anything related expect examples.

Split up the repository

Every of those mentioned specs should get an own repository for issue discussing and preparing spec documents which are then merged into the main repository on full member agreement. Almost no issue here is about the core spec anymore. It is mostly about additional nodes, additional types and so on.

[fermuch]

I'm with you, @davidgraeff, on having a minimal spec and then branching out to "how to implement complex stuff with homie", but more as tutorials instead of complementary specs. “How can I implement a home alert system with Homie?” “How can I implement a smart refrigerator with Homie?”

If there are several specs, how are we supposed to keep track of them? How are we going to version? What if Homie Core 3.1.0 is incompatible with Homie Node Types 3.1.1?

---

The current spec is OK right now in my opinion. I don't have much experience, and it's been not so long since I started using Homie, but what confused me was: versioning. At the time there was next, 2.0.0, and some other branches and forks. What the spec needs right now is to be concise. After reading it one time anyone should have a clear idea of how to implement Homie. After reading it twice, anyone should have a clear idea of why Homie is implemented how it is.

Most of the confussion comes now from, as far as I could see:

• the spec not being clear about something (how can I implement state over Homie? No one told me I needed to know how last will works, nor what it is or what spec it comes from),
• the spec not providing enough examples or concise enough examples (how am I supposed to treat arrays? Why not just use multiple nodes instead of arrays)
• the spec doesn't give an explanation for its decisions: Why even have $stats?

[ingoogni]

Played with it a bit

Homie(Core)
 |
 --- HomieDevice(Name)   ---> DeviceName(homie) name space
 |     |
 |     --- HomieInf
 |     |
 |     --- HomieStats
 |                 |
 |                 --- Propertie(s)
 |
 |
 --- LightDevice(Name)    ---> DeviceName(light) name space
 |    |
 |    --- Node(s)
 |    |
 |    --- Node
 |            |
 |            ----- Propertie(s)
 |
 --- OtherDevice(s) ...

No need for underscores m.i, with proper topic strings (#57 sadly the discussion it references is deleted as it touched upon this).
Agree with @fermuch especialy on Homie Node Types, it should be examples.

[davidgraeff]

The current spec is OK right now in my opinion. I don't have much experience, and it's been not so long since I started using Homie, but what confused me was: versioning.

I don't agree. Homie 3.x does more than being a convention. It defines topic values at the moment.

the spec doesn't give an explanation for its decisions: Why even have $stats?

That's my point. The core should only define the structure of topics (introduce a convention). Nothing value related. Every value related piece need to go into another, a second document.

If there are several specs, how are we supposed to keep track of them? How are we going to version? What if Homie Core 3.1.0 is incompatible with Homie Node Types 3.1.1?

Additional specifications should not be allowed to build on top of each other (as a start at least). An additional document can define at the very top the minimum Homie Core specification required. I don't expect Homie Core to change often.

but more as tutorials instead of complementary specs. “How can I implement a home alert system with Homie?” “How can I implement a smart refrigerator with Homie?”

We do have the $type attribute. Why not use it and define some basic types. It would help a lot on the controller side, if it is known if a node assembles a light, a switch or a temperature sensor for example (the most common use cases probably). Everybody is always free to use a custom type string, but if any of those reserved ones are used, they need to conform to the Types specification.

[ThomDietrich]

@marvinroger I think the extend of this issue means all hands on deck. Could you please add your opinion?