MQTT Import topic subscribe fields too short
Moderators: grovkillen, Stuntteam, TD-er
MQTT Import topic subscribe fields too short
Hello to all!
I am using a mqtt broker maqiatto.com, which has a required topic prefix - username, which is an email address of user.
The topic import field in MQTT Import plugin has a limit of 40 characters, which is very small.
Is it possible to somehow increase this limit, or set a common prefix for all topics separately?
Thank you very much!
I am using a mqtt broker maqiatto.com, which has a required topic prefix - username, which is an email address of user.
The topic import field in MQTT Import plugin has a limit of 40 characters, which is very small.
Is it possible to somehow increase this limit, or set a common prefix for all topics separately?
Thank you very much!
Re: MQTT Import topic subscribe fields too short
Not without changing the code of this plugin.
But maybe you can for example set something in a system variable, like you're doing in the %sysname%?
See the sysvars page for inspiration.
But maybe you can for example set something in a system variable, like you're doing in the %sysname%?
See the sysvars page for inspiration.
Re: MQTT Import topic subscribe fields too short
I'm still working on a couple of enhancements for this plugin, including a re-worked settings structure. I can add a generic prefix for all topics, as changing all input lengths seems less useful, and harder to upgrade existing settings.
It still needs thorough testing, as I'm fixing some memory allocation issues, but thats progressing nicely now. The PR is already taking quite some time, but that should not block you from testing, once I complete testing myself. Will report here when that test-build is available.
It still needs thorough testing, as I'm fixing some memory allocation issues, but thats progressing nicely now. The PR is already taking quite some time, but that should not block you from testing, once I complete testing myself. Will report here when that test-build is available.
/Ton (PayPal.me)
Re: MQTT Import topic subscribe fields too short
+1 That seems like a simple solution.But maybe you can for example set something in a system variable, like you're doing in the %sysname%?
Or, how about using the Home Assistant (openHAB) MQTT controller instead of the MQTT Import plugin? It is a generic MQTT controller and its subscribe strings are much longer (128 chars).
- Thomas
Re: MQTT Import topic subscribe fields too short
I'm using the Home Assistant (openHAB) MQTT controller to receive MQTT commands. I use it to execute ESPEasy event rules.Isn't a MQTT Import plugin the only way to transfer data from mqtt broker to ESP board?
EDIT: I just tried setting a system var in case that is what you need to do. Works great.
Here is an example of a publish statement:
Code: Select all
publish: TOPIC_TEMPLATE/cmd
message: let,1,99
- Thomas
Re: MQTT Import topic subscribe fields too short
One other thing...
It looks like the hostname you're using is not on your local network.
Thus better increase the timeout from 100 msec to 500 or more.
It looks like the hostname you're using is not on your local network.
Thus better increase the timeout from 100 msec to 500 or more.
Re: MQTT Import topic subscribe fields too short
Hello everyone!
Was very surprised by the speed of response in this community as well as the warm welcome !
This method assumes special formatting of the values that need to be entered. It is not very convenient to control the board using a mobile MQTT Dashboard app. The MQTT import plugin works much more conveniently. Then there are 2 types of topics - for sending values and receiving confirmation (feedback).
Now I'm using MQTT import plugin, but with short, non-human-readable topic names. But that's okay. I was also lucky that the username (the email address) was not so long![Lach :)](./images/smilies/icon_e_smile.gif)
Thus, if it were possible to set the user prefix globally, it would be cool!
Thank you all very much for the answers, and for such a powerful firmware for esp!
Roman.
Was very surprised by the speed of response in this community as well as the warm welcome !
100 ms is send interval, not client timeout.
Wow, its works, thanks. Also tested this method, and it also works! But...
This method assumes special formatting of the values that need to be entered. It is not very convenient to control the board using a mobile MQTT Dashboard app. The MQTT import plugin works much more conveniently. Then there are 2 types of topics - for sending values and receiving confirmation (feedback).
Now I'm using MQTT import plugin, but with short, non-human-readable topic names. But that's okay. I was also lucky that the username (the email address) was not so long
![Lach :)](./images/smilies/icon_e_smile.gif)
I will be happy to take part in testing.
I needed to switch from one broker to another and had to rewrite the prefixes in the plugin, controller settings, and also in the rules.
Thus, if it were possible to set the user prefix globally, it would be cool!
Thank you all very much for the answers, and for such a powerful firmware for esp!
Roman.
Re: MQTT Import topic subscribe fields too short
A theoretical solution would be to add string type vars to ESPEasy. Besides general purpose use, they could be used as string substitutes in the application you mentioned.Thus, if it were possible to set the user prefix globally, it would be cool!
For example, initialize the string var at boot in the rules, like this:
Code: Select all
on System#Boot do
let,str1,"yourname@gmail.com/" + %sysname% + "/"
endof
Just thinking out loud here. Maybe @TD-er or @Ath have better ideas. Or maybe this functionality already exists?
- Thomas
Re: MQTT Import topic subscribe fields too short
Nope, does not (yet) exist... But I think the %strN% syntax analog to %vN% would be a good idea.
The string variant for "let" would then be like "letstr".
The string variant for "let" would then be like "letstr".
Re: MQTT Import topic subscribe fields too short
Hi Roman,
Reporting back after applying improvements to the code in my PR. Can you fetch your build from the Github Actions, or do you want me to provide a build for you? If the latter, then please specify what build you are currently using (bin filename please, didn't find clues in this thread) or the ESP type (ESP32/ESP8266), size of flash and a list of plugins you actually use, so I can create a Custom build for you.
Edit: The Github Actions build failed because of .bin size issues (as it does often), so the second option is the best for now
![Knipoog ;)](./images/smilies/icon_e_wink.gif)
/Ton (PayPal.me)
Re: MQTT Import topic subscribe fields too short
This is the 'normal' build from my development branch:
)
And a preview of the documentation: (not yet including the Topic prefix field, that my next task ![Lach :)](./images/smilies/icon_e_smile.gif)
/Ton (PayPal.me)
Re: MQTT Import topic subscribe fields too short
Already flashed and tested. It is working! Now I am thinking about applying the new features of the plugin (filter). Now filtering (or rather normalization of incoming values) is done using rules. But by using the new features, I maybe can save a little space in the rules.
Many thanks for the provided build and new plugin features!
Roman.
Re: MQTT Import topic subscribe fields too short
Major advantage of filtering is that the topic is 'dropped' if it doesn't pass the filter, and the rules aren't parsed at all then. Even that is a big speed/load improvement.
You're welcome
![Cool 8-)](./images/smilies/icon_cool.gif)
/Ton (PayPal.me)
Re: MQTT Import topic subscribe fields too short
@Ath, The new features are well thought out. Fantastic documentation!
- Thomas
- Thomas
- dynamicdave
- Normal user
- Posts: 257
- Joined: 30 Jan 2017, 20:25
- Location: Hampshire, UK
Re: MQTT Import topic subscribe fields too short
Has anything happened regarding this excellent suggestion?ThomasB wrote: ↑18 Oct 2021, 20:27A theoretical solution would be to add string type vars to ESPEasy. Besides general purpose use, they could be used as string substitutes in the application you mentioned.Thus, if it were possible to set the user prefix globally, it would be cool!
For example, initialize the string var at boot in the rules, like this:Now any place %str1% is used it would expand to yourname@gmail.com/ESP_Easy/Code: Select all
on System#Boot do let,str1,"yourname@gmail.com/" + %sysname% + "/" endof
Just thinking out loud here. Maybe @TD-er or @Ath have better ideas. Or maybe this functionality already exists?
- Thomas
Also on a related topic/question... has there been any development with sending a string via MQTT event and collecting it with %eventstring%
The reason I ask is... it would great if a string variable could be used in a 'publish' command.
e.g. replace "garage" with %str1%
Code: Select all
On publishReading Do
publish homie/reading,'{"node_number":[my#nodeID],"location":"garage","ssid":"%ssid%","update_interval":[timer#value]}'
EndOn
Re: MQTT Import topic subscribe fields too short
I have a longstanding open PR #3424 that adds a 'Prefix for all topics' feature (see this screenshot from the PR)
There is no %eventstring% support yet, other things have gotten priority, and the desire to add string handling as a generic feature isn't speeding things up either.
For replacing 'garage' with a variable, it would depend on the number of options, but the {substring:<startpos>:<endpos>:<string>} function could help here (documentation)
There is no %eventstring% support yet, other things have gotten priority, and the desire to add string handling as a generic feature isn't speeding things up either.
For replacing 'garage' with a variable, it would depend on the number of options, but the {substring:<startpos>:<endpos>:<string>} function could help here (documentation)
/Ton (PayPal.me)
- dynamicdave
- Normal user
- Posts: 257
- Joined: 30 Jan 2017, 20:25
- Location: Hampshire, UK
Re: MQTT Import topic subscribe fields too short
Thanks for your swift response.
It's not an issue as I can handle it the way I'm doing it now.
Much better for the 'Team' to concentrate on higher priority features/issues.
It's not an issue as I can handle it the way I'm doing it now.
Much better for the 'Team' to concentrate on higher priority features/issues.
Re: MQTT Import topic subscribe fields too short
Adding labels to variables isn't that hard to do, but it may take up more memory and resources in parsing.
Right now variables are stored as a std::map<int,double>
But this can be changed to std::map<String,double>
It also needs some adaptations to the parser, but that's about it.
Then you could use %v_garagetimer% for example as a variable holding a double value.
Storing strings is a different matter.
Not only will it easily blow up in used memory resources, as those variables may tend to live quite long.
But it also needs quite a lot of work to extend the "let" command (or add a "letstr") and where it can be used.
Maybe that last part isn't as hard as I am afraid it will be as things will be replaced by their string equivalent before parsing anyway, but I think I might be missing some corner cases then.
However, the more I think about it, the more powerful it appears to be to have string operations as you could even make dynamic program flows.
For example you can even place a string variable on a rules line and expect it to be executed if it contains rules code.
But that's also the dangerous part. What if you get some string value as an event value via MQTT or HTTP and it contains a call to perform a factory reset?
Right now variables are stored as a std::map<int,double>
But this can be changed to std::map<String,double>
It also needs some adaptations to the parser, but that's about it.
Then you could use %v_garagetimer% for example as a variable holding a double value.
Storing strings is a different matter.
Not only will it easily blow up in used memory resources, as those variables may tend to live quite long.
But it also needs quite a lot of work to extend the "let" command (or add a "letstr") and where it can be used.
Maybe that last part isn't as hard as I am afraid it will be as things will be replaced by their string equivalent before parsing anyway, but I think I might be missing some corner cases then.
However, the more I think about it, the more powerful it appears to be to have string operations as you could even make dynamic program flows.
For example you can even place a string variable on a rules line and expect it to be executed if it contains rules code.
But that's also the dangerous part. What if you get some string value as an event value via MQTT or HTTP and it contains a call to perform a factory reset?
Who is online
Users browsing this forum: Bing [Bot], Google [Bot] and 30 guests