[Brainstorming] Homie MQTT specification implementation

[depau]

I'd like to start this early since the MQTT support is still at very early stages and it can still be changed fairly easily. I'd like to introduce the Homie specification for MQTT autodiscovery: https://homieiot.github.io/

I know the hass.io integration is being worked on, but I do not use hass (and I actually really dislike it).

I use OpenHab which technically does have support the hass protocol, but it is very limited since it maps very poorly to OpenHab's rich object-oriented home automation semantic model (JSON payloads and OpenHAB don't get along very well)

In this discussion I'd like to brainstorm ideas on how to implement it.

One idea could be to implement it in each CapabilityBasedAttributeMqttHandler, which should be easy for most caps that handle only one piece of information (i.e. fan speed).

However, for more complex data (such as the wi-fi configuration) that is currently published as a JSON object, each value has to be split into its own topic (see example in the website's homepage).

Another idea would be to have separate implementations for the hass-style and homie-style topic providers.

What do you guys think?

[depau]

I thought about it for a few minutes, here's my idea for a hybrid system, which shares code between the two implementations but that does require a refactor of the current MQTT codebase.

Filesystem structure for a few examples:

• DIR mqtt
  • MqttController.js
  • CapabilityMqttHandler.js
  • MqttPropertyHandler.js
  • DIR capabilityHandlers
    • DIR WiFiConfigurationCapability
      • WiFiConfigurationCapabilityMqttHandler.js (implements CapabilityMqttHandler)
      • DIR properties
        • state.js (implements MqttPropertyHandler)
        • ssid.js (implements MqttPropertyHandler)
        • ...
    • DIR FanSpeedControlCapability
      • FanSpeedControlCapability.js (implements CapabilityMqttHandler)
      • DIR properties
        • speed.js (implements MqttPropertyHandler)

MqttPropertyHandler

This class is implemented for each piece of information provided by each capability. It contains the Homie property attributes.

It also handles retrieving and setting the value in question from/into the capability.

CapabilityMqttHandler

This class is implemented for each capability. The implementation will return the home assistant component autodiscovery payload, as well as the Homie node attributes.

All MqttPropertyHandlers provided for each capability are instantiated and registered here.

Since Hass likes JSON, the CapabilityMqttHandler will collect all the data from the properties, put it in a single JSON and publish it; subscribe to the command MQTT topic and pass any changes to the properties.

Since Homie hates JSON, it won't do anything: each property will subscribe to its own value (on both valetudo and mqtt sides) and publish/set values accordingly.

MqttController

This class is a singleton. It will instantiate all the CapabilityMqttHandlers available for the current robot, provide the autodiscovery config for the main vacuum.mqtt hass component, as well as Homie device attributes.

---

Each base class will provide methods to automatically set up the boilerplate topics when possible (most of the homie attributes can be set once on start and then forgotten about, except for presets which may need a little special handling).

On the Hass side, MqttController and CapabilityMqttHandler will both provide Hass components, the former will provide "vacuum" and the latter may provide whatever best fits.

[Hypfer]

Okay so would this be both Hass and Homie at the same time or a toggle between them?

Also, what about the Map data? Would that live beside the vacuum.mqtt in the MqttController?

[depau]

Okay so would this be both Hass and Homie at the same time or a toggle between them?

That can be decided, but in the way I'm imagining it it is possible to enable both protocols, on two separate sets of topics. Or always enable the homie-style hierarchy and generate a hass autoconf that redirects it to the homie topics.

Then Hass can be turned off if requested by not generating the home_assistant/# topics, Homie can be turned off by not prepending homie/ to all non-hass topics and by not generating the $stuff topics.

Also, what about the Map data? Would that live beside the vacuum.mqtt in the MqttController?

Since Homie has a stricter hierarchy device > node > property maybe we can have a fake capability handler (with capabilities mapping 1:1 to homie nodes) that handles all the common status data such as map, accessories etc. in a special manner.