Support $type of Homie nodes to set Webthing device cabability

[klausahrenberg]

Hi, I just thought about to transfer my project to Homie spec to use only MQTT on the device and make it more compatibe to other IOT projects, like HA. For connection to Mozilla Webthings I wanted to use your plugin. However, I struggle at one elementary thing at the beginning. The Homie spec provides a $type for nodes. It seems that your library doesn't set the device type according to this, I can only add a 'custom thing'. Do you plan to set device types according to https://iot.mozilla.org/schemas/ in your plugin? The custom things are ugly and don't provide the functionality I need for a thermostat, I even can't select this device type manually.

[tim-hellhake]

However, I struggle at one elementary thing at the beginning

I'm sorry for the inconvenience.

It seems that your library doesn't set the device type according to this

The homie adapter is relatively new. That's why some features, such as the device type, are still missing. If you look in the code, you can see that I already try to set the correct @type in the properties depending on the unit. I would love to also set the correct @type for the devices.

The Homie spec provides a $type for nodes

The problem with the homie $type is that the specification does not define what values are to be expected. As a first step, I could check if the $type matches one of the WoT capabilities. What types would you expect to work beside them?

The next problem is that I need to identify the device properties which are expected by the capability. In the case of the Thermostat, this would be the TemperatureProperty and the TargetTemperatureProperty. Maybe I could guess it based on the id of the property, but I have no idea which values are to be expected.

I even can't select this device type manually

You can only select the capabilities that are set in the device. That's why I have to know exactly which of the capabilities apply to the device.

What do you use to implement your devices? The python library?

[klausahrenberg]

Hi, thanks for your detailed answer.

What do you use to implement your devices?

I'm programming devices on ESP base. I have some custom made, but mostly I reprogram so called Tuya devices with an ESP8266 inside. This is an example: https://github.com/klausahrenberg/WThermostatBeca For these projects I implemented an own Webthings-Adapter based on the webthing-arduino project. However, when it comes to battery driven devices, it makes no sense and create difficulties to run a web server on the ESP to serve the Webthing requests. Furthermore the device is marked as offline after a short time, if it does not react immediately on the http requests from the gateway (because it's sleeping to save battery). So my idea was to use MQTT also for describing the device (=Homie) and your library to have it still in the Mozilla gateway.

As a first step, I could check if the $type matches one of the WoT capabilities. What types would you expect to work beside them?

Yes, it's a problem - there are not defined types in Homie and the used one are not exactly the same like in WoT. If I take a look at the examples here: https://github.com/homieiot/homie-esp8266/tree/develop/examples The following Homie to WoT type conversion would be possible:

thermostat > Thermostat
door > DoorSensor
switch, button, shutters > OnOffSwitch, Light
temperature > TemperatureSensor

This is far away from ideal. Maybe it would be a better solution to implement a custom tag for WoT, for example $wot for node and properties. If this tag exists, your library could use this value without modification as type for the WoT device. The homie-esp8266 also added some custom tags, like $ip, $mac or $stats.

The next problem is that I need to identify the device properties which are expected by the capability [...] Maybe I could guess it based on the id of the property

This problem could also be solved by usage of a custom tag, like $wot. Then you have no unsure transformations in your add-on. How do you think about it?

[tim-hellhake]

However, when it comes to battery driven devices, it makes no sense and create difficulties to run a web server on the ESP to serve the Webthing requests

That's true. MQTT is a far better solution for this.

The homie-esp8266 also added some custom tags, like $ip, $mac or $stats.

They are actually part of the spec. Version 3.0.0 introduced them and version 4.0.0 moved them to an extension.

Maybe it would be a better solution to implement a custom tag for WoT, for example $wot for node and properties.

I'm not sure if adding non-spec properties would be a good idea. The proper way would be to either create a new extension or label the devices/properties using the meta extension. I'm not sure though how well extensions are implemented in homie-esp8266.

I wonder how HA solves this.

[mrsteakhouse]

Since the current capabilities are known for a WebThing device and the information is rather domain specific to a WebThings Gateway, the adapter might compile the possible device types and its needed properties into the adapter. Hardcoded or parsed from some source. A new device is then checked against its containing properties and any matching device type is added to the list of possible types. The user then has the opportunity to choose the information to display.

[mrsteakhouse]

Thinking about this, using the meta extension seems like the best approach. Homie and WoT try to achieve the same goal so a new extension embedding the WoT into Homie feels wrong.

Given the meta extension a temperature device with properly set type would look like this

homie/temp-device/$homie -> 4.0
homie/temp-device/$name -> Thermostat
# Extension declaration
homie/temp-device/$extensions -> eu.epnw.meta:1.1.0:[3.0.1;4.x]

# define meta keys for the main device
homie/temp-device/$meta/$mainkey-ids ->  wot
# set meta keys
homie/temp-device/$meta/wot/$key -> type
# can be a list
homie/temp-device/$meta/wot/$value -> TemperatureSensor,HumiditySensor,BarometricPressureSensor

# define node type
homie/temp-device/$nodes -> sensor
homie/temp-device/sensor/$name -> Sensor
homie/temp-device/sensor/$properties -> temp,hum,press

# temperature property
homie/temp-device/sensor/temp/$name -> Temperature
homie/temp-device/sensor/temp/$unit -> C
homie/temp-device/sensor/temp/$datatye -> float
homie/temp-device/sensor/temp/$meta/$mainkey-ids -> wot
homie/temp-device/sensor/temp/$meta/wot/$key -> type
# must be a single type
homie/temp-device/sensor/temp/$meta/wot/$value -> TemperatureProperty
...
homie/temp-device/sensor/press/$meta/wot/$value -> BarometricPressureProperty

[tim-hellhake]

@mrsteakhouse

Homie and WoT try to achieve the same goal so a new extension embedding the WoT into Homie feels wrong.

Fair point.

Thinking about this, using the meta extension seems like the best approach.

This also seems to me like the cleanest approach. The problem is homie-esp8266 is still on 3.0.1, and I didn't see a way to set custom attributes in the examples.

@klausahrenberg

You seem to have a lot of experience with the homie-esp8266 library. Do you know if it's possible to advertise something like this?

# define meta keys for the main device
homie/temp-device/$meta/$mainkey-ids ->  wot
homie/temp-device/$meta/wot/$key -> type
homie/temp-device/$meta/wot/$value -> TemperatureSensor,HumiditySensor,BarometricPressureSensor