Ezlo MQTT plugin as trigger?

[ibrewster]

It appears according to the documentation that, using the MQTT plugin, I can set the device created by said plugin as a trigger in a meshbot. I would think this would enable me to trigger the meshbot by publishing a specific message (correct me if I am wrong).

To test this out, I set up a meshbot as per the following screen shot:

Then published a message to the ezlo/notify topic (picked arbitrarily) with the content ‘Run’. However, as far as I can tell nothing happened, though another client subscribed to the ezlo/notify topic did receive the message, so I know it went through.

So, can anyone tell me how to properly use the MQTT plugin as a trigger? Thanks.

EDIT: I tested the setup by adding a MQTT action to this meshbot that published a message, then running the scene manually. The meshbot did, in fact, publish the message correctly (it showed up on another client I had subscribed), so I’m fairly confidant that the plugin is set up correctly and communicating with the broker. So it should just be a matter of setting up the trigger correctly and sending the correct message to the correct topic…I would think?

[jouked]

Very interested in this as well, as I’m trying to control my a/c units through MQTT. I was surprised to find only ‘MQTT message’ on the trigger section, as it really should specify the topic on which the message was received as well.

Furthermore, it would be very helpful if the contant of the received message (the ‘value’) is usable on the action bit as well.

[osman]

Actually if you just set a “message” as a trigger it should listen all topics and if you specify a topic, it should listen to that topic for any message.

Let us check it again. It should have been working already.

[jouked]

Looking at the Lua code of the MQTT plugin, it’s not just ‘all topics’ where the triggers can occur. The MQTT plugin explicitly subscribes to the following topics:

	_mqtt_client.subscribe({
		topics = 'ezlo_mqtt/set/item/#',
		packet_id = 1,
		qos = 0,
	})

The # is a wildcard in MQTT, so any message send on any topic starting with ezlo_mqtt/set/item/ should trigger the meshbot.

[jouked]

And then there’s this bit of code which handels incoming data on topics:

	local topic = string.sub(packet.topic, #'ezlo_mqtt/set/item/#', #packet.topic)

Which basically seems to strip the ‘ezlo_mqtt/set/item/#’ bit from the topic name. So if you receive data, the topic name might be truncated, though I don’t see how you can use the topic name in the rest of the meshbot (it would come in handy though!)

[ibrewster]

@jouked

The MQTT plugin explicitly subscribes to the following topics:

Good catch! That was it exactly! Publishing a message ‘Run’ to the topic ‘ezlo_mqtt/set/item/test’ successfully triggered my meshbot. SUCCESS!

Perhaps this should be something that is exposed in the configuration of the plugin? Not a big deal for me now that I know what topic to publish to, but it could be useful.

@jouked

Furthermore, it would be very helpful if the contant of the received message (the ‘value’) is usable on the action bit as well.

Perhaps this is something that variables can be used for? I haven’t played around with those yet, so I’m not sure how they work.

[jouked]

I was thinking of somehow using local variables for that purpose as well, however the documentation and/or examples are really lacking in this area.

On my side I’m trying to control a a/c through MQTT. Not directly with several meshbots, but I want to control the a/c through a virtual device. I’ve created the virtual thermostat (that was easy) and want to tie this to mqtt. For some bits it’s straightforward, for example using the thermostat mode as a trigger and directly publishing the right command to mqtt, e.g.:

For other bits, e.g. the temperature setpoint, I’m at a loss:

The other way around is also a mystery to me, e.g. reading a temperature from a MQTT topic and using the received value as a target for a local (virtual) device.

@melih : Development seems to follow Agile principles. Maybe the below features can be put on the backlog?

• “As a user, I want to be able to trigger a meshbot on the change of a value instead of a comparator.”
• "As a user, I want to be able to use a value from the trigger as a variable in an action, in this case, I want to use a value read from a MQTT topic from the MQTT plugin as a setpoint for a virtual thermostat device’’
• “As a user, I want to to be able to use a changed setpoint on a virtual thermostat as a variable in the action bit of a meshbot to publish a message to a MQTT from the MQTT plugin.”

[osman]

Hi @jouked , @ibrewster

As you figured out the topic was set as “ezlo_mqtt/set/item/”
The reason for that was to avoid overloading. Subscribing to ‘#’ (anything) without specifying a topic is actually bad form, as it will capture every message in every topic. In a busy broker, this will overload the client (and it might even overload the broker). Though it can be a shorter and more generic one like “/ezlo_mqtt/meshbot” only.

So here are the improvement points on the topic gathered together:

1- Allow to specify topic and message on the triggers
2- trigger a meshbot on the change of a value instead of a comparator
3- Use values of the devices in the actions as parameters. (to set another item value , to send notification about it, use it in HTTP Requests, in local variables etc… (This should cover your both cases, its a more generic approach)

I will be creating “Community Bug and Feature Request” tickets on behalf of you

[ibrewster]

Super, thanks! A couple of comments:

@osman

Subscribing to ‘#’ (anything) without specifying a topic is actually bad form, as it will capture every message in every topic

100% absolutely agreed. My thought would be that (in an ideal world) when you set up the MQTT plugin, the user can specify a topic to subscribe to. Default to ezlo_mqtt/meshbot (or whatever - the current value is fine too), and disallow entry of just ‘#’

@osman

1- Allow to specify topic and message on the triggers

Can’t you already do that though? Granted, if you want both you have to put in two lines with an and, so perhaps the idea here is just to simplify it a bit? Or does the topic trigger not work due to the filtering/stripping of the topic name that @jouked identified in the code?

@osman

3- Use values of the devices in the actions as parameters

I second this, with the addendum (perhaps already understood) that this would seem to be a generic meshbot improvement, not something specific to this plugin.

Thanks for looking into this!