Reflection on the MQTT API

[pierre-gilles]

@Boimb

Yep. We are in full agreement that this is the whole point of MQTT, being able to do push as well. Therefore, we need to define the ad hoc topics.

Of course! I hadn’t defined the outgoing routes simply due to lack of time. In v4, as you’ve seen, I take the time to properly define things and do it right. I prefer not to develop something rather than develop it quickly and poorly

@Boimb

However, I think we should allow, as is the case today, creating devices and adding features via the Gladys UI (this topic should not be the only way to add an MQTT device, but it should be a solution)

I agree, in my opinion it’s better to recommend that MQTT code developers ask the user to create the devices in the UI (as is the case for other services). Otherwise, as soon as it runs in the background, the user has no feedback if it succeeds or fails. And if it fails, apart from looking at the logs (which we don’t want in v4), there’s nothing they can do.

@Boimb

Will the device pass anything other than an update of the state of the concerned feature through this topic?

For this topic, no, but for other topics yes. And since we want to keep the same naming conventions everywhere to stay consistent, if we put it elsewhere, we need to put it here too.

I suggest using the exact attributes to stay consistent.

The

gladys/master/device/custom:12/feature/custom:12:temperature:1/last_value

Looked good to me!

@Boimb

Thus, we do not multiply the « public » routes of the API, and yet, we are able to manage « non-compliant » devices.

Yes! Call it forwarding if you want, but in the end it will just be the implementation of a few « custom » routes that will indeed call the same methods in Gladys

So what’s the next step for this? @Boimb can you make a proposal for documentation that summarizes what we’ve discussed? (Or wherever you want: Here, in a GitHub issue, as you see fit)