It says it can’t deliver the message. A possible cause is not explicitly having added all 8 channel frequencies (or any of the other required settings).
First: provide more details about your device and what you have done.
What is your region, EU 868MHz?
Have you followed all steps in " 1. Migrating a Few Devices", including adding all 8 channel frequencies?
Have you also copied the AppSKey from V2 and configured this in V3 device settings.
The AppSKey step is missing from the instructions in the OP.
Apparently you already have a gateway connected to V3, otherwise you would not see any traffic in the V3 console for a migrated ABP device.
It seems to be the case that always only 3 frequencies are saved also when I add more.
I can press save, but when I switch to different page and go back there are only 3 frequencies displayed.
What is the reason that changing Advanced setting later may/will not work?
The console gives the impression that it should work and allows these fields to be edited.
Can ‘may not work’ be fixed?
If not then why are these fields allowed to be edited in the console after the device has been added/registered?
Maybe @roman can give some details here, but as far as I know those settings are applied to new sessions of the device, not the existing session of the device. A new session starts with an OTAA join. In case of ABP, the LoRaWAN 1.1 ResetInd MAC command indicates that some session state was reset. And maybe it’s also triggered on an ABP frame counter reset if you’ve enabled those (don’t, it’s insecure).
@roman please confirm how this works exactly, then perhaps we can clarify this in the Console.
I’ve got a V2 device working with ABP, i’ve deleted from V2 console, then added to V3 console keeping the same DEVId, DEVADD, NWSKEY and APPSKEY, now on my gateway (still V2) i can see the traffic of the device, but on V3 console no data is displayed, what i’m doing wrong?
In my case devices are usually placed deep indoors, so i realized that there is the chance to setup the same device settings in TTN and EVERYNET… so i can receive data from my device in two different networks, that’s not posible with OTAA, and gives an “antenna diversity” that improves the chance of the device to communicate, and at the end my customers want “service”.
I understand the reasoning for choosing ABP. But my question is: Are you willing to accept that two LoRaWAN network servers talking back to your device? It could happen that the network servers are issuing conflicting commands to your end device that will disrupt the service that your customer expects. The architecture choice is not something to blame the network server for. If this was part of your risk assessment an you accept the risk it should be fine.
The classic one when servicing two networks (though perhaps not the case here) being both connections telling the node to change settings under ADR - with the poor node changing up and down the gears (SF & Tx pwr) based on which ADR command last seen…in worst case then the network with GW ‘closest’ in terms of best signal perhaps telling the node to go to SF7 (for example) and lower Tx power such that the other networks GW can no longer even hear the node and result is that ‘service’ failing totally!
Thank you for the feedback, i don’t use ADR, so these MAC commands are not sent by NS, fortunately the RX1 delay on both networks are now different and Rx2 SF too ( 9 for TTN and 12 for Everynet ) so that makes posible to receive MAC commands from both, concerning ADR, my app server chooses best network case to send donwlinks, and the device with the received RSSI tunes the uplink SF and power. i think that it is possible to work that way, thus improving the chance to communicate.
For ABP devices, apart from ResetInd, MAC state is reset on FCnt reset.
Since 3.11 we also have a Reset RPC (see ttn-lw-cli end-devices reset CLI command), which lets you reset an ABP device MAC state or forget OTAA device session in the Network Server.
Can I see ttn-lw-cli device get geocaching gc-10 --mac-settings.rx1-delay --mac-settings.desired-rx1-delay?
And what RX1 delay would you like to use on your device?
By default we use 5 - that requires a RxTimingSetupReq.
That’s actually not legitimate or workable, unless you’ve rigged things such that one of the networks is physically incapable of ever transmitting down to the node.
Otherwise, one will capture the downlink frame counter locking the other out, nevermind the confusion over MAC state.
Keep in mind that downlink support is mandatory with TTN V3, so if you’re going to try to feed two networks, then you must make sure the non-TTN network can never transmit.
fortunately the RX1 delay on both networks are now different and Rx2 SF too ( 9 for TTN and 12 for Everynet ) so that makes posible to receive MAC commands from both, concerning ADR, my app server chooses best network case to send donwlinks, and the device with the received RSSI tunes the uplink SF and power. i think that it is possible to work that way, thus improving the chance to communicate.
No, that is unworkable and should not even be attempted, as it will cause one or both networks to waste downlink capacity on housekeeping messages originated automatically and not by you.
TTN V3 makes it absolutely mandatory that your node support downlinks, and not be registered with anything else that has the capability to send them.
In simple terms, a LoRaWan network (be it TTN or something else) must have exclusive ownership of a node. The protocol simply will not work correctly otherwise.
As far as i know ( just few weeks with testing ), if i don’t setup ADR on Everynet , no downlink MAC commands are sent from , still haven’t been able to setup properly V3 ABP devices,… maybe too busy. The App downlinks are not a problem don’t you think so?
Of course i foresee the chance to have the same DevEui, AppKey registered on both networks, and try to join OTAA on both, an see what happens…
I think that commercial applications should have network server diversity, in my case, Spain, there is not country wide operator, and LORAWAN has strong competitors , let’s say NB-IOT, and the only way to compete with is to have the best network coverage as posible, being able to “roam” in different LORAWAN networks does make sense, i think that stacks should accommodate for this market need, and will thus leverage the use of LORAWAN.
They are most definitely a problem. LoRaWan tracks frame counters in both directions, so you can only have one network sending them, otherwise the downlink frame counter will get out of sequence.
TTN V3 sends downlinks, for its own housekeeping even if you do not request any. And it is mandatory that nodes support and honor those downlinks.
I think that commercial applications should have network server diversity
That’s your opinion, but the designers of LoRaWAN felt differently.
TTN is a LoRaWan network; it works according to the LoRaWAN spec.
And that spec is designed such that a node can only belong to ONE network.
If you want to register an ABP node on a different network, at minimum you’d have to first de-register it from TTN.
Of course i foresee the chance to have the same DevEui, AppKey registered on both networks, and try to join OTAA on both, an see what happens…
You’re not supposed to do that either; if both are in range, the join accepts would jam each other.
LoRaWan is not the only game in town; but it is the network type this forum is about.
