Devices, nodes and properties - discussion on improving automatic discovery

[mjcumming]

The Homie convention needs further development to support automatic device discovery so that controllers can not only discovery but interact with devices with ideally no/little user configuration. From my perspective, there are 2 areas we need to work on - device layout (nodes/properties) and property behavior.

To begin with we need to further vet out what properties we should use for common home automation devices so that controllers can work with them in their respective framework.

Some examples:

SWITCH: There is no switch payload. So how is a switch implemented? Is this a string payload with ON/OFF? An enum payload with ON/OFF? Or a boolean payload with true/false.

OpenHAB Homie, uses a boolean payload and will map that to a Switch item.

DIMMER: There are several payloads that could be used for a dimmer: Integer, Float, Percent (with either integer or float). This caused a lot of confusion with the initial OpenHAB Homie implementation that has only recently been fixed.

OpenHAB Homie uses a percent payload and will map that to a Dimmer item.

CONTACT: A contact, similar to a Switch, could be mapped to a string, enum, or boolean payload.

OpenHAB Homie is not able to map any payloads to a Contact item.

Would like to see what others think about further developing the convention!

[tim-hellhake]

Hi @mjcumming,

I'm currently developing an integration for the Mozilla WebThings gateway and I have a similar problem. The WebThings spec provides a list of capabilities such as Thermostat and corresponding property types such as TemperatureProperty and TargetTemperatureProperty. I would like to avoid guessing the correct capability based on the name of the device. There is a $type property in the spec but there is little information about how to use it. I thought about creating a new extension to describe those capabilities in the spec.

[Thalhammer]

The type property in fact was designed for exactly this purpose. However we have not (yet) defined a list of types.

[tim-hellhake]

The problem is the $type won't tell you how to use the thermostat even though you know it is one.

[bggardner]

My gut reaction is that controllers shouldn't care whether it is a switch/dimmer/contact. They should be able to read the $datatype and display the appropriate indicator/control along with the $name. Coming from HTML, I see switches and contacts (see <input type="checkbox">) as booleans, and dimmers (see <input type="range"> or <progress>) as floats between 0-1 (or integers between 0-100, or percentage; which is your point, but $min and $max could fix this). However, I understand your frustration.

I was searching for an existing issue to bring this up, and this might be the best place based on the title. I see the device/node/property scheme to be very limiting. Is there a reason that the hierarchy can't be "infinite", that is: homie/node/node/.../node/property, with each topic element having a $children attribute? Or, a child node could just be a type of property of its parent. I realize this is a fairly significant change, but I've struggled with implementations. Thoughts (or suggest opening a separate issue)?

[piegamesde]

@bggardner This is an interesting topic, please create a new issue.

[bggardner]

The $type property should not be required (or used in the convention at all) unless/until a list of types is defined. If what @Thalhammer says is true, then the only valid value should be an empty string until types are defined in the convention. Otherwise, it's simply metadata, and should not be required.

[jorgh6]

I think this is an important discussion.

I've created a Python script that publishes all my Domoticz devices in MQTT, using the Homie Convention. I had to make some choices here, and can easily see that someone else would make different choices. Although this would not conflict with the Homie convention, it would make the discovery process, and specifically how to represent the device a lot of hassle.

Here you can see a part of what I've created to represent a dimmable switch from a Domoticz device.

homie/domoticz/$state ready homie/domoticz/$homie 4.0.0 homie/domoticz/$name Domoticz homie/domoticz/$nodes 92,1,2,3,5,103,28,6,10,9,8,14,12,11,68,23,7,15,19,20,18,66,89,88,73,91,99,100,101,102,104,105,106,107,108,126,127,128,129,77,54,40,140,148,141,142,143,145,155 .... homie/domoticz/14/$name Kitchen table homie/domoticz/14/$type dimmer homie/domoticz/14/$properties switch,level homie/domoticz/14/switch On homie/domoticz/14/switch/$name switch homie/domoticz/14/switch/$datatype enum homie/domoticz/14/switch/$settable true homie/domoticz/14/switch/$retained true homie/domoticz/14/switch/$format On,Off homie/domoticz/14/level 15 homie/domoticz/14/level/$name level homie/domoticz/14/level/$datatype integer homie/domoticz/14/level/$format 0:100 homie/domoticz/14/level/$settable true homie/domoticz/14/level/$retained true ....

I've made some choices here, on $type, $properties, $datatype and $format.

As the convention does not give any guidance (or defined list) of $type, I've could have easily chosen $type=lamp for example On $properties, 'state' and 'dimlevel' would also be correct choices. for the 'switch' property alternatives are:

homie/domoticz/14/switch/$datatype enum homie/domoticz/14/switch/$format Closed,Open .... homie/domoticz/14/switch/$datatype integer homie/domoticz/14/switch/$format 0:1 .... homie/domoticz/14/switch/$datatype boolean .... etc

I could also have made the choice to make both a dimmer and a on/off switch the same type ($type=switch) and only distinguish on the exposed properties (having a level for only for dimmers).

For a human, using MQTT explorer it would in all cases be self explanatory how to use the device. However automated processing will be very difficult if everybody makes different choices, although they all comply with the Homie convention. this makes the adoption of the standard difficult. And this is just an example of a very simple device. Imagine the same discussions for more complicated devices.

I think adding standards (or at least guidance) on these choices would greatly benefit the automatic processing of Homie devices and ease the adaption of this standard.

[tim-hellhake]

@bggardner

My gut reaction is that controllers shouldn't care whether it is a switch/dimmer/contact. They should be able to read the $datatype and display the appropriate indicator/control along with the $name.

That might be true for simple devices, but if you have something a thermostat, you have at least two temperature properties with a totally different meaning. Describing the meaning of the properties allows the controller to build a user-friendly UI.

@jorgh6

I think adding standards (or at least guidance) on these choices would greatly benefit the automatic processing of Homie devices and ease the adaption of this standard.

I totally agree.