In V2 console we could switch Activation Mode for devices, but after setting up a couple of devices is V3 (as OTAA) console it seems you cant switch anymore?
This is correct and is correct - ie, yes, you can’t change and that’s the way it’s intended.
Saw a post somewhere on there but there’s so much traffic at present I can’t quickly get it to hand
Thanks, I miss understood one of the instructions re taking a simple single device from V2 to V3.
Not sure if this helps in terms of simple OTAA device move steps…
- Create new OTAA device in V3, device ID/names can be different, as can application ID/names
- Important to then copy/paste the devices V2 DevEUI, AppEUI and AppKey values over to V3
- Once done save the new device in the V3 console
- Now restart the physical device to gain its V3 Device Address which is key to backend routing
- Once you see join request in V3 console and all looks good you can remove device from V2
2 Likes
This will only work when having (also) a V3 gateway and the device picks up up the join request from the V3 gateway first (instead of from a V2 gateway) as described here (also check replies).
If it picks up the join accept from a V2 gatewway first then it will start a session with V2 and traffic will be routed to the V2 environment and not V3.
I don’t think that’s true, my V2 gateways will forward device join requests to V3 and accept, they issue new device addresses, and this seems to be working, I thought that was the whole idea that you can migrate all devices to the V3 backed without any V3 gateways, then once all devices are migrated over you can look at moving over the gateways to the pointing to the V3 infrastructure
See below re my first V3 device, done as above - this is a full join via V2 gateway but processed by the V3 backend (note the uplink duplicate line and two join requests), that’s because I have two gateways here onsite)
To my (and some others’) understanding, if a device gets and accepts a join accept from a V2 gateway first it will setup a session with V2.
Traffic will be forwarded via the packetbroker from V2 to V3, but you can only have a session established with either V2 or V3(?).
I have tried this myself as described in the link in my previous post.
LoRaWAN keys and ID’s were exactly the same for the device in both V2 and V3 but traffic after the join accept only arrived at the V2 application, unless the device was explicitly joined via the V3 gateway.
Maybe @htdvisser can shine some light on this and explain what exactly happens and what does not happen with this combination of V2, V3, packet broker, session setup and any possible traffic filtering or prioritizing.
1 Like
Did you remove the V2 device after creating one in V3?
No I did not (not for those tests).
I cant test at the moment but it maybe the logic that if the credentials match in V2 then it performs the join request and issues a V2 device address etc, if the device doesn’t exist in V2 then V3 does the join accept and issues a V3 device address but all via the V2 gateway - I agree you can’t have both trying to compete so some logic must exist.
No need to test, that is exactly what happens. And it is designed to work this way to allow gradual migration (no big bang).
1 Like
That’s indeed the first part. After this, you need to make sure that V2 no longer accepts joins. You can do that by deleting the device from V2, but that would make your device stop working immediately. Instead, you can change the AppKey in the V2 console, so that new joins will no longer get accepted by V2, but the existing session is not deleted yet.
That “V3 Device Address” is indeed important for Packet Broker routing.
2 Likes