Go to settings, scroll down, click delete, modal pops up, click delete, how so accidental?
Anyhoo, the docs are clear on what you can do, check out the section on Deleted Entities
Accidentally deleted as in, I didn’t know these were the consequences. Thanks i’ll check them out!
Okay Already finished reading it. it is actually quite short: deleted entities
After reading this I understand there should be no restriction and I should be able to re-use the AppEUI and AppKey combination right?
I just tried a new OTAA join request with the device and unfortunately it does not go past accept join request. Is this a sign there is still something wrong? Is the clearing of these keys perhaps a daily server event?
Thanks once again for your time and patience.
Are you asking or telling? Given that you’ve deleted it, what would be the worst thing that could possibly happen if you gave it a try.
I’m assuming you are putting in the same DevEUI as well.
Again, asking or telling? What is normal for LoRaWAN after a Join Accept is transmitted? What would “good” look like?
Not that I’m aware of but I only read the code they write and whilst they have relaxed the “what you can delete and when” policy, I’ve not come across anything that needs a database purge as yet.
How are you able to force a join? Where did you get the copy of the EUIs and key from? How long after the device has been nudged and its joined would you expect the first uplink? What is the device? What firmware does it have? Does the LoRaWAN version in the firmware match the version in the device because if the NS is sending MAC requests that the device doesn’t understand or can process, it may not get any of the really important settings that it needs - like the channels, the Rx1 window timing etc. Has it retried to join if it hasn’t uplinked since the first join request? Does the firmware retry to join or do you have to nudge it? When it’s “nudged”, is that a power cycle that clears all the settings like the JoinNonce or some other mechanism?
Thanks once again for taking your time to answer my questions.
I’m telling you that I have just tried a new OTAA Join. The device I use, a watermeter by iotvega has an option where if you hold a magnet near a specific point for 20 seconds it will reconnect and immediately send an uplink message.
I have done this a lot during testing so I know what the sequence looks like.
The device indicates is in join mode on the actual device.
In the TTN Console I see Accept join request.
Approximately 20 seconds I see an uplink message with a payload coming
Session info on the device page in TTN appears.
This time, after ‘accidentally’ deleting the device and adding it again I repeat the same proccess as above.
Now I see in my console:
The device indicates is in join mode on the actual device.
in the TTN Console i see Accept join request multiple times.
After 4 repeated messages this stops.
Nothing else happens
Session info DOES NOT appear on the TTN Device page.
To answer your other questions:
- I have set the same LoraWan firmware as the other devices that are currently working correctly (same device, same manufacturer)
- I’m not sure about your last question wether is clears these settings
- I have tried above sequence a few times.
Context & detail are everything - the fact that you’ve tested this & have other devices eliminates many possibilities, but without that information we have to second guess the questions to ask. And anything ending with a question mark is usually a question is it not?
I’m saying I don’t know definitively but I have not seen a requirement to wait for a database purge and you would receive an error message anyway if TTS thought you were entering a duplicate and it certainly would not issue a Join Accept either.
If the device is sending a Join Request that is getting generating a Join Accept, then it would appear all is well with the device registration.
The only wrinkle is why isn’t the device hearing the transmitted Join Accept, so one thing to check is that the expected gateway is transmitting it (look at the gateway console and at the gateway logs). And is there anything in the environment that may have changed, like someone leaving a magnet on top or a metal case open or something?
You are right I could have been more specific in my original post.
I thought the exact same. (the device not being able to hear the reply from the gateway).
In this case it is an TTIG gateway (connected to v3 if it matters) And I had the log open real time and it did transmit a downlink.
Come to think of it we have experienced the exact same bug a couple months back when I also re-added an device (to test the adding feature in our webapp UI).
I didnt think of this being the cause back then hence I didnt bring it up earlier in our conversation. Back then I was also unable to assess the device personally, so we left it there because we would come back to that site a few months later.
But then all of a sudden, after perhaps 1 or 2 weeks, the device connected again and functioned properly from there on.
I’m hoping the same will happen here, allthough I hope we wont have to wait another 2 weeks. To exclude it’s a gateway issue I will ask someone to switch on our other gateway nearby (TTOG with a proper antenna which is offline now for maintenance) and report the results.
I will keep my updates posted here.
Cool - would be good to know how it goes because it adds to the general knowledge of confusion - that is to say with so many parts and not always being privy to the actual internals of a device let alone a serial debug output - it is sort of useful in a moral boosting way to know that sometimes ‘stuff’ happens and we have no idea why it stopped or started working. Or someone may be able to use it to link up some other information and suddenly we have a new solution or procedure to try.
1 Like
In this recent post (5 days ago) I read admins have the possibility to perform a purge. Is there perhaps an admin who would like to try this with me if something similar exists with an device?
Thanks in advance once again.
Hmmmmmm, asking the same question twice in different places, very naughty.
See my other reply
1 Like
Yes my bad I didn’t realize I was the admin
It seems however that this was a dead end.
I’m starting to think it might be related to the hardware I’m using that, as you suggested earlier, it might indeed be keeping the join nonces etc for a certain period of time.
I’ll contact the manufacturer on Monday and see what he has to see about that. If he replies saying that this is not the case and it should rejoin correctly then I will try deleting all devices in the application, then the application itself and finally purging it, in the hope that the AppEUI and AppKey combinations will get released again (assuming they’re blocked if the hardware is not the cause).
I’ll keep you posted.
So we did another test with the device with a TTIG gateway nearby.
See the verbose output from the gateway and the device page:
Device page:
Gateway page:
The same message sequence repeated 3 times.
I’m a bit clueless on what to do next.
I’ll try to contact the manufacturer and see if it goes wrong on the device side.
I’ll dig out my notes - somewhere I have the magic command to flat line the MAC state, resetting everything. When I’m in the office later on I’ll dig it out.
1 Like
I just had contact with the manufacturer and he confirmed to me that “the magnet trick” which forces an OTAA join should reset all the keys hardware side. He suggests somewhere on the TTN the old keys are still being used or something not properly reset.
Would a next step be deleting all the devices and then finally the application?
It is recommended on v2 to swap the last two digits of the AppKey to prevent join attempts to v2 - tested & working after a brief hiatus where we couldn’t save it.
The note I was thinking of was to do with removing the downlink queue:
ttn-lw-cli dev set $application $device --unset mac-state.pending-application-downlink
from a GitHub issue, so not neatly filed away. But it indicates the possibilities for nuking a device state on the NS - the question that then comes up is how long before the device does a link check but in this instance you are zapping it with the magnet to speed up the process.
For the CLI as well as the official docs at Command-Line Interface | The Things Stack for LoRaWAN there is the somewhat out of date but easier to drill in to https://descartes.co.uk/TTSv3CLI.html revealing such items as:
ttn-lw-cli dev reset $application $device --all
Further information on the blizzard of options can be found here: https://www.thethingsindustries.com/docs/devices/mac-settings/
But as suggested by the manufacturer, best to ensure there is no way it can connect to v2 first but I’d not delete it as it may be useful to see it working on v2 to confirm that that may be the issue.
Somehow I cannot flag your comment as the solution but this was it!
I used both commands, because my person on site only had the time to troubleshoot once but it worked straight away!
I’m gonna write it down and guard it for life! Thanks a lot =)
1 Like
Seems I can flag it myself so I have done, maybe a setting under the hood for us to check on who can set a solution.
I think the
reset --all
option probably does everything in one hit, but the main thing is that you are operational.
Perhaps this could be documented somewhere in the future? In the rare case that a user deleted a devices with a hardcoded AppKey en AppEUI, and wants to re-add it to the same application.
It is, right here, forum searching for the win!
Trouble with a system as huge as a LoRaWAN stack is where do you draw the line trying to document all the situations versus having a collective of people with enough knowledge to be dangerous who can go looking in the documentation.
If you look at the drill-down guide to the CLI you can see how many potential commands there are - and the aspiration at TTI once they get themselves another React developer, is to add all those commands to the web console by some means!
The other challenge to the jigsaw is the different devices with their varying support of the specification - so two apparently identical situations can lead to two radically different solutions just based on the firmware on the device & it’s ability to process MAC commands &/or be told to rejoin or reboot (or self-destruct) remotely or in-person.
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.