NodeRed not conect viac mqtt on TTN Stack 3.32 on Rocky Linux 9

1

I recently installed the latest version of TTN Stack on Rocky Linux, and so far, everything is working fine. The gateway connects via the packet forwarder, and the sensors are successfully registered in the applications.

However, I’m having trouble extracting data from my TTN Stack server using Node-RED. In the previous version, with the older interface, I was able to retrieve data via an MQTT client in Node-RED. The topic I used to read was:
v3/poc-idutto/devices/eui-XXXXXXXXXXXXX/up.

Now, with the new version (v3.32), I can’t get it to work. Could someone please help me understand what I’m doing wrong? It worked perfectly in version 3.26.

Any guidance or suggestions would be greatly appreciated!

2

Are your application still the same?

3

Yes the same

4

“I identified the issue just by reading your comment. From what I observed, it can’t be v3/poc-idutto/ because I believe the dash in the application name might not be supported. I created a new application without the dash, and from there, the MQTT client in Node-RED was able to connect to the TTN Stack broker. Thank you for your help!”

5

"I am now able to connect to the TTN Stack topic on Node-RED via MQTT, but no data is coming through. Is anyone else experiencing this issue?

6

What do you see in the application console?

7

I discovered recently, a significant change was introduced in the way MQTT topics are structured in LoRaWAN network servers, such as The Things Stack (TTS). The topic no longer uses the DevEUI to identify devices. Instead, the new format is as follows:

v3/{application-id}/devices/{device-id}/{event-type}

Key Changes:

  1. Use of Device ID Instead of DevEUI:

    • The device identifier is now the Device ID, which corresponds to the name assigned to the device in the platform. This replaces the hexadecimal DevEUI previously used in the topic.
    • This makes integrations more user-friendly, as you can assign descriptive names to devices rather than working with hard-to-read identifiers.

  2. Topic Structure:

    • The topic includes the application-id, the device-id, and the event type (e.g., uplink, join, ack, etc.).
    • Example:
      v3/my-app/devices/kitchen-sensor/uplink

  3. Benefits of the Change:

    • Improved Readability: Using the Device ID makes it easier to identify devices, especially in large-scale applications.
    • Enhanced Compatibility: The new structure aligns with The Things Stack V3 standard, ensuring better interoperability and scalability.
    • Greater Flexibility: You can create unique and meaningful names for devices, simplifying device management in applications.

  4. Payload Format:

    • Device identification, which was previously part of the topic (via DevEUI), is now included in the message payload in JSON format.
    • Example of payload:
      {
  "end_device_ids": {
    "device_id": "kitchen-sensor",
    "application_ids": {
      "application_id": "my-app"
    },
    "dev_eui": "AABBCCDDEEFF0011"
  },
  "uplink_message": {
    "f_port": 1,
    "frm_payload": "data-encoded",
    "rx_metadata": [...],
    "settings": {...}
  }
}

Recommendations:

  • Update Your Code and Workflows: Ensure that your integration scripts and tools are updated to use the new Device ID instead of the DevEUI in the topic structure.
  • Refer to the Documentation: Check the official documentation of The Things Stack for detailed examples and guidance on adapting to the new topic format.
  • Choose Device IDs Wisely: Since the Device ID is part of the topic, assign unique and meaningful names to devices to make management easier.
8

Sorry to say, but this has been the format of v3 since its release.

TTI have a clear public policy on API breakages - they don’t.

I’ve not seen anything radical change over the last 3 years and some of the CLI commands I’ve used have come up with a warning message that says it’s not in the “no-break” policy so we generally get plenty of heads up.

So I think most people will be on top of the changes - if it’s working then you are already using the right formats but certainly the other two recommendations stand - only takes a few seconds to check the very comprehensive docs and sure, some device-ids are just asking for trouble but remember, naming things is a whole job in it’s own right, most useful facilitated with some liquid refreshment.

9

I understand, but in this last version of TTN-STACK my nodered stopped connecting to the network server and it was because of this that I started researching because as my network server is local I have been using version 3 for some time but now that I migrated to the last with the new interface and then I started to face the problems described at the beginning of my topic. What seems to me that there is a break in the api yes in this type of integration