Since about 2 days we get only activation messages to our applications. All of them worked before and the traffic is showing in the gateway console. I may have pushed the fair use terms incidentally on some of them but not on all (and I wish that would be not so wishy-washy but trigger a notification explaining why it does not work and when I would be allowed to reconnect). There are also applications that are shared with me and I don’t touched them at all and they are well within the fair use limits but they behave the same way. Does anybody experiences a similar problem? I am in the US915 region. I did also check on the frame counters and disabled the check on some of the devices in order to debug.
Are you saying that devices that were sending data uplinks just fine earlier, have somehow been restarted and are sending OTAA Join Requests again? And that this happens for all your devices? And is this shown repeatedly for the very same device?
Or are you saying that devices that were sending data uplinks just fine are now not seen in the application’s Data at all, but you’re still seeing new devices (that still need to join) just fine?
So this refers to the OTAA Join Request and Join Accepts? Or are you referring to also seeing data uplinks in the gateway Traffic, but not seeing those uplinks being forwarded to your applications?
(The Fair Access Policy is not being enforced yet. Of course, if you’re exceeding its limits and others are as well, then you might see more collisions. But even that does not explain why devices that were working fine might now be trying to join again, if that’s what you’re saying.)
I’m having a similar problem.
More than 200 devices registered by ABP, all operating for 6 months without problams, 2 days ago the data stopped appearing in Applications. There were no modifications, today I realize.
On the gateways tab I see the data that arrives, but in applications nothing.
Was there any change in the policy of registering devices in the Applications?
Are you seeing data in Integrations or when using the MQTT API? Were all devices taken into usage at the same time? How often do they transmit? Are they set to 16 bits or 32 bits counters? What routers (region) are the gateways registered at? And the handler for the applications?
(Seeing packets in the gateway’s Traffic page but not in the application’s Data page usually indicates a frame counter problem. Editing an ABP device in TTN Console might reset the counters to zero in TTN, but of course you did not edit all 200 so that can’t be it. But: beware when editing in TTN Console!)
Arjan, thanks for answering.
In integrations I use HTTP and send the data to an AWS server, but the data 2 days ago stopped appearing in the data within applications.
The devices do not transmit all at the same time and shipments are made every 1 hour. They are configured in 16 bits
There are 15 gateway receiving the data.
The gateway region is US915 and the applications in ttn-handler-eu
I have the option of the counter in the applications disabled.
Aside: this would imply the 16 bits counter overflows after 7 years, so that’s not likely to be the issue.
The gateways’ routers are also set to something in the US? at might be the issue then, though nothing was reported, yet.
All of the above. We have OTAA devices that have been working fine for 6 months. We have one development device that sends intermittently on ABP (framecounter turned off) and we have two OTAA devices that are used for dev and joing intermittently as well and try to rejoin after failed transmissions. Tested them with and without framecounter check enforced. Just chatted with a colleague who experiences the same issues with an entirely different account, gateway, and application (using OTAA). He managed to get it to work by recreating the application which did not work for me.
Be very cautious about this: that would reset the downlink frame counters, too, which could cause the nodes to start rejecting everything (such as ADR) from the network.
Best would probably be to take a raw packet and manually decode it with the known keys, or really more specifically, see what frame count valid the MIC validates for.
Figure out what the problem is before changing things.
Could very well be some outage network-side.
Yes. Also, if the uplink counter has already exceeded two times 65,536 then TTN will not be able to validate the MIC, so will also discard the message. 
Yes, I see both in the gateway console. Join traffic and data traffic. And I get a transmission success in my script. The data messages don’t show up in the device console or the MQTT integration. Disabling the frame counter check did not help. I have a few devices on my bench. In those cases it is not a problem for me to reset the frame counters.
Looks like outage to me.
Any difference in the used regions for you and your colleague? Like, maybe: are your applications registered to a different handler than theirs (like ttn-handler-eu, just like @Sikron, rather than ttn-handler-us-west), and are these in the same region as the gateways’ routers (like ttn-router-eu or ttn-router-us-west)?
(Just trying to find the commons between you, your colleague and @Sikron. Also, don’t forget to report on Slack.)
Using which router?
Current gateway router is ttn-router-eu changed that from ttn-handler-west since all the applications are in ttn-handler-eu. Will try alternative settings.
I moved a device over to ttn-handler-us-west and it started to work again. This is a big hassle because it means to create a new application with all its implications. So basically ttn-handler eu is currently not working.
Probably not helpful for you:
For OTAA devices, @htdvisser created a migration tool that might help to move devices between networks (TTN to enterprise networks and vice versa) or between clusters (TTN regions). But that needs a new OTAA Join as the DevAddr includes a reference to the region, so the device needs to get a new DevAddr. And for ABP, this does not work at all.
Not with cross-region traffic, or something like that.