Feedback on Gladys

Configuration
1

Hello,

I am currently using as a « home automation system » a set of services (zigbee2mqtt, deconz, node-red) + home-assistant (but actually using it quite little).
To get a feel for what Gladys is I deployed a test instance in a container: installation process went smoothly, the interface is clean and responsive.
The user interface is modern and stands out compared to many other often austere home automation solutions.

One limitation I find quite detrimental in Gladys is the MQTT integration. Not being able to specify a specific topic (even in addition to the one defined automatically) directly at the device level is unfortunate. Although it is possible to handle the reception of a message via a scene I find that this makes the logic « messy » to maintain a device-centric approach.
In my opinion the ability to:

  1. be able to specify a topic at the device level,
  2. define whether the content is JSON or plain text,
  3. in the features specify the sub-topic of the value or the key in the JSON received from the device topic

would satisfy a large number of scenarios that currently require node-red.

Furthermore, this would make Shelly, teleinfo, and EnOcean devices relatively easy to integrate into Gladys.

my two cents

Have a nice day

3 Likes
2

Hi @Alyafride! :slight_smile:

Welcome to Gladys, and thank you very much for your feedback! :folded_hands:

I get this feedback about Gladys very often, but I can’t figure out how that could work.

MQTT is a communication protocol (just like HTTP), but this protocol doesn’t define any message format (everyone puts whatever they want), and it’s not especially tied to home automation.

In Gladys we defined our topic and message format. Each brand using MQTT also uses its own format (and that’s normal, it’s like HTTP APIs, it isn’t meant to be standardized).

So, let’s say we offered users the ability to add a custom topic to each MQTT device.

As you say, the user would also need to be able to define the payload formats (input and output), and then the user would need to define the format of the values, as well as conversion functions.

Example: in Gladys, a lamp “On” has the value 1, in Shelly it’s “true”.

For colors, in Gladys it’s an integer format, some manufacturers use hex, others RGB, etc…

In short, everything I just described is actually code :joy:

To take Shelly as an example, if you’re going to make the mapping table between Shelly and Gladys anyway, why force every user to do it one by one per device, when it could be done once in Gladys’ code and then it works for everyone? That’s what we did in the Zigbee case, for example.

Or maybe I didn’t understand something?

Thanks for your feedback in any case!

But since I relatively often get this feedback from users coming from HA, there must be something I don’t understand, so I’m open to your insight :blush:

3

So at first I only have in mind the data retrieval and display part, in order to be able to show certain states (how much I consume, equipment turned on, etc.); for issuing commands it’s indeed a whole different ball game to handle the different types of data. But personally I quite like publishing sensor data (air quality, energy, etc.) via MQTT. For issuing commands most of the time it’s Node-RED or Home Assistant.

Typically in the case of Shelly: Someone who would like to test Gladys and have a clean dashboard — although it can be a bit tedious — would currently define features as an MQTT device but specify the subscription topic, thus having their metrics come up directly.

To illustrate my case with a CO2 sensor that publishes info via MQTT, I had to create a Node-RED flow that only subscribes to the sensor’s topic, change that topic to the one expected by Gladys, and re-publish the message; it’s a bit of a shame.

4

Example for a Shelly EM, someone could simply configure the MQTT broker on the device — it will push a message of this type (note: gen1 only; gen2 messages are in JSON format):

image
image203×377 4.47 KB

Create an MQTT device in Gladys and create a feature for the metric(s) you’re interested in.

5

Ok I understand, then it’s an easy case if it’s just numeric values (but that may be the case in most cases)

In your screenshot, « power », « reactive_power », are those JSON attributes?

6

No, in bold is the topic tree and in plain text the value:
shellies/shellyem-XXXXXXX/emeter/0/total_returned 855.2

For Shelly generation 2 and 3, however, the messages are in JSON format; I can provide an example if needed.

I’m convinced that this fairly simple case is one of the most common: while MQTT isn’t easy to handle for issuing commands because there’s no state-feedback management, for IoT and the reporting of sensor values I find it very relevant.

7

Ok, in that case I’d like you to create a feature request on the forum to keep a record of the request :slight_smile:

Maybe check beforehand if there isn’t already a similar request

And if you’re a bit of a dev, Gladys is open-source and any pull request is welcome :hugs:

8

Ok, I’ll find/write a feature request.

For development, I’m more comfortable with Python and I’m already working on quite a few projects at the moment.

2 Likes
9

hello @Alyafride

your request is a bit like this request if I’m not mistaken and if I understood you correctly :wink:.

10

Indeed, I had come across that one, except that the idea at first was simply to define the topic without any intention of trying to transform the data. More or less keep the same processing logic but simply provide the ability to specify the topic in order to be able to target the topics imposed by manufacturers.

A relevant solution in my view would be to be able to define the topic « parent » at the device level and specify whether the message content is JSON or flat values (in subtopics). Then for each « feature » of the device define the key of the value, namely the subtopic if the data is flat and the dictionary key if JSON.

11

@cce66 since it’s the same request, I closed your request to keep the other one which is clearer / has more votes :slight_smile:

1 Like