The id is like v2, something you can use to id the HTTP integration / Webhook
Webhook format should be JSON (it’s what we had in V2, I don’t have time to learn Protocol Buffers and I have a PHP script that can semi-auto read JSON)
The Base URL is the v2 URL.
The rest can be left alone unless your script requires some authorisation id.
You will have to make substantive changes to picking out the data you want from the new expanded format, but it’s still just JSON. But it’s just a different structure. Not something I’d describe as leading to problems, just different.
It can be done on both. However it does put additional load on the stack to determine which application should be used. And you can just as easily delete the device and and it in the other application. And back…
If you use the command line tool to add an device you can even create a batch file to first delete and next add.
V2 will become ‘read only’ today so you should be moving devices away from it. Not between applications on the V2 stack.
Hello all, I was wondering: since TTN V2 has become read only since the beginning of July I can’t change the AppKey anymore of devices in V2 in order to prevent them from joining again with V2 except from deleting the device all complete.
But since that has the risk of devices not being able to reach anymore, I was wondering if there is any alternative right now for this?
As Nick says we discussed this very issue earlier and as you decided changing a part of the AppKey (or indeed the AppEUI or DevEUI) in V2 would be the classic way to disable before more drastic delete. In my case I checked V3 logs and see the V3 join request being actioned - with a Join accept & with a DevAddr allocated, but of course the V2 infrastructure responds faster and the node takes the offered V2 Join ack and associated DevAddr before the V3 Join ack arrives. Since talking to Nick have decided that as I am confident V3 join ack happening and DevAddr clearly being allocated I’m just going to bite the bullet and delete device in V2 as there is no going back now and I cant even see the data traffic now in console with latest changes - I just monitored the device with the console and had no integrations set up for that specific device & application.
Will delete tomorrow and keep fingers crossed.
@Inou Recommend you check your device/app logs in V3 also and see if the join accept is triggered (and if you look in the associated metadata you should see a V3 DevAddr allocated also). If it is perhaps you do the same?..
Hi @Jeff-UK , I totally recognise your problem and have exactly the same. I’m currently migrating devices of a customer of me, and they have a good coverage with TTN V2 gateways.
I experience exactly the same that I see the join accept in V3 (after I trigger a rejoin with a downlink from V2) and the device counter is being set to 0 in V2, but sometimes the device keeps on rejoining and then continues in V2.
I already bit the bullet and have deleted some devices from V2 and as a result thereof have already 3 of the devices coincidentally lost…
When I tested this back in June, it worked fine with changing the AppKey, but now I’m afraid that I have to drive across the Netherlands to fix my problem…
Or maybe I should wait until more gateways in that area are migrated to V3… But I’m a bit afraid to do that since V2 is going down the drain fast right now…
Somewhere it is a bit soothing that I’m apparently not the only one with this problem, but I hope the hard workers of TTN have an alternative for us!
Not sure that strategy would work, I think V2 transit times are just faster - not least as there may be transit times through PacketBroker when transitioning between V2 & V3 GW’s and Apps/Devices, also Rx windows are set shorter in V2 than V3 so suspect that is another factor… Node (depending actual internet routing as well) will just see the V2 before V3 - only when V2 off will V3 be guaranteed to ‘win’ the race I suspect.
Am not a fan of CLI’s unless playing with some linux bits so havent tried yet but have you looked at/tried the V2 to V3 CLI migration tool/script? (ttn-lw-migrate tool) Nick is a fan of such options and perhaps can guide you - suggest you go read the CLI/tool install and use docs 1st and come back with questions if needed?
Sorry to hear that - perhaps I will hold a while then!!! Though I atleast have ready access to the device in question if I need to reprogramme…
I’ll have a go at the v2 CLI in the morning but I’ve added my 2c worth on Slack.
I think the missing concept for the TTI eggheads is that a good number of older devices don’t have any of the link check code in the stack - so they never check if they are online ever. And a fair few implementations don’t have a rejoin/reboot downlink command baked in.
So if we can’t change the AppKey, even if we go to the device to restart it, we either have to reflash its keys OR wait until 1st Jan when the v2 gateways aren’t online & then cycle the power manually, ie up close & personal.
Final observations of the night, don’t send a reboot command as confirmed and don’t eat yellow snow.