Fair user policy accidentally breached

One of my RAK TrackIt devices has been accidentally posting data to TTN too much during the night, because of which probably the fair user policy has been breached. It was not noted that the device was still ON.

I see now that I can not send any data through TTS anymore from all of my LoRaWAN devices. Does this mean that my TTS account has become worthless and cannot be used anymore (as a kind of penalty)? Or can I not use it anymore during the next 24 hours?

Please let me know. Thanks for your answer.

Best wishes,
Addy

As per other comments I’m prone to making about such things, if the details of the FUP were unpacked we’d have people trying to gamify the system to hack their way around it.

Maybe you caused enough chaos to spike the graphs and someone at TTI pressed a button to make the problem go away. However don’t think of it as a penalty, think of it as protection of the network for the community users that abide by the guidelines.

If all your devices can no longer uplink, have you checked your gateway is OK?

In the absence of actual numbers it’s hard to provide advice - numbers like frequency of uplink on the tracker, approximate lat & long, how many devices & gateways you have etc etc

No one here can fix this for you, you can try to contact TTI, taking out a support contract will ensure a response.

Thanks for your answer.

I like to assure you that this was an unfortunate mistake. There was no bad intention from my side. I have always kept myself to the Fair User Policy with the few devices I am working with.

I see now on the TTS console that the devices joined the network, but do not send their data. Based on this I came to the conclusion that TTN blocked my account.

My devices have successfully send their data to a gateway I have here at home and also to another gateway not far from here owned by a school nearby. I could see that from logged connections.

I will check the gateway I have here at home.

You don’t have to assure me, I make no assumptions, I just say what I see in terms of debugging the FUP. As a device developer I’ve set the wrong compile flag before now and come back to a lot of logs that weren’t at all FUP friendly and weren’t on the account I thought they were - when testing 10 devices with different configurations it’s easy to get turned around. So the occasional screw up is factored in.

I’ve been shown a few of the graphs in the past and the consequential impact and in one case the only remedy was to delete the entire account because there was no response to emails asking them to stop trying to kill one of the integrations. That sort of action is very very rare but in the moment, if there is an impact, killing the sessions of devices is a good way to slow up the deluge. But this is conjecture as we have so little detail.

If your devices have joined they should then be able to uplink, depending on settings, which you’d have tell us about to be able to make suggestions. Some firmware knows to check the link occasionally and if it thinks it’s offline, it will then try a rejoin.

This seems contradictory! Is this the join or an uplink?

If you mean have connected rather than an actual OTAA join then there may be issues with the frame counter, again, can only really be definitive with more info.