[Feature request] Trigger Tasker event on wildcard topic subscriptions about mqttclpro HOT 16 CLOSED

Hey

Yeah, I actually didn't get time to work on this. However this should be straightforward, I will try and push this change in the next version.

from mqttclpro.

Done! Will be available in the next version.

Cheers!

from mqttclpro.

Hey...I believe returning the MQTT topic in a tasker variable is the right way ahead in this issue.

We can introduce another non mandatory text field configuration for MQTT topic tasker variable.

from mqttclpro.

This also confused me for a while. Then I found /topic/# does not work, but /topic/subtopic/ does.

from mqttclpro.

@brianmay the request is to get all subtopics. Using what you found will only show you all the messages posted to that specific subtopic.

Wildcard support would be very useful.

from mqttclpro.

Very nice, thanks. Looking forward to it! I hope both + and # topic events become available :)

from mqttclpro.

If I subscribe to foo/+ and publish to foo/bar how should I know the actual value which comes for + (bar in the case) inside tasker?

from mqttclpro.

@dc297 Thanks!!!

@dvv A wildcard subscription is useful when it is not important which specific topic a message came from. If that is important to you, you either have to 1) subscribe to a specific topic instead of a wildcard topic, or 2) create a better topic structure, eliminating the importance :)
Feel free to add your specific case(s), if you want to elaborate further on this.

from mqttclpro.

An evident test case is to subscribe to sms/+ to have the wildcard topic portion in variable %phone and payload in %text.
I believe I see you suggest to parse topic manually in the task but what variable carries the topic per se?

from mqttclpro.

Not sure if I understand your case completely. Can you list the seperate topics, which you want to catch with one wildcard subscription? In other words, what part does the + replace exactly?

from mqttclpro.

The target phone number.
So that publish to sms/+7....... result in variable %phone be assigned +7........

from mqttclpro.

This issue resolves subscribing to wildcard topics, these (usually) contain MQTT messages your phone receives from external sources. A SMS is received on the phone itself, Tasker already has access to these vars without MQTT.

If you want to publish these SMS vars with MQTT messages, it has no relation with subscriptions on your phone, or this issue.

If you want to receive MQTT data from SMS's received on other devices (say: phone2, phone3) on your own phone (phone1), I would use specific topics for the publishing phones and types of data (phonenumber, data, datetime etc.):
phone2/messages/sms/received/phonenumber
phone2/messages/sms/received/data
phone2/messages/sms/received/datetime
phone3/messages/sms/received/phonenumber
phone3/messages/sms/received/data
phone3/messages/sms/received/datetime

To receive all SMS received datetimes via MQTT, or see the latest SMS datetime if these messages are retained, regardless of the phone who sent the MQTT message, you can subscribe to:
+/messages/sms/received/datetime

If you want all datetimes of all received message types, not only SMS, subscribe to:
+/messages/+/received/datetime

All incoming and outgoing SMS numbers on all phones:
+/messages/sms/+/phonenumber

All incoming message data on all phones:
+/messages/+/received/data

All SMS stuff on phone3:
phone3/+/sms/+/+
phone3/+/sms/#

And so on. Hope this makes (enough) sense.

from mqttclpro.

Well. I didn't succeed explaining the issue.
I would like an android to send SMS to the some target phone. For this I run tasker. The tasker profile is to wait for MQTT message sms/+ and the tasker task is to send SMS. I expect the target number as second part of received MQTT topic and text as MQTT payload.
In this case I do not see how the tasker task is given MQTT topic. If the topic were not containing wildcard I would know it as it would be constant.
In effect I would like this plugin to not only set custom variable for incoming payload but also to set some predefined variable, say %topic, for incoming topic.

from mqttclpro.

@dc297 I also think it is a nice feature to have. In a freedom of choice kind of way, giving Tasker more options to work with. Having options is good :)

@dvv Now I finally understand your case. You want to use data (phone numbers) as structure (topic names). I would prefer using messages for data as much as possible. Just in case your client has no access to the topic name as a variable ;-)

In line with the examples above, if phone1 is the phone you want to send the SMS from, something like:
phone1/commands/messages/sms/send/phonenumber
phone1/commands/messages/sms/send/data
phone1/commands/messages/sms/send/datetime
Datetime could be used for sending SMS in the future. If you want to know which phone sent the instruction, a topic layer with the publishing client might be useful. Extra functionality can be added by adding a topic name. Functionality scales better within the topic layers, without needing smarter clients.

I understand using phone numbers as topic names does provide extra functionality. Building an archive of SMS messages for instance. Imho, there are better solutions outside MQTT for that, like databases or text files.
In theory, you could put all (text type) data in topic names. But most MQTT clients are just dumb, and there are reasons for that. A good topic structure requires less logic in the clients. And also decreases the maintenance on the broker (it would fill up quicker on heavy use, requiring a cleanup strategy, etc.). Privacy concerns extend from the messages into the topic names as well. Both approaches have their up- and downsides I guess.

from mqttclpro.

I tend to believe the topic is mandatory and payload is purely optional. Just like they might want to send a blank postcard with filled address just to notify of something predefined offline )
And yes, having incoming topic in a variable would solve the issue.

from mqttclpro.

@dc297 I noticed you released the new version v2.3.1, thanks for that! First tests look promising, Tasker events are triggering OK.

@dvv Sending null messages (blank postcards) can be done on both approaches, I use them a lot. It still is a message, regardless if there is a payload or not. You can have predefined "offline" logic on empty and filled messages, it isn't related to the choice of topic names. But ymmv.

from mqttclpro.