Handling device tree changes

[andig]

The homie protocol allows updates to the device tree, including unpublishing devices and/or adding and removing nodes and properties. I'm wondering how to best handle this on client side without generating excess traffic?

My thought was to listen for homie/# to get updated on device tree changes but that will get hit by all value updates as well. I assume homie/+/+ should work for devices + nodes (and the properties defined on the node).

Does that make sense?

[ThomDietrich]

For me your question would make more sense if you better explained your use case. Constant changes to the device tree should not be normal but these are of course supported. Are you sure that is needed in your use case? Your controller (i.e. the other device observing and controlling a homie device - is that what you called client above?) would need to actively re-discover your homie devices and nodes. This could e.g. be homie/+/$nodes or homie/+/$state or homie/+/+/$properties.

@davidgraeff is any type of automatic re-discovery implemented in the openHAB binding?

[davidgraeff]

The openHAB controller subscribes to every found node and property separately and reacts to $properties and $nodes changes.

[andig]

For me your question would make more sense if you better explained your use case.

My use case is a homie to volkszaehler bridge. As long-running daemon process and data concentrator it must be able to handle device tree changes.

would need to actively re-discover your homie devices and nodes. This could e.g. be homie/+/$nodes or ... homie/+/+/$properties.

Perfect.

An (edge) case would be updates to existing properties. The spec does not say so but imho- to limit complexity- it should not be allowed to update existing properties in their abilities, e.g. change $dataype. Instead, a property should be unpublished and republished including $properties. If that makes sense it should be added to the spec?

[davidgraeff]

If the original Homie creators would have wanted a 100% fixed property after publishing, they would have chosen a single topic for property description (eg $config), like the HomeAssistant MQTT component definition.

On the other hand, the openHAB controller is not able to react to $datatype or $format changes without property republishing.

A concise sentence somewhere in the Property section to state that it is undefined behaviour if any of those attributes are changed might be helpful, indeed.

[andig]

On the other hand, the openHAB controller is not able to react to $datatype or $format changes without property republishing.

Neither would I want to add this complexity.

A concise sentence somewhere in the Property section to state that it is undefined behaviour if any of those attributes are changed might be helpful, indeed.

How about:

Controllers MUST not update property attributes after initial creation. To modify an existing property's definition, a controller MUST comply to the following steps:

• the property MUST be removed from the node's list of properties
• the property and its attributes MUST unpublished
• then finally the updated property can be be published

I think the same would be true for nodes, so rather make this a general section?

[Thalhammer]

A concise sentence somewhere in the Property section to state that it is undefined behavior if any of those attributes are changed might be helpful, indeed.

To be honest I don't feel well changing the spec just because a single controller implementation can't deal with it. Instead one should update the controller in order to support it.

[davidgraeff]

@Thalhammer That is actually not really possible. $format and $datatype are strongly coupled and a sane person would always send those attributes together in one entity. Homie decided to split them up, we are walking the insane path here.

I would not FORBID to change those attributes like @andig proposed, I would just hint the reader, that controllers might not be willing to update a property once those attributes are published and a change of $properties/$nodes is required first.

[davidgraeff]

@andig Nodes do not have these problems. There is only $name and $type, verbal descriptive attributes. They may change at any time.

[andig]

Instead one should update the controller in order to support it.

Imho this is about sane behaviour as @davidgraeff pointed out. From that perspective the spec is very open and therefore open to some amount of insanity.

[andig]

I would not FORBID to change those attributes like @andig proposed, I would just hint the reader,

@davidgraeff would you accept a PR with SHOULD instead of MUST? If not- do you have a better approach?

[davidgraeff]

Go for it. We can fine tune the pr in the process. I guess it is better to have a restriction in for 4.0 that, if necessary, can later be relieved, than other way round.

[mjcumming]

I can't see on the spec page how to add/remove a node or add/remove a property after a device has been published?

How does one add additional nodes to a device that has already been published?

[andig]

How does one add additional nodes to a device that has already been published?

I understood that the process for either nodes or properties is to publish your new node or property and update $nodes/$properties. Both operations need to happen within spec time which is 500ms.

[mjcumming]

When adding a new property to a node of a device that has already been published, is it ok to publish all properties of the node or only properties that have not been published before?

[davidgraeff]

The spec doesn't specify this. I would say it doesn't matter. The mqtt broker knows the topic values already, but will re-publish them. Controllers must cope with re-published but unchanged properties.

[mjcumming]

When removing a node or property, should there be a publish event for that node or property that removes the retain flag?

[andig]

The spec does currently not specify this. Imho $properties/$nodes should be leading but properties updates must be finished within 500ms. I would consider it good practice to unpublish retained topics within those 500ms, too.

[andig]

Closing this one as the discussion is at least partly superseded by #155.