How to login to TTN MQTT server

Application Development MQTT
1

Hi,

I am new to LoRa and TTN.

I would like to attach https://lorabridge2.github.io/ to TTN instead of owning a dedicated gateway.

I advised the AI to implement the connector and it looks fine now.

But: Login to the MQTT Server fails.

any idea why?

def on_connect(client, userdata, flags, rc):
    logging.info("Connected to TTN with result code " + str(rc))

    if rc == 0:
        # Subscribe to uplink messages for all devices in the application
        # Topic format: v3/{application-id}@{tenant-id}/devices/+/up
        topic = TTN_UPLINK_TOPIC
        logging.info(f"Subscribing to TTN uplink topic: {topic}")
        client.subscribe(topic)
   # JPT OLD client.subscribe(userdata["chirp"] + "+/event/up")
    else:
        logging.error(f"Failed to connect to TTN, return code {rc}")

You can find my source here:

MAIN branch is more or less what I am running, EMERGENT branch is what the AI produced.
If you want to see the original source just go where I forked from.
You can simply run converter.py from commandline, if python is set up correctly.

My log is:

$ ./converter.py
Starting TTN Converter
Connecting to TTN broker: eu1.cloud.thethings.network:1883
Username: 7D1903CBD0BBC269ACEE1DA1DBCD1995@ttn
Password: NNSXS.xxxx
Subscribe topic: v3/7D1903CBD0BBC269ACEE1DA1DBCD1995@ttn/devices/+/up
Connected to TTN with result code 5
Failed to connect to TTN, return code 5

Thank you very much.

JPT

2

The LoRaBridge developers appear to have bypassed any high level architectural overview so this is what it seems to do from a quick scan of the docs:

ZigBee → LoRaWAN device → LoRaWAN gateway → A LoRaWAN Network Server (like TTS, or in their case, Chirpstack) → a process somewhere that hears the uplinks and does something with them → Arrives in HomeAssistant.

The second to last bit appears to be the bit you are stuck on and won’t work with TTN because it doesn’t run a public MQTT server for general use. You can receive the uplinks via MQTT but you can’t then push back the data, because it’s not there for that. As ChirpStack doesn’t have a free public infrastructure, I can see how an individuals setup could do what they want in that regard.

You could push the data to a different MQTT server. But as for you are hoping you can use Someone Else’s Gateway rather than provision your own it’s going to need some justification. We work on the basis that we use each others gateways, not freeload off the network. Your throughput and any downlinks may exceed the Fair Use Policy - hard to tell without a lot more info.

3

Thanks for your answer. that makes things clearer. But I still have some questions.

So, how would I send my messages to TTN? If I simply send to another MQTT server how do they go through TTN to arrive at my Homeassist?

Ah, ok. didn’t want to freeride. The Discovery Plan says: connect up to 10 devices and 10 gateways.

Will be a single LORA bridge plus like two zigbee devices (temperature and a relay) that communicate through it. apart from that it’s a proof of concept. if everything works fine and I can estimate the traffic I will think about either paying for the service or buying a gateway.

I happen to have a MarryIoT/Helium Gateway. No idea if I could use this for TTN or a local gateway. MarryIoT pays for providing a gateway and they charge for every message sent.

haven’t set it up because I couldn’t find out how and they want to know a lot of personal data.

4

have you seen this?

5

I think this reinforces my comment which you address below, that it’s not got an architectural flow diagram. And hacking on LoRaWAN rarely works quickly.

The system seems OK right up to the idea that you take an uplink with the software you are working on, process it and then push it back in to the MQTT broker you got it from so that HA can pick it up.

  • So the somewhat complicated Zigbee to LoRaWAN device bit, fine.
  • LoRaWAN gateway, standard.
  • LoRaWAN Network Server - options are available, they use Chirpstack extensively with no mention of TTN, that’s a HUGE hint in my book, check.
  • Uplink receiver via MQTT, all good
  • Data processor, yup
  • Resend via MQTT server, not on TTN

The last three items are the very badly named “gateway-converter” - it’s actually an uplink data converter.

So if you use the Zigbee to LoRaWAN device, the LW uplink can be heard by a LW gateway that passes it on to a LNS and then that arrives in your application and is passed on - with TTN the preference is a WebHook but MQTT is also available.

So your code can hear the uplinks.

But what you can’t do is send the data back to TTN for HA to pick up. Because TTN is not providing a public MQTT broker for anyone & everyone to use. Because that’s not what an LNS is for. Chirpstack happens to allow it, but then Chirpstack don’t pay 10,000’s of $/£/€ a month to provide anyone with a free service.

So alter the code so that having processed the uplink, you send it to your own MQTT broker somewhere else. If you are running this on a Pi, you could run one on there. And then have your HA connect to that.

That’s for YOU to host up to 10 gateways. So if you’ve got the gateway hardware, just set it up for TTN, Google will provide info on the conversion if you ask it, a LW gateway is the same at the very heart, it’s the software that wraps around it that needs installing & setting up.

Yes, that shows what’s going on INSIDE a bridge - it doesn’t explain the external entities required - like the fact that it pushes the data back to the MQTT broker that provided the downlink. I had to infer that from your code. Which wasn’t helped by the naming as a gateway converter!

You can do what you want to do as soon as you setup an MQTT broker somewhere.

But you can’t do what you want to do with the TTN MQTT broker and no-one apart from TTI and a big pile of money is going to be able to change that. And even then, possibly not as the very reasonable pricing of TTI services is based on a uniform code base.

6

This doesn’t bring me anywhere since it’s the gap from the bridge-Pi to the HA-Pi i want to close with LoRa.

If I could communicate with the the bridge directly I wouln’t need Lora.

Or do you mean Mosquitto on the HomeAssist Raspberry Pi?

I do not really understand what you are saying. I am going to forward it to the authors of lorabridge. maybe they can help.

7

The repro you linked above appears to process uplinks from the LNS that it hears via MQTT and then pushes them back to the MQTT broker so the HA can pick them up. There is NO LoRa based code in the repro you linked to. The second line of the readme says it runs on the gateway.

It appears to me that it is a background task to make the data suitable for HA - hence the Docker config - that would sit anywhere on the internet but mostly near to your LNS / broker or on your home network. It is implied that it is on a network (Ethernet or WiFi), so I’m not sure why you need to link the bridge-Pi to the HA-Pi via LoRa. It does not appear to be directly referred to in the gateway graphic.

The bridge is the bit that sends ZigBee data via LoRaWAN. By definition it’s not on the internet as it’s using LW to relay the data back via the LoRa radio. So it won’t be able to connect to any MQTT servers. If it could, the LW bit would be rather pointless.

Perhaps sketch out a picture of all the parts you have to figure out what goes where?

8

Oops. You are right. Well, I started where they pointed me. Maybe there was a misunderstanding.

So I have to start all over again.

And yes, there should be some sketch of the topology.