B4R Question rMQTT HostName with query parameters


Active Member
Licensed User
Longtime User
I was able to successfully develop a B4J desktop application to connect to a data streaming API using MQTT after overcoming some initial difficulties covered in this thread: Websocket connection to MQTT based API.

I am now trying to connect to the same API using an ESP8266 based device and so I'm in the process of porting my B4J code to B4R, however, I am uncertain whether the capabilities of the rMQTT library will allow that.

As explained in the original thread, the authentication call returns an "authorised url" and I can extract that along with the clientId from the response obtained from the authentication call using this JSON Parsing Code Snippet. The format of the "authorised url" (with line feeds added to make the query parameters more visible) is:


So my question is can I just use that "authorised url" as the HostName parameter in the mqtt.Initialize2 statement?

It seems from the comment "Note that the host name should not include the scheme (tcp://)" by @Erel in this post that at least I'd need to remove the wss:// prefix, but will mqtt.Initialize2 handle the query parameters included in the "authorised url"? Or do I need to use just xxxxxxxxxxxxxxxxxx.amazonaws.com/mqtt in the mqtt.Initialize2 statement and then include the query parameters in a mqtt.Connect2 statement? If so, how do I incorporate these multiple connection options? However perhaps I'm "barking up the wrong tree" because I think there are only a defined set of allowable connection options.

Any suggestions or guidance would be greatly appreciated.


Active Member
Licensed User
Longtime User
Well that puts an end to that Arduino based project and indeed it does seem suited to an RPi solution, but in a couple of attempts to use an RPI I've been unsuccessful. I've become very comfortable with B4J / Windows desktop and B4R / Arduino based solutions, but haven't yet come to grips with working with an RPi.

So this outcome is the motivation to try again . . . .
Last edited:
Upvote 0