Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Node type specification #152

Closed
Thalhammer opened this issue Jan 10, 2019 · 9 comments
Closed

Node type specification #152

Thalhammer opened this issue Jan 10, 2019 · 9 comments

Comments

@Thalhammer
Copy link
Member

I propose adding a set of predefined node types with required properties to improve the handling of devices by controllers.

We already have a required topic $type for each node, I think it would be a really good idea to define a set of types which require, but are not limited to certain properties. An example is given:

A "lamp" should have at least the following properties:

  • state

A "dimmable-lamp" should at least have:

  • state
  • level
@davidgraeff
Copy link
Member

See #38 and the linked PR and so on. I had proposed to have this as extension but at that time there was no extension mechanism in place.

@Thalhammer
Copy link
Member Author

Would this really be an extension?
The $type topic is already in place in the base convention. I think we would only need to specify its values.

@davidgraeff
Copy link
Member

It is about the values :)

@mjcumming
Copy link
Contributor

Has any work been done on specifying a core set of device/node/property types?

@mjcumming
Copy link
Contributor

Would it be better to have a device $type topic rather than a node $type?

@Thalhammer
Copy link
Member Author

@mjcumming I think there is a good argument for both.
Lets take the car example used in the convention.
Devicetype would be car and you have a couple of nodes with different types like light or engine.
Nodetype would probably be more important but I think both have there reason to exist.
But if we allow both we should probably make separate registries/lists for both as I don't think there is a lot of overlap between them.

@mjcumming
Copy link
Contributor

mjcumming commented May 3, 2020

Probably we should come up with some use cases to try and vet out the best approach. My thoughts are that any further development along these lines is to allow controllers to have a functional understanding of Homie devices.

Arguably, we need to start with properties and define additional properties (or behavior of existing). Ie. the OpenHAB implementation uses a Boolean for representing a switch or contact. That is fine but it should be defined somewhere. I use OpenHAB as an example and my guess is it is the most use controller for Homie devices.

I am not a big fan of the use of the car example. Its just not a home automation use case. I also don't really see the purpose of Nodes. Its nice on paper as a way to structure devices but in any of the 100 Homie devices I have connected to OpenHAB, the Node has no real functionality. I don't see where a controller needs to know anything about Nodes. But since we have Nodes I am not suggesting we change or remove that. But I (from my use) don't understand their purpose.

@mjcumming mjcumming reopened this May 3, 2020
@mjcumming
Copy link
Contributor

My mistake on hitting close....

@mjcumming
Copy link
Contributor

I am going to close this so we can keep all discussion in this thread.

#205

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants