Hi there.
I found an issue regarding a failure build-up on a Broker - url: Supposed the url contains a domain and a path like that http://www.example.com/mqtt
the port is added to the completed end at the moment.
But it should look like this:
Right: http://www.example.com:1883/mqtt
Wrong: http://www.example.com/mqtt:1883 (as it’s now).
Affects on mqtt - in, mqtt - out and mqtt - config nodes.
Best reagrds
node-guy
Does everything work for you if you use http://www.example.com and not http://www.example.com/mqtt as the server name?
i,e does appending the /mqtt return a different IP address for the broker?
Simon
Hi Simon,
thank you for your fast reply. I tried with your suggestion but with no success. It seems the broker needs the specialized mqtt path.
Best regards
node-guy
mm intriguing … what broker is it?
I send you a link for description about the broker
http://cumulocity.com/guides/mqtt/implementation/#connecting-via-mqtt
There’s a note which tells you only available over the path /mqtt
Best regards
node-guy
I seem to be connected
The instructions I found said /mqtt was only needed for websocket connections
http://cumulocity.com/guides/mqtt/hello-mqtt-0
Hi Simon,
first thanks for your reply and sorry for my late answer.
Yes it works for the mqtt over tcp with port 1883. The problem we have is that in most cases the port 1883 is blocked by firewalls (same 8883). So we decided to take wss (port 443) to send data to mqtt broker. Any other ideas?
Best regards
node-guy
if you were trying to use websockets, you shouldn’t have been using http:// web sockets url begins with ws:// secure websockets with wss:// not http or https
As @ukmoose says websockets uses different method
here is my connection setup for websockets (I used port 80 but port 443 should work equally as well once you sort of certificates etc)
Hi ukmoose,
yep I know that. It was just an example to explain my problem.
Best regards
node-guy
Could you restate what your problem is then as I’m confused
Hi,
okay. Again.
My problem is that the broker on cumulocity is availabe over websockets with the path /mqtt.
We need to use websockets because the port 443 (TLS) is free on most firewalls.
The mqtt nodes build the url on the wrong way: wss://[tenant].cumulocity.com/mqtt:443
The url should look like wss://[tenant].cumulocity.com:443/mqtt
Best regards
node-guy
If you configure the server field as wss://[tenant].cumulocity.com/mqtt
then the node will use exactly that as the url passed to the underlying mqtt client - it doesn’t append the port number.
The node only appends the port number if the server field does not start with ws://
or wss://
(more specifically, if it doesn’t contain ://
).
Can you see that I’m connected? ![:slight_smile: :slight_smile:](https://emoji.discourse-cdn.com/twitter/slight_smile.png?v=5)
I’m using
ws://mqtt.cumulocity.com:80/mqtt
as URL (as said before not tried 443 but can’t see why it wouldn’t work if you put cert info into node config)
As far as I read the docs, you don’t use wss://[tenant].cumulocity.com:443/mqtt
The docs say to use tenant info in user name (on security tab in config dialog)
http://cumulocity.com/guides/mqtt/hello-mqtt-0
Hi to both!
You’re right. After updating to the newest node - red version it looks really good. Thank you very much!!!
You make my day!
Best regards
node-guy
I've seen others get tripped up on the MQTT over Web Sockets configuration. How about we add an additional checkbox "MQTT over Web Sockets" following the same pattern as "TLS"? It looks like there is some dead code indicating that this was the intent at some point in time.
See pull request https://github.com/node-red/node-red/pull/1875.
Sounds reasonable idea
JFI The NodeRED team usually ask for a discussion on here or Slack before pull-requests are issued
It gives normal users a chance to get involved in the discussion rather than just coders ![:slight_smile: :slight_smile:](https://emoji.discourse-cdn.com/twitter/slight_smile.png?v=12)