To put it simply, my sensor sends with a topic (ex: « dsmr/reading/phase_currently_delivered_l3 ») and Gladys only allows me to listen on an automatically generated and non-editable topic (ex: « gladys/master/device/mqtt:consommation_instantanee/feature/mqtt:consommation_instantanee/state »).
In short, to do something ‹ simple ›, I have to go through Node-RED to transfer the information from one topic to another.
Would it therefore be possible to create a mapper to fill this gap? Or to make the topic created by Gladys editable?
Thank you for the request, I edited the title to make it clearer.
For me 2 possibilities with their pros and cons:
Do this via scenes, via a trigger « When an MQTT message is received », which takes as parameters an MQTT topic, and an example of a received message. Then, in the scene, a variable is injected that is usable everywhere (send a Telegram message, set the state of a sensor, etc..). The advantage is that it’s infinitely customizable; the disadvantage is that you have to make one scene per sensor, which can be cumbersome.
Do this in the MQTT integration directly, via a « custom » topic that will be customizable. The advantage is that it’s simple to use; the disadvantage is that it’s not customizable at all (if the MQTT message has a specific format, how do we handle that?)
It is true, as I already pointed out, that this is a constraint when dealing with fixed or limited publish/subscribe on certain devices; the question remains whether the ability to assign a device’s behavior (switch, on/off bulb, etc.) to a customizable subscribe or publish is feasible in Gladys rather than the somewhat heavy current syntax (the « mqtt: » is unnecessary in the name of the subscribe or publish). It would be a plus, because currently it’s an illogical limitation given how MQTT works.
Great, I think this addition can help to easily integrate different sensors.
In terms of UI I would have imagined a switch at the device level to define whether the payload is of type JSON or « sub-topic » and optionally to set the parent topic. Then at the feature level define the JSON path or the sub-topic (not sure that combining both simultaneously is necessary)
There is still work to do, because currently the MQTT integration does not support multiple listeners on the same topic, which would prevent using the same topic across multiple features, which is inconvenient in the case of this feature
I’m not sure, that might make each feature longer (and it’s already long)
On one hand, since the MQTT topic for devices often contains a unique ID (the device’s serial number or its MAC address), it seemed simpler to define it only once at the device level, but that has a heavier impact on the interface.
On the other hand, it offers more flexibility to specify the full topic each time and has less impact on the interface. However, it implies a « JSON path » field which can be confusing if the metrics are emitted « flat ».
I just tested, it works for a device that posts with a topic/metric. However, for a device that posts different metrics within a JSON, only the first « feature » works; the second, configured on the same topic but with a different JSON path, does not retrieve any data. Ex of data:
Finally I hadn’t remembered this when defining the expected behavior, but it’s clear that filling in the external ID is quite tedious; it would be nice to have a generated default value if the field is left to MQTT:
I think there’s a UI bug when filling in these values during the creation of the MQTT device, however when editing it works perfectly… Thanks for the feedback, I’ll work on it and get back to you
However, I tested the case of having multiple metrics within the same JSON and it works well:
Yes, why not, personally I quite like NetBox’s logic for defining slugs. Basically, if the field isn’t filled in it sets it based on the name and makes it URL-safe.
