Node-RED not connecting to TTN on Azure Ubuntu VM

General
1

My goal is to move data from The Things Network (TTN) using MQTT into Node-RED running under Docker on a Azure Ubuntu 22.04 VM.

My first step was to create a Node-RED instance under Docker on my Win10 desk top, and to initialize a -MQTT in- node for TTN. I completed this step and I can see data arriving.

Next, I created a Azure VM running Ubuntu 22.04 and I installed Docker and Node-RED(V2.2.3). I opened port 1880 on this VM and can now see the Node-RED GUI in my browser.

I created the same -MQTT in- node in the Azure VM Node-RED as I did in my desktop Node-RED. The TTN server communicates on port 1883. I opened this 1883 (both in and out) port on my Azure VM.

However after I Depoly in the Azure VM Node-RED, my -MQTT in- node forever shows "connecting".
The -MQTT in- node on my Win10 desktop works. The identical node on my Azure VM does not.

Any guesses what might be different on the Azure VM?

2

Welcome to the forum @mhead

Why use an old version?

Make sure have not specified the same client id on both systems. Each client must be unique.

3

"Old version" Oh... I believed I was using the latest Node-RED. I will attempt to locate and install the latest version.

"Make sure have not specified the same client id on both systems. Each client must be unique."

By "client" I assume you mean something about Connection Credentials at the MQTT Integration at TTN. True, I used the same credentials in both my Win10 desktop Node-RED -MQTT in- nodes and also my Azure VM -MQTT in- node.

Following your suggestion, I created a new password at TTN MQTT Integration Connection Credentials. I used this password with my Azure VM -MQTT in- node.

I now see a green "connected" next to my -MQTT in- node in the Azure VM Node-RED! This is an improvement since previously I saw a forever "connecting" in yellow at the same location.

I continue to see data arriving at my Win10 Node-RED, (I have a debug node connected which shows data in the debug window on the GUI)

But no data are shown by the identical debug node in Azure VM. My Win10 debug node has a blue dot displayed but my Azure VM debug node has no blue dot. I do not know what the absence/presence of the blue dot indicates.

So, thanks for your suggestion on client ID. You've given me a little progress since now I see green "connected" replacing yellow "connecting". But I'm not out of the woods yet.

Other ideas?
Thanks!

4

It is 3.1.8. I don't use Docker but I believe the node-red docker container provided by the node-red developers will be at that level.

No, the client id can be specified in the MQTT server nodes. If left blank then node red will automatically provide a unique id.

image

That means you have not deployed the changes.

Where is the MQTT broker you are trying to connect to and what have you specified for the server URL in the MQTT broker node (where I have owl.local in the image I posted)?

5

No, the client id can be specified in the MQTT server nodes. If left blank then node red will automatically provide a unique id.

I tried placing "some id" into the client box without success.

Where is the MQTT broker you are trying to connect to and what have you specified for the server URL in the MQTT broker node (where I have owl.local in the image I posted)?

I attempt Node-RED -MQTT in- node connection to a MQTT integration at The Things Network Sandbox. Here is the screen shot at TTN

Capture
Capture1202×688 57.1 KB

On my Node-RED side here is the server screen

Capture

(Security tab shows User Name: pme-test-application@ttn and password generated by TTN.)

The image above come from my Azure Ubuntu VM Node-RED. They also represent my Win10 Node-RED. Azure doesn't work but Win10 does.

Back to your notice of the Node-RED version. On Azure VM Node-RED is V2.2.3 whereas on Win10 Node-RED is V3.1.0. Perhaps this explains why Win10 works and Azure fails.

My next step must be to update Node-RED.

On Azure VM I have only a command line interface, no Docker desk top. I guess I am running Node-RED under Docker. I see something that looks like Node-RED in my Docker images on Azure Ubuntu VM. Here is the response I see:

mhead@LinuxAquasendIoT:/home$ sudo docker images

REPOSITORY TAG IMAGE ID CREATED SIZE
iot-app-nodered latest 419935a3924a 3 days ago 525MB
hello-world latest d2c94e258dcb 11 months ago 13.3kB
influxdb 2.6.1 2d51928ea51a 11 months ago 233MB
grafana/grafana-oss 9.4.3 944e84f25bc7 13 months ago 329MB

  • I guess somehow I must tell Docker to remove and discard iot-app-nodered
  • Then I must tell Docker to obtain the latest Node-RED container from who-knows-where. This would be something like "sudo docker pull ????" What do I use for the ????
  • And lastly I must tell Docker to start operation of this new Node-RED.

I found a list of instructions at URL

Update Docker Image

Should I follow these instructions?
Can you fill in the [docker_image] part in the statement below:

sudo docker pull [docker_image]

for me or tell me how to search the 'net for the answer?

Thanks!

6

If you are running in Docker you need to make sure you are able to access the internet from inside the container. I know little about Docker and nothing about AWS so can't really help much.

7

I followed instructions to update my Node-RED to v3.1.8 which I was able to pull from the Docker hub.
But the V3.1.8 doesn't present the GUI and, when restored, the Version 2.xx doesn't work anymore either.

I'm presently trying to get V3.1.8 going. When I do (if ever) I'll post the results here as to weather V3.1.8 fixes the MQTT TTN problem.

After some confusion I have Node-RED V3.1.8 going and replacing Node-RED V2.2.3 on my Azure Ubuntu VM.

Node-RED V3.1.8 operates as expected! It connects to TTN and data arrive at the -MQTT in- node!

I did many command line operations as I replaced V2.2.3. Some of these were in error. I can not be 100% sure that I didn't do something else besides simply upgrade V2.2.3 to V3.1.8.

It appears however that your original observation of my use of a old version was correct and that the old version was somehow responsible for the problem.

Thanks for advice so far!
Mike