Reflection on the MQTT API

[Boimb]

Salut @pierre-gilles @Terdious, cool, feedback
I’ll try to share my thoughts on the points raised.

@pierre-gilles

The topics presented in the documentation are only incoming topics! We do not manage outgoing flows in MQTT for the moment

Yep. We agree that this is all the interest of MQTT, to be able to do push as well. We therefore need to define the ad-hoc topics.

@pierre-gilles

There is a logic in the current API.

Yes, yes, of course! I imagine that this thread is there to validate/improve it.

@pierre-gilles

You have reversed it with the device I think. Gladys listens to what is intended for it, i.e. « gladys/master »

My bad. Of course, the idea would be that Glady listens to everything that concerns it
gladys/master/device/# or even just gladys/master/# but I don’t see a use case (maybe for the pods later)

@pierre-gilles

Then there are topics where we will have to keep the JSON encoded, I am thinking of device.create for example:

Indeed, this seems mandatory for that. However, I think we should allow, as is the case today, to create devices and add features via the Gladys UI (this topic should not be the only way to add an MQTT device, but it must be a solution)

@pierre-gilles

In your proposal gladys/master/device/custom:12/feature/custom:12:temperature:1 for example, there is no mention in the topic of what we are creating/updating.

Yes, and this is intentional. Will the device pass anything other than an update of the state of the feature concerned through this topic? That said, it’s not blocking to add the state mention, so why not.

@Terdious

Arduino (device) → Gladys = update of sensors:
Topic = gladys/master/device/state/update/Arduino01_garage/Garage Electricity
Payload = {« Average Voltage »:231, « Total Current »:11.6, « Power »:2691.2}

I’m not a big fan of the topic nomenclature but I share PG’s opinion:

@pierre-gilles

Very interesting remark One does not prevent the other, we could have a topic per device that would allow to update several features (in addition to the other topic per feature)

Based on these first exchanges, and from what I’ve read about the different types of protocol applications from different manufacturers, we probably won’t be able to define an API compatible with all manufacturers or open-source firmware providers (Tasmota, ESPEasy).

A solution we could explore would be forwarding, i.e. the possibility for the Gladys MQTT client to forward messages to topics it also listens to. Let me explain:

We define a single and unique Gladys MQTT API based on our first reflections (which we refine and validate). For example, to update a feature:

payload: stateValue

// Or even
topic: gladys/master/device/external_id
payload: { features: [
  {
    "external_id": feature_external_id,
    "state": stateValue
  }
]

This allows us to have a clear and precise API, without ambiguity, and which does not require rocket science to implement.

For cases where we don’t have control, like the MQTT service of unflashed Shelly devices. here the doc The integration takes the form of forwarding « proprietary » topics. For example:

payload: "off"
// Forwarded to
gladys/master/device/shelly:deviceid/feature/deviceid:onOff:1
payload: 0

Thus, we do not multiply the « public » routes of the API, and yet, we are able to manage « non-compliant » devices. Not to mention that the integration is nothing more than the addition of a forward. We can even imagine that the MQTT module, faced with a message on a proprietary topic, is able to create the associated device if it does not exist in the DB before forwarding it.