I read the V3 documentation, but i can’t find a solution!
Creating Webhooks | The Things Stack for LoRaWAN (thethingsindustries.com)
In V3 I have to make decisions for which I have no information because I did not have to set this before in V2!
I am only user of the interface!
I only see, that the infercae workes not for me!
E_T
If you want other users to be able to help you you should be more specific.
(I have not used the webhooks myself.)
Please give any details like.
TTN V3 is still new and TTI has not worked out all migration guides yet unfortunately.
It’s almost identical to V2. I didn’t even break step setting up a WebHook using my V2 PHP scripts - no changes in PHP, just a change of UI but still very similar in V3.
There are some additional options, but if you don’t need them, don’t worry about them. About the only extra you do have to choose is JSON vs Protocol Buffers - V2 was only JSON, so stick with that.
What are the settings in the webhook to get the behavior of the old settings?
Is it possible that the changed format for the payload on the server side leads to problems?
E_T
Like this:
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.
Ok, thanks!
A post was split to a new topic: Importing devices in V3 with JSON generated by V2 ttn-lw-migrate tool fails
Tool in WIN10. First I set:
D:\tmp\migrate_ttn>set TTNV2_APP_ID="my-ttn-app"
D:\tmp\migrate_ttn>set TTNV2_APP_ID="nmpmaq"
D:\tmp\migrate_ttn>set TTNV2_APP_ACCESS_KEY="ttn-account-v2.2iw3xxxxxxxxxxxxxx9qctlwV7jCowj2Nc"
D:\tmp\migrate_ttn>set FREQUENCY_PLAN_ID="EU_863_870_TTN"
D:\tmp\migrate_ttn>set TTNV2_DISCOVERY_SERVER_ADDRESS="discovery.thethings.network:1900"
Then I run the tool and got errors:
D:\tmp\migrate_ttn>ttn-lw-migrate devices --dry-run --verbose --source ttnv2 nmpmaq-00059590f10fe481
DEBUG [core]parsed scheme: ""
DEBUG [core]scheme "" not registered, fallback to default scheme
DEBUG [core]ccResolverWrapper: sending update to cc: {[{"discovery.thethings.network:1900" <nil> 0 <nil>}] <nil> <nil>}
DEBUG [core]ClientConn switching balancer to "pick_first"
DEBUG [core]Channel switches to new LB policy "pick_first"
DEBUG [core]Subchannel Connectivity change to CONNECTING
DEBUG [core]Subchannel picks a new address "\"discovery.thethings.network:1900\"" to connect
DEBUG [core]pickfirstBalancer: UpdateSubConnState: 0xc00062f7d0, {CONNECTING <nil>}
DEBUG [core]Channel Connectivity change to CONNECTING
WARN [core]grpc: addrConn.createTransport failed to connect to {"discovery.thethings.network:1900" "discovery.thethings.network:1900" <nil> 0 <nil>}. Err: connection error: desc = "transport: Error while dialing dial tcp: lookup tcp/1900\": getaddrinfow: The specified class was not found.". Reconnecting...
DEBUG [core]Subchannel Connectivity change to TRANSIENT_FAILURE
DEBUG [core]pickfirstBalancer: UpdateSubConnState: 0xc00062f7d0, {TRANSIENT_FAILURE connection error: desc = "transport: Error while dialing dial tcp: lookup tcp/1900\": getaddrinfow: The specified class was not found."}
DEBUG [core]Channel Connectivity change to TRANSIENT_FAILURE
DEBUG [core]Subchannel Connectivity change to CONNECTING
DEBUG [core]Subchannel picks a new address "\"discovery.thethings.network:1900\"" to connect
DEBUG [core]pickfirstBalancer: UpdateSubConnState: 0xc00062f7d0, {CONNECTING <nil>}
DEBUG [core]Channel Connectivity change to CONNECTING
WARN [core]grpc: addrConn.createTransport failed to connect to {"discovery.thethings.network:1900" "discovery.thethings.network:1900" <nil> 0 <nil>}. Err: connection error: desc = "transport: Error while dialing dial tcp: lookup tcp/1900\": getaddrinfow: The specified class was not found.". Reconnecting...
DEBUG [core]Subchannel Connectivity change to TRANSIENT_FAILURE
DEBUG [core]pickfirstBalancer: UpdateSubConnState: 0xc00062f7d0, {TRANSIENT_FAILURE connection error: desc = "transport: Error while dialing dial tcp: lookup tcp/1900\": getaddrinfow: The specified class was not found."}
DEBUG [core]Channel Connectivity change to TRANSIENT_FAILURE
DEBUG [core]Subchannel Connectivity change to CONNECTING
DEBUG [core]Subchannel picks a new address "\"discovery.thethings.network:1900\"" to connect
DEBUG [core]pickfirstBalancer: UpdateSubConnState: 0xc00062f7d0, {CONNECTING <nil>}
DEBUG [core]Channel Connectivity change to CONNECTING
WARN [core]grpc: addrConn.createTransport failed to connect to {"discovery.thethings.network:1900" "discovery.thethings.network:1900" <nil> 0 <nil>}. Err: connection error: desc = "transport: Error while dialing dial tcp: lookup tcp/1900\": getaddrinfow: The specified class was not found.". Reconnecting...
DEBUG [core]Subchannel Connectivity change to TRANSIENT_FAILURE
DEBUG [core]pickfirstBalancer: UpdateSubConnState: 0xc00062f7d0, {TRANSIENT_FAILURE connection error: desc = "transport: Error while dialing dial tcp: lookup tcp/1900\": getaddrinfow: The specified class was not found."}
DEBUG [core]Channel Connectivity change to TRANSIENT_FAILURE
DEBUG [core]Subchannel Connectivity change to CONNECTING
DEBUG [core]Subchannel picks a new address "\"discovery.thethings.network:1900\"" to connect
DEBUG [core]pickfirstBalancer: UpdateSubConnState: 0xc00062f7d0, {CONNECTING <nil>}
DEBUG [core]Channel Connectivity change to CONNECTING
WARN [core]grpc: addrConn.createTransport failed to connect to {"discovery.thethings.network:1900" "discovery.thethings.network:1900" <nil> 0 <nil>}. Err: connection error: desc = "transport: Error while dialing dial tcp: lookup tcp/1900\": getaddrinfow: The specified class was not found.". Reconnecting...
DEBUG [core]Subchannel Connectivity change to TRANSIENT_FAILURE
DEBUG [core]pickfirstBalancer: UpdateSubConnState: 0xc00062f7d0, {TRANSIENT_FAILURE connection error: desc = "transport: Error while dialing dial tcp: lookup tcp/1900\": getaddrinfow: The specified class was not found."}
DEBUG [core]Channel Connectivity change to TRANSIENT_FAILURE
DEBUG [core]Subchannel Connectivity change to CONNECTING
DEBUG [core]Subchannel picks a new address "\"discovery.thethings.network:1900\"" to connect
DEBUG [core]pickfirstBalancer: UpdateSubConnState: 0xc00062f7d0, {CONNECTING <nil>}
DEBUG [core]Channel Connectivity change to CONNECTING
WARN [core]grpc: addrConn.createTransport failed to connect to {"discovery.thethings.network:1900" "discovery.thethings.network:1900" <nil> 0 <nil>}. Err: connection error: desc = "transport: Error while dialing dial tcp: lookup tcp/1900\": getaddrinfow: The specified class was not found.". Reconnecting...
DEBUG [core]Subchannel Connectivity change to TRANSIENT_FAILURE
DEBUG [core]pickfirstBalancer: UpdateSubConnState: 0xc00062f7d0, {TRANSIENT_FAILURE connection error: desc = "transport: Error while dialing dial tcp: lookup tcp/1900\": getaddrinfow: The specified class was not found."}
DEBUG [core]Channel Connectivity change to TRANSIENT_FAILURE
DEBUG [core]Subchannel Connectivity change to CONNECTING
DEBUG [core]Subchannel picks a new address "\"discovery.thethings.network:1900\"" to connect
DEBUG [core]pickfirstBalancer: UpdateSubConnState: 0xc00062f7d0, {CONNECTING <nil>}
DEBUG [core]Channel Connectivity change to CONNECTING
WARN [core]grpc: addrConn.createTransport failed to connect to {"discovery.thethings.network:1900" "discovery.thethings.network:1900" <nil> 0 <nil>}. Err: connection error: desc = "transport: Error while dialing dial tcp: lookup tcp/1900\": getaddrinfow: The specified class was not found.". Reconnecting...
DEBUG [core]Subchannel Connectivity change to TRANSIENT_FAILURE
DEBUG [core]pickfirstBalancer: UpdateSubConnState: 0xc00062f7d0, {TRANSIENT_FAILURE connection error: desc = "transport: Error while dialing dial tcp: lookup tcp/1900\": getaddrinfow: The specified class was not found."}
DEBUG [core]Channel Connectivity change to TRANSIENT_FAILURE
What is wrong?
Port 1900 is blocked?
Use
TTNV2_DISCOVERY_SERVER_ADDRESS=discover.thethingsnetwork.org:1900
Is it possible to use this strategy (i.e. changing the AppKey) to move a device from between applications on the v3 stack? Or for that matter on the v2 stack?
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?
I was just talking to @Jeff-UK on exactly that issue as he’s ended up with some devices that won’t move over as there are still v2 gateways around them and I’m sure I’ll be hit with that issue too.
I’m trying out the CLI to see if we can alter the AppKey from there - if not, we’ll be petitioning TTI to allow AppKey edits on the console.
The plus point of the conversation is that the last seen timestamp and the fcnt is available for a device using the CLI so we can at least tell which devices are still alive.
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.
I cannot change the app key because now everything is readonly in v2.
any workaround here?
AppKey should still be updatable. In the device settings page you can change it and save. (The save button is grayed out if you haven’t changed any values yet)