Elaborate on the $type idea #92
Conversation
Elaborate on the $type idea. Property and Node both should have an optional $type attribute. Some easy, probably most-used predefined $types should be included to not fragment the homie device landscape for those simple nodes/properties.
|
Way to go David 🎉 thanks for catching up on the idea.
This was my issue so far. How do we decide on this counted list, who defines what a "fridge" comprises? |
README.md
Outdated
| homie/super-car/engine/$properties → "speed,direction,temperature" | ||
| ``` | ||
|
|
||
| `$type` can be any string. The following predefined node types allow controllers to identify and present a node in a more distinct way: |
There was a problem hiding this comment.
I'd suggest to add a level 5 headline. Also please break down lines to one sentence per line.
There was a problem hiding this comment.
I would also change from "any string" to a topic id, since it makes more sense (after all, a $type is an ID)
| </tr> | ||
| <tr> | ||
| <td>$name</td> | ||
| <td>Device → Controller</td> | ||
| <td>Friendly name of the Node</td> | ||
| <td>Yes</td> | ||
| <td>Yes</td> | ||
| <td>No (the node ID is used)</td> |
There was a problem hiding this comment.
Sounds like the view by someone who implements the controller side of the convention 😃
From the convention side of things: Do we want to give such promises or do we want to leave this decision to the controller?
There was a problem hiding this comment.
Yes I'm not sure about this one. It potentially saves space on the device if the node is called "Temperature" and the name would be the same.
README.md
Outdated
| <td>The type/category of this property</td> | ||
| <td>Any string, see recommended types below</td> | ||
| <td>Yes</td> | ||
| <td>No (The property ID is used)</td> |
There was a problem hiding this comment.
Makes sense actually. You can choose the property Id based on the type like in the example "temperature". Type would only be used if for any reason you can't name it that way like with multiple temperature sensors.
There was a problem hiding this comment.
This might be related to #51.
Feel free to add your recent experiences there! ;)
There was a problem hiding this comment.
it is actually not about the controller this time. It is about saving memory on the constrained device by choosing a decent property id to not also be required to implement $type, I though
There was a problem hiding this comment.
Then I still don't get it. Every optional argument not published by the "constrained device" will not cost anything. On the controller-side a default needs to be selected of course. For settable the default is false, for $type the ID might or should used. Correct?
|
Can we wait a bit for discussion before just pushing thought what you want. We haven't yet come to a conclusion on this issue. |
|
I like to propose suggestions by PRs, @timpur. That's just a form of discurs and is something concrete to base a discussion on it. Because a lot of issues getting quite long without a single line of improvement on the spec :) |
Change any string to any Topic ID string
|
I really like this idea, however, we really have to make sure to only require the bare minimum for each type so we do not force devices to implement features they actually don't have. |
|
Actually I like to change the PR once more and remove the type suggestions. I would favour #101 and split type suggestions and the core convention. |
Partly implements #38
Elaborate on the $type idea. Property and Node both should have an optional $type attribute. Some easy, probably most-used predefined $types should be included to not fragment the homie device landscape for those simple nodes/properties.