New trigger: arrival of an MQTT message

[Archive] Feature request
1

Feature description
Following our discussion here

A scene must be able to be triggered when an MQTT message arrives on a particular topic.

2

And that would be useful in other cases, I think!

I need to

1 Like
3

I made a small suggestion on this PR :

I didn’t add a new trigger. I just added the ability to launch any scene from an MQTT message.

To do this you need to publish a « START Â» message to the channel: « gladys/scene/[sceneSelector] Â»

What do you think?

4 Likes
4

@Lokkye just one word: Awesome! :blush:

For that you need to publish a « START Â» message in the channel: « gladys/scene/[sceneSelector] Â»

You’ll need to explain because I don’t see the « how Â»?

Otherwise it’s great for opening scenes from outside via MQTT or Node-RED!
Well done on these developments!!! :+1: :clap:

5

Super cool @Lokkye!

For the topic format, we need to keep the format we currently have on the other MQTT topics, notably the « master Â» prefix which indicates we’re addressing the « master Â» instance. It’s not the case yet in Gladys, but the idea of this « master Â» was to have, in the future, detached « pod Â» instances that can run remote services.

So I’d suggest something like:

gladys/master/scene/[sceneSelector]/start

No specific body.

What do you think?

PS: I also did a small technical review: Run scene when receive message on MQTT by callemand · Pull Request #1911 · GladysAssistant/Gladys · GitHub

2 Likes
6

@pierre-gilles : I didn’t know about the existence of the topic â€č gladys/master/
 â€ș.
I just modified my code accordingly. It’s much simpler :slight_smile:

Thanks for the technical review :slight_smile:

1 Like
7

Indeed it’s much simpler :smiley: Great PR, I tested it and it works for me!

It’s merged and will be available in the next version of Gladys.

However I’m not sure we should close this feature request because it’s not exactly what was asked (this was talking about a custom topic here)

1 Like
8

Thanks @pierre-gilles for the merge :slight_smile:

[quote=« pierre-gilles, post:7, topic:8127 Â»]
However, I’m not sure

1 Like
9

@pierre-gilles :
Here is the PR that implements the feature:

Tell me what you think :slight_smile:

2 Likes
10

@Lokkye I left you a review! Add scene trigger : MQTT message by callemand · Pull Request #1913 · GladysAssistant/Gladys · GitHub

I’d like to better understand the logic behind this development to understand the implementation choices :slight_smile: If you prefer to explain here in French rather than on GitHub in English, whichever you prefer!

11

@pierre-gilles : Thank you for the review.

So regarding the fact that I don’t use the word « MQTT Â», I wanted to completely disconnect from the service. I do a lot of Clean Architecture in my work and therefore I like to separate concepts. I also wanted to avoid adding technical terms into Gladys. But it’s true that by doing that I’m not necessarily any clearer.
Are we going to add other message queues in the near or not-too-distant future?

12

I understand the idea — however, from a user perspective, making things « ultra-generic Â» can just be confusing in practice, and it’s often better to be « ultra-specific Â», which allows using the right vocabulary.

UX level

In this case, a user who wants to connect an external MQTT script will inevitably look for the word « MQTT Â» as a trigger. Sure it’s technical, but anyone who wants that is technical.

If MQTT isn’t mentioned anywhere, it’s impossible to know what that means :slight_smile:

Even if in the future we have other queue technologies, we can create other triggers specific to those technologies.

If we take the example of Zapier (https://zapier.com/), when you select a trigger, they offer all the possible technologies directly so it’s clear:

Screenshot 2023-10-27 at 13.45.47
Screenshot 2023-10-27 at 13.45.471862×1252 283 KB

I think we can mention MQTT in this case and talk about MQTT throughout the code without problems :slight_smile:

Implementation level

I’m not sure the implementation makes sense for this specific case, notably the use of eventEmitters to cancel triggers and set triggers, because we don’t have a guarantee that the code will execute before moving on.

In the current implementation, nothing tells me that the listener:

this.gladys.event.on(EVENTS.MESSAGE_QUEUE.UNSUBSCRIBE, this.handleGladysEventUnsubscribe.bind(this));

Will actually be executed before:

this.gladys.event.on(EVENTS.MESSAGE_QUEUE.SUBSCRIBE, this.handleGladysEventSubscribe.bind(this));

So potentially, if I edit my scene, my listener is added a second time then removed and so we’re in a « messed-up Â» state.

Not sure we have a choice; I think we need to call this.service.mqtt in the scene. Besides, generally when we go from Gladys to the services, that’s what we do in the rest of the code (for example in the Telegram integration that’s what we do).

What do you think?

13

Ok, I understand better.

Yes, after thinking about it you’re completely right :slight_smile:

I didn’t think the « core Â» could be directly linked with the services. So we also need to handle the fact that the service isn’t enabled :slight_smile:

I’ll take care of that :slight_smile:

1 Like
14

[quote=« Lokkye, post:13, topic:8127 Â»]
I

15

@pierre-gilles : I have made the changes based on your feedback.

2 Likes
16

Great! I’ll check that out today :slight_smile:

17

Super cool @Lokkye, it works perfectly for me like this :ok_hand:

I’ve left you a few comments but nothing major :slight_smile:

1 Like
18

@pierre-gilles : I’ve just made the changes based on your feedback.
Feel free to tell me if I missed anything. :slight_smile:

1 Like
19

Thanks for the fixes, it’s fine with me and it will be included in the next Gladys release! :folded_hands:

3 Likes
20

This feature is available in Gladys Assistant 4.31! :rocket:

I’m closing this thread to free up the votes, feel free to create another thread if you encounter bugs with this feature :slight_smile:

3 Likes