What is the final date? for migration to V3.
No hard dates have been set yet. From the timelines mentioned during the conference think Q3.
I’m new to TTN, so I got my first gateway running and obviously I started directly with V3 to skip an upcoming migration. Is that OK or is it better to still register in V2?
If I understand correctly all your V3 applications will work just fine on your V3 gateway. I understand that if there is an existing community using V2 applications these packets will not be routed on the V3 (your gateway!) network at all. Maybe Jac or Johan could confirm.
The only instance this gateway migration will be a nuisance for me personally is the frame counter of an experimental application/node running over 31 months on a single LiFePO4 cell polling a BMP280 every fifteen minutes. Ideally I would like to see this device run for several more years but looking like there is an impending end to that experiment if I migrate my gateway?
G
yes, meanwhile I have a first temperature sensor running and also I receive the data in TTN V3. Next will to setup a proper application which stores the data, but that can wait some moe weeks. As far as I understood, V2 will be gone sooner or later, so probably your experiment will be g
I am trying to migrate my gateways from TTN v2 to V3.
Instructions at Adding Gateways | The Things Stack for LoRaWAN say I should add the gateway in TTS. However, this fails because the EUI is already being used (which it is, by me in my TTNv2!). Is this documentation correct or what is the correct procedure?
{
"code": 6,
"message": "error:pkg/identityserver/store:id_taken (ID already taken)",
"details": [
{
"@type": "type.googleapis.com/ttn.lorawan.v3.ErrorDetails",
"namespace": "pkg/identityserver/store",
"name": "id_taken",
"message_format": "ID already taken",
"correlation_id": "xxx",
"code": 6
}
],
"request_details": {
"url": "/users/xxx/gateways",
"method": "post",
"stack_component": "is"
}
}
That’s not what the error message says, it says the ID is already taken.
It doesn’t say the DevEUI is taken.
Also:
I deleted my device from ver2, then added it to ver3, get this message… any idea on how to fix it??
duplicate_identifiers
{
"code": 6,
"message": "error:pkg/networkserver/redis:duplicate_identifiers (duplicate identifiers)",
"details": [
{
"@type": "type.googleapis.com/ttn.lorawan.v3.ErrorDetails",
"namespace": "pkg/networkserver/redis",
"name": "duplicate_identifiers",
"message_format": "duplicate identifiers",
"correlation_id": "827238d53a7f436c8ce873d697d30837",
"code": 6
}
],
"request_details": {
"url": "/ns/applications/rsf1-otaa/devices/ws4a-6c-b0",
"method": "put",
"stack_component": "ns"
}
}
As I said above, duplicate identifiers - or possibly using a reserved word.
Have you used the Id before (note, NOT the EUI)
What is the Id you have used?
the device DEVEUI is hard coded in the device, can’t change
end device name, I have changed many times, same error
the end dev id, I have changed many times, same error
APPEUI is common to all my devices
APPKEYS is common to all my devices…
freq plan is USA TTN-2
class A
so for some reason my DEVEUI must be in never-never land in the V3 database, locking this device out
the error message is very vague, “duplicate identifiers” not stating what identifier(s) is the issue…
V3 is not ready for prime time if there is no way to fix this type of issue…
so I’m at a loss here on how to move this device to V3…
The Id of the device is the part YOU enter that’s up to you. As I said above, it is NOT the EUI of anything.
An id like descartes-amazing-device-01
.
It’s in the field marked End device ID
This does not allow certain obvious words or phrases like, for instance device
.
The DevEUI should be unique - so may be if you look past that you are focused on the wrong field, if someone accidentally registers your DevEUI in the database before you, that’s not the fault of the database. How do you propose it handle it differently?
The combination of DevEUI and AppEUI needs to be unique. A DevEUI can be registered multiple times without any issue.
Ah, OK.
All the more reason for it not to be blocking the registration using an EUI.
Although I also appear to have morphed it from a gateway to a device registration via a mixture of nomenclature. Or via the mention of device by the OP or the error message having OTAA in it. Or the OP did the morphing. Confused!
This morning I did a quick test, I change the DEVEUI in my hardware, re-loaded my code, add it to V3, no issue.
So, it appears that the DEVEUI is the issue, as the original DEVEUI come from a EUI64 chip from Microchip, it very unlikely that someone else is using this DEVEUI… so for some reason, the old DEVEUI was locked in the database without a way to delete it if it’s in my account… or verifying that it was in another account… It possible that it was locked in on a previous attempt to load the device in V3 using the EU1 system.
also, error messages like “duplicate identifiers” not stating what identifier(s) is the issue is not very helpful…
My Friend Alan Cooper has written a number of books on computer interface design, and his firm (now part of designit) teaches classes on how to design man-to-computer interfaces… as TTN grows, they might find a need to understand how to refine their interfaces to make them more user friendly…
I think there is still some uncertainty here - if it’s a gateway, it’s not the Device Id. Which gateway is it that comes with Microchip EUI silicon on board.
I’ve started compiling from the source code all the different error messages so I can track things down quicker. Unfortunately it appears to assign them to identifiers that don’t necessarily get used as expected so I’m still on the learning curve of the data structures.
If you want to get TTI’s attention for Alan Coopers works, you’ll have to file an issue on GitHub.
As TTN grows the community has more members that can lend a hand in working on the code base. If you look at contributors for V3 you will notice its very much the TTI team that works on it while then there are over 140 thousand users using the free service. May-be it is time some of them start contributing…
I looked at a few issues in autumn related to the UI as I thought I could help out with that side of things.
There’s no architectural documentation to really point the way and the UI side via a web browser requires detailed knowledge of JavaScript with the React library. It’s then transpiled by Babel over to a wider supported dialect of JavaScript which means the source doesn’t match up with the production code and often doesn’t look anything at all like the original code.
I can replicate most of the UI using the API’s, apart from the console log which uses Server Events to send messages to the web browser. There is no concept of CORS for SE. I’ve looked in detail at the code used for the console log and it’s beyond me, mostly as I don’t know React and mostly because my brain gets overheated when looking at such obtuse code. It doesn’t appear to actually invoke SE on the web browser so I can’t tell if they have found a way to make it move between domains or if React / Babel is just using a polyfill.
I did ask many months back about the state of the JavaScript SDK (more languages coming soon) as the single example provided doesn’t run. There are other parts that need addressing first, so I wasn’t able to get any pointers. This is one area I thought I could contribute but as above, I’m a bit without clue.
The use of Google’s Protocol Buffers and the subsequent compiling of API stubs from the definitions means getting in to the Go code has a learning requirement as well as the more technical techniques, which for those that code Go a lot I’m sure makes sense.
The only Open Source element of all of this is that it is published on GitHub. Everything else about contributing is theoretical.
Nope, it has a steep learning curve but it is certainly possible to contribute to the code.
However there are more ways to contribute:
- documentation
- examples
- creating issues on GitHub for improvements
- answer questions on the forum (with actual helpful answers, not me too’s)
@descartes you are well covered when it comes to contributing.
A post was merged into an existing topic: Unable to receive downlink messages from V3 application to V2 gateway