We recently launched version 2.0.0 of our backend, which is no longer compatible with v1-staging. You can configure your v1-staging ttnctl with ``–ttn-account-server https://v1.account.thethingsnetwork.org` to delete your old devices from v1-staging and move them to our v2 backend.
See Launching Production Environment for more information.
Pfoe that did the trick. Thanks!.
So we should start migrating. How long will the “old” staging environment be alive?
Maarten
As an aside: network providers (such as TTN) are required to actively block devices that always send on SF11 or SF12, to keep their LoRa Alliance NetID: Devices with fixed hardcoded data rates of SF12 or SF11 must not be allowed to join the network.
It’s not possible to register just any DevAdr, as it includes a network identifier:
The most significant 7 bits are used as network identifier (NwkID) to separate addresses of territorially overlapping networks of different network operators and to remedy roaming issues. The least significant 25 bits, the network address (NwkAddr) of the end-device, can be arbitrarily assigned by the network manager.
[…]
The seven LSB of the NetID are called NwkID and match the seven MSB of the short address of an end-device as described before.
The documentation on LoRaWAN Address Space explains some more:
The Things Network Foundation has received a 7-bit device address prefix from the LoRa Alliance. This means that all TTN device addresses will start with
0x26or0x27(although addresses that start with these might also belong to other networks with the same prefix). Within TTN, we assign device address prefixes to “regions” (for example, device addresses in theeuregion start with0x2601). Within a region, the NetworkServer is responsible for assigning device addresses. We are using prefixes here too for different device classes (for example, ABP devices in theeuregion start with0x26011) or to shard devices over different servers.
(TTN currently uses a NetID of 0x000013, hence its NwkID is the 7 bits binary %0010011. As hexadecimal 0x26 is binary %00100110, and 0x27 is %00100111, both indeed start with the 7 bits NwkID.)
@htdvisser wrote in Slack, about just copying some existing DevAdr into TTN Console:
No, that won’t be possible in the public network
We route data based on the NetID that was assigned to us by the LoRa Alliance
Devices with a DevAddr that does not match our NetID, are (according to the LoRaWAN spec) part of another network
If a manufacturer puts fixed DevAddr/NwkSKey/AppSKey in a device without giving the customer the ability to change those, they either don’t know what they’re doing or they don’t really care about the customer or they try to create some kind of lock-in to their own network.
And if if the NwkSKey/AppSKey is
2B7E151628AED2A6ABF7158809CF4F3CI would think twice before buying the device.
And about the test NetID 01/02:
We don’t issue DevAddresses for
00/01but it is possible to “force-register” a device with such address (not in the console, only withttnctl)For such devices, we can still route data
But uplink for anything else than
00/01/26/27will just be dropped before it’s even considered by the backendOr routed to a roaming partner when roaming is added to LoRaWAN and supported by us
Thanks for this info.
Is there somewhere a list of assignments NetID <-> LoRaWAN Network Provider?
@arjanvanb
Thank you for the helpful information. I have devices whose DevAddresses begin with 00. How can I force-register these devices over the ttnctl?
Thank you very much for your help!
ttnctl devices set my-device-id --override --dev-addr 00000000 --nwk-s-key 00000000000000000000000000000000 --app-s-key 00000000000000000000000000000000
As for currently enforcing this, @htdvisser wrote on Slack July 3rd:
But no, we’re indeed not enforcing it at the moment
It’s pretty difficult to detect (with certainty) that a device is hardcoded to SF11/SF12
Sure, we can “assume” it if a device with a good signal is transmitting on SF12
But in my opinion, we should first notify the owner before we start blocking a device
And we’re still working on this notification system
The TouchTag has a fixed DevAddr that starts with 16. When I register it and personalize it via ttnctl according to the console it is given a DevAddr that starts with 26. Whether or not I change that via ttnctl, the gateway traffic only shows transmissions from the DevAddr 16xxxxxx and in neither case does traffic show at the application level.
Does it seem possible that TTN would in the future accept traffic for a device with a fixed DevAddr that starts with 16? Would that require some kind of peering agreement? My guess would be that sensors with a fixed DevAddr would be cheaper to manufacture than ones where the user can alter the DevAddr. And for devices with a fixed DevAddr to need to be specifically manufactured for use only in a particular network would seem regrettably inefficient. But I may have a fundamental misunderstanding of the issue.
If the devaddr is fixed the node uses ABP (not the preferred activation mode), with OTAA the customer would be able to create an application with the (unique) id, register the nodes EUI and key and be in business.
Thanks! This is useful when migrating a device from TTN to a TTI instance or back.
Hi… I have similar problem with my sensor. The sensor that I have already with a prefix DeviceAddress (Address: B00XXXXXX), Application Session Key and Network Session Key. According to the manufacturer, the sensor is configured with ABP.
When I added the sensor to TTN using TTNCLI and force change the Device Address to the sensor Device Address, I couldn’t get the publish in TTN. The instruction that I used to change the Device Address
ttnctl devices set [device_id] --dev-addr [sensor_device_address] --handler-id ttn-handler-asia-se
As i’m using Asia server, I need to put the --handler-id, else there will be error in the process.
Is there any solution for this?
A DevAdrr that starts with B00 will never work with TTN, see the explanation above. You’ll need to reprogram the device to use the TTN-assigned DevAddr for ABP. Or make it use OTAA and configure TTN and the device to use the same values for DevEUI, AppEUI and AppKey.
Hi… Thank you for the feedback. Although the data is available in the gateway traffic, application level, the data can’t be shown in the application due to the network identifier?
Sorry, I don’t know how to explain better than already quoted from the documentation above:
…and as already quoted from Slack:
If you don’t believe it, then click on an item in the gateway traffic, to see that (in your case) TTN will not recognize this as traffic it needs to handle. For example, for a DevAddr starting with 14:
…and the “drop” along with the reason “no brokers” in:
The data can not be forwarded to any application because the address is not valid for TTN.
