We are experiencing issues with mqtt from Australia Meshed Handler, i Hope that current catastrophe due to the fires is not the origin and that the Australian people soon manage to control the fires.

The last mqtt hit was 08/01/2020 19:16:10

I´m connecting iotfactory platform thru mqtt with TTN and from 1 day ago, no mqtt connection was possible.

Not sure mate, the fires have been extensive here. I put the outage for 12 hours last week possibly to the fires as the connections eventually resolved themselves last time. I’ll have to check again today was still offline as of last night so maybe 48hrs offline now.

Just makes me nervous as we are looking to potentially deploy a lot of nodes commercially with TTI. We have a few POC nodes on TTN which have been working great for the last 3~4 months. On the day we had a quick chance to show our customer the progress unfortunately the network was down so we didn’t have any real current data we could show them.

Ok, will look into changing them over. Maybe just lucky we haven’t hit this issue before.

from I am not able to make any integrations when I register to either us-west, EU, or meshed_handler. Is there still an outage for AU? Does the meshed server not work at present for integrations?

I have switched to using the SE Asia handler and the AU-915 bands. Then don’t use the meshed console - just use the regular TTN console

There are other ways around but the meshed handler/meshed console just seems to introduce unnecessary complications.

In you’re in Australia you should use:

  • meshed-router for gateways
  • meshed-handler for applications
  • for the Console when configuring integrations. You can use the regular console at all other times.

The problem with using asia-se is that other people in Australia may have applications registered on meshed-handler trying to use your gateway and the cross-region routing is intermittent and won’t be resolved until V3 is implemented.

:warning: See also below for a July 2020 discussion about:

1 Like

I was using the meshed-router for my nodes at university since June , and it was working ok for AU915 frequency plan until this last weekend. I figured out that the OTAA Join Accept is using a different frequency from TTN frequency plan ( Have anybody also detected this behavior ?

There is a problem with OTAA Joins at the moment on the Australian network. Some devices (mostly random) are affected. We are in discussion with the TTN Core Team and hope to have it resolved overnight.

Thanks, the instability has been solved !!!

Hi @Maj, hoping you can shed some light:

  • After about 4 months of operation on around midnight on 8/7/2020 I lost connectivity from a bunch of my Laird RS191 field sensors across a bunch of Dragino LG308 gateways. Turns out that the reason for this is that their Join-Accept’s started specifying the downlink frequency of 923.2 (vs 923.3). FYI I’m on the AU915 band.

  • After much troubleshooting I’ve discovered that due to a bug in the LG308 GUI, they were using the router (incorrectly listed as “meshed-router” in the GUI) as the server address on the gateway. So all my gateways in the field are pointing at this rather than the AU915 router.

My running theory is that the router has been processing AU915 downlinks correctly up to midnight wed 8th July 2020.

All my gateways are in the field and I don’t have remote access, so hoping I can find a way to get 923.3 Join-Accepts from the router… BTW, all my gateways are registered on TTN with the AU_915_928 Frequency plan…

Do you know or can you advise how I could find out if there have been any changes in the oz meshed network that could have triggered this??

Thanks and kind regards,


Is there an issue with meshed? I was running my devices 2 weeks ago with no issue but now I cannot get my devices to connect. my gateway connect correctly but I cannot get sensors to join. They are just sending join requests. Trying to use AS923 and have tried AS1 and AS2
Is there any status dashboard for meshed? very frustrating…

Just in case it helps, from Slack on Thursday July 9th (Amsterdam time):

@maj 2020-07-09 9:46 AM

Actually, the backend has undergone a significant update on Wed, then a partial rollback yesterday. If your gateways are using MQTT then for now there should be no difference, but the UDP bridges have now been replaced by the v3 GS Offloader.

They still should show the correct frequency plan though.

There’s is more about that on Slack; see also How do I get a Slack invite?

@arjanvanb Thanks Arjan for the feedback - I’ve joined the Slack channel, and reading through the thread it does look like the timing of the changes on the meshed router backend correlates with the impact to my traffic. Interestingly, my backend also reports correctly via “ttnctl gateways list” as AU_915_928, but when doing "ttnctl gateways status " shows EU_863_870.

Reported time: 2020-07-19 13:24:30 +0800 AWST
Frequency Plan: EU_863_870
Bridge: gs.v3.

[Edit][2nd Edit] Actually, if I add in “–router-id meshed-router” to the command above I get the AS_923 frequency plan:

   Reported time: 2020-07-20 00:36:09 +0800 AWST
  Frequency Plan: AS_923
          Bridge: gs.v3.
      IP Address:

So just need to figure out via @Maj if can still honour the AU915 frequency plan that’s assigned in TTN and listed with “ttnctl gateways list” command like it was before rather than what I assume is the default plan for the gateway itself…

Hi @davo30au and @dbrosy, I replied to you yesterday but I can’t see my posts on this thread, so trying again…

In addition to @arjanvanb’s reply,
AU915 UDP gateways should point to
AS923 UDP gateways should point to
AU915 and AS923 MQTT (and other) gateways should point to (or

Nothing has changed in this respect, but the recent (8-Jul) upgrade means that incorrectly configured gateways will end up with the wrong downlink frequencies, hence why joins will fail.

Running ttnctl gateways info might show the incorrect band plan for your gateway. Don’t worry about this, it is incorrect. It’s because ttnctl doesn’t support the new V3 gateway offloader completely.


Just to be sure: “incorrectly configured” refers to using the wrong URL, right? (Not to some mismatch in Meshed’s Console, which only then yields wrong frequencies for gateways that also use the wrong URL.)

incorrectly configured

Good point. I was referring to gateways using the wrong server address, but they need to be configured for the right band plan in the console too.

So the gateway’s frequencies in global_conf and the server URL in global_conf (or local_conf) and the Frequency Plan in the TTN Console all need to match.

1 Like

The main Semtech UDP forwarder page could do with an update to reflect getting AU915 onto an explicit address.

I created a pull request to reflect this.

1 Like

This fixed my issue. awesome thank you

Hi @Maj, I’m having similar problems to those mentioned in this thread where the gateway is being instructed to use a different download frequency band to the upload frequency band. I’m based in NZ and trying to use the EU_863_870 frequency plan. The uplink frequencies are in the 860 MHz range but the gateway is being told to use a downlink frequency of 923.3 MHz.

Running ttnctl gives:

ttnctl gateways info <gateway-eui>
      Gateway ID: <gateway-eui>
  Frequency Plan: EU_863_870
          Router: meshed-router

ttnctl gateways status <gateway-eui> --router-id meshed-router
  Frequency Plan: AU_915_928
          Bridge: gs.v3.

I’m using a Semtech UDP type gateway and I’ve tried routing to, and, and but it all results in the same behaviour.

I’m reasonably new to TTN and have read the associated slack thread but have run out of ideas. Do you know of a way to change the frequency plan of the underlying gateway status to be EU_863_870?

Hi @Maj

Thanks for the concise set of links. BTW, this is the first time I have seen the need for a gateway to point to , I always thought it was for Au915. That’s the address published on TTN web site when registering a new gateway.

Couldn’t work out why I had never seen this before and went and searched and from what I can see this is the first time “” has been published on this forum.

I’m wondering if some of this can be rationalised and realigned with the TTN naming convention used elsewhere around the globe by editing the DNS records for some of these domains.

Just a thought.