Personally, on a positive note, I think the V3 console is a nice improvement with a fresh new look. I can edit application/device attributes now, this wasn’t possible in the V2 console and I didn’t realise the potential of these attributes until I saw them in the V3 console. So in general I’m happy with it, with only a few nitpicks, which have all been identified by others too in this thread.
5 Likes
Another thing in V3 that is more complicated than in V2 is the security keys/tokens. In V2 there was a single Application Key which was used for MQTT and sending downlinks via HTTP webhook. And this key was always available in plaintext after logging in and going to your application.
On V3 one can have multiple keys with multiple permissions. From a security perspective this is good, but for newcomers that don’t understand all the different “scopes” of permission, this is very complicated. Even I do not always know what all the scopes mean, and which I really need for what.
Another security improvement in V3 is that a key can only be viewed directly after it was created, never again after that. This might be unexpected for many users, and other users (like me) may end up creating hundreds of keys during development, forgetting what older keys were used for, and being too scared to delete them as something might stop working.
A good compromise is what is done with the MQTT integration: There is a button one can click to create a new key with the correct scope. This definitely makes things easier, but it makes the problem of forgetting what keys are used where more difficult. I would however like to see this same feature everywhere else a token/key is required in the UI (gateways).
This could be improved by adding pre-configured roles. Each role defines a set of permissions. By only having to select a role, the process of selecting permissions will be simplified and more clear.
Of course the possibility to select permissions individually should not be removed.
Additionally an option could be be added to define custom roles (at account and/or application level).
The Personal API Key covers all bases but obviously should never ever leak out of your personal network of computers.
I think key management is going to be problematic - for professional users I think it hits the right note in terms of keeping copies of your keys somewhere - I add them to my macOS Keychain so they are available on all my machines.
Certainly need bigger warnings / suggestions about looking after your keys - and not turning off access to your own applications by mistake!
I find this thread fascinating, on release of the V3 console I gave feedback and felt I was unfairly treated at the time by another forum member - interesting to see how this has progressed and to see the comments regards Live Data views.
But in general I would ask that before anyone posts with harsh words they should remember you are getting this entire service and resource for free - if there is a costs to you it is that TTI get to use our feedback/data to develop their paid for services, just because your not paying for this I can assure you someone else is - they balance the running cost with looking at how we use this amazing solution and I would think the forum content is a huge value.
If your running mission critical or full on commercial solutions you should consider the paid for TTI services, then you can request perfection - just a thought.
1 Like
on release of the V3 console I gave feedback and felt I was unfairly treated at the time by another forum member
That should indeed never be the case. It’s ok to have different opinions but we always insist that they are expressed respectfully. Next time please reach out to a moderator (or flag the post), who can then assess on a case-by-case basis.
If your running mission critical or full on commercial solutions you should consider the paid for TTI services, then you can request perfection - just a thought.
Our philosophy at TTI is that the enterprise/commercial solutions will have additional features compared to the The Things Network, because they target a different audience (and use cases).
That still means that the The Things Network should be really easy and intuitive to use. So in the context of this discussion, we do really appreciate the feedback here and as already mentioned by Kevin, many of these items are already in open issues. We are internally discussing bumping the priorities on things the community feels are important so keep the feedback coming… 
3 Likes
Hey all.
At the risk that I am somehow missing the obvious or sounding completely silly I would like to share my experience trying to get a Gateway and a Lilygo working in V3.
Please read this as informational and not as a rant.
I have basic TTN knowledge, I know how how to build my own nodes and flash them with Arduino or Platform.io and mess with the code a bit.
However I am by no means a pro but make that up with my google skills and a plenty of tips from the helpful people in this community.
The first part was actually easy. Getting into the new console and setting up the gateway that I have here for V3 took less than 5 minutes. It is a Lorrier LR2. From there I could easily register a new gateway and insert the address eu1.cloud.thethings.network.
Succes. The gateway now forwards to both V2 and V3. I did however have to check in the slack community to know if I can actually get away with this or that I cause strange side effects. @jpmeijers was able to tell me that this is ok. This is not documented it seems so if anyone finds this thread: Yes it is ok to configure a poly packet forwarder to forward to both backends at the same time:
I also have a working setup for pax counter in Visual Studio Code so I thought it would be a good time now to reflash a Lilygo by just changing the parameters from a node that I have already working in V2.
Next step, register a node in the console.
Click applications, and then
Now I’m slightly lost because what do I put here?
The docs didn’t really help me here so I just an Application ID that described my node “lily1-v3” and as Application name I choose “TTN Mapper” because that is what I want to do with it.
After pressing “Create application” I soon realised this was a mistake because in the next screen I should now add a node “Add end device” but I already named the Application ID with the name of my node.
No problem, just rename the Application ID, right? Not possible.
Go back, delete the application and just start a new one. Delete is not possiblele or I cannot find it. I guess this follows later.
Start again, create an application with an appropriate name “ttn-mappers”.
Now the rabbit hole begins.
A dropdown! Nice.
I click it and the list is long with brands that I never heard of which if fine but sadly no TTGO or anything like that.
I go for “Other…” and am linked to the manual config where the rabbit hole deepens.
For testing and dev I really like ABP without frame checks but I’ve also read that this is not the preferred way and since the pax counter project is actually working quite well I selected OTAA.
Next I am greeted with a choice that I didn’t know existed. Choose your LoRaWan version.
But wait! There is help hover thingy.
“The LoRaWAN version for your end device should be provided by the manufacturer in a datasheet”.
It is at this point that I decide that I do not have all day to go find the datasheets and dig through them hoping that I find the desired version. It is not like I’m configuring lithium batteries that will set my house on fire if choose a wrong parameter so I choose the highest one in the hope that my Lilygo board is advanced enough.
The Application Server address and the Join Server address are refilled so I press Start.
I choose ttgo-v3-1 for End device ID
Now what? There is no button next to the JoinEUI so let’s look at the help pop-up/
???
Contact the manufacturer? No way, that cannot be the solution. Now what?
The docs have the solution:
In the section about OTAA scroll down a bit more and find this:
All zeros it is then.
Next hurdle, the DevEUI
No generate button. Help states: “Contact the manufacturer or reseller”.
I don’t think so.
I decided to make one myself my taking the DevEUI of one of my other nodes in the V2 console and change two of the numbers on the far right to make it unique.
xxxxxxxxxxxxFAFA into xxxxxxxxxxxxF9EA
Now it is unique - I hope 
Give it a name and go to the next screen.
“Regional Parameters version”
No idea and “Contact the manufacturer”
I just choose PHY V1.1 REV B for no other reason than that it looks better than REV A to me.
LoRTaWAN capabilities class B seems ok to me.
Next screen.
This one is easy, I can just generate keys here and press 
(don’t worry, I’m not actually using these keys in real life)
By the way, as a result of my testing for this I now have two End devices in this application without a way to delete one
Next step.
Go to visual studio code and insert the data in the sketch in loraconf.h
From the console I can easily copy DEVEUI end APPKEY.
But what to put in APPEUI?
I found earlier today in the docs (see above) that I can put all zeros there, or to quote @jpmeijers 
“AppEUI defaults to all 00’s on V3, where as on V2 it was generated from one of TTI’s EUI blocks”
Done. Upload sketch, observe result.]
No join but I do see a bunch of errors.
I am yet to figure out what is wrong here. by now it is dinner time.
I hope this is useful to anyone, maybe to improve the docs or for reference.
Any tips to me why I have no join now are welcome!
Please remember, if I sound n00b it is because I actually am
Obvious issue here is that @paulb chose “the highest lorawan version”, while we all know (no, in fact we don’t but I picked this up somewhere along the line) that we should use v1.0.2. I’ll assists @paulb in a direct message.
It is however interesting to see an old TTN user struggle to use the new console. The exact point of this forum topic.
2 Likes
No quarrel from me here on pretty much everything - it has gone from Spitfire to Flight Deck of Concorde - ie a few basic instruments to a few hundred dials.
If you view the “entity” as us software devs may call it, and go in to General Settings (the one half way down, right hand side, lest you choose the entity above in the hierarchy (ie, if looking at the Device, the left hand menu General Settings is actually for the Application), you will find a link in red that allows you to delete.
BIG HUGE WARNING:
If you delete a gateway or an application, you will NOT be able to reuse the ID due to database security restrictions. You can reuse the EUI.
I think the entering a device id where an application is being setup was a minor detour from reality as the same application → device hierarchy exists in v2 and it is a fundamental concept of LoRaWAN.
Things like which version of LoRaWAN, Join vs AppEUI, where to get one etc etc aren’t overly maker friendly. I have a stock of official EUI’s plus a random EUI generator from source code from this forum but it is a bit of a WTF moment that is almost unanswerable - putting all 00’s in just feels wrong. I’m not sure it makes any sense to ask for it for each & every device on an application, I’d not see a common use case where you want devices on an application to use different Join Servers - although some vendors do seem to provide unique AppEUI’s per device they ship - a bit of a waste.
As I have said on another thread where @clv has created a CLI script to add ABP devices, I have a couple of scripts in the works to ameliorate this and once I’ve got those up & running in the next week, we can all work on different devices profiles to make it a bit of a no-brainer.
Some of the suggestions mentioned in this thread are now available in the console:
- “last seen” timestamp in the device overview of an application (instead of “created”)
- the live data stream now has a “verbose stream” checkbox, showing either just a single-line (decoded) uplink message, or the full set of events
1 Like
Something I find annoying in the V3 console is that in the live stream, the information is truncated on the right side of the screen (when you don’t have a large one). I can browse the list vertically but not horizontally. I have the same problem when displaying the event details.
Is there a way to fix it?
It won’t be a huge improvement, but if you look bottom left and click …
Yes, it’s a little better if I hide the side bar but it doesn’t solve the problem. I still have the issue on long lines.
I see a bar under each line, that I suppose is there to scroll from left to right but it doesn’t work.
Actually this little bar under each lines works if you click very precisely on it… If you click just a little above or below, it is inefficient or opens the event details.
In the event details, however, there is no such bar to scroll from left to right (or I don’t see it…)
Even with higher res screens it can still be annoying.
IIRC correctly I have created an issue with feature request for implementing word wrap/line folding in the console. It was considered a luxury feature (they use a different name for it) and as far as I’m aware has not been planned to be implemented.
The only way to fix this is to have TTI add support for it in the TTS console.
For you maybe it won’t, for many others it will. Especially if you want to have other windows open on screen.
I prefer to be able to see things at a glance which is not possible when major part of the event details falls off the screen.
No idea what you think I’m referring to, but I’m talking about collapsing the left hand side menu which gets you a bit more space, but won’t be a huge improvement.
Ah sorry, my bad… 
(Must read better…)
1 Like
This is not true. We will be working on that as part of a general overhaul of event displays in the Console. This will take some time though.
“IIRC, … It was considered a luxury feature (they use a different name for it)”
To be more correct: the issue was labelled “goldplating”.
Goldplating commonly means nice to have or in other words low priority.
I should have added “yet” to be more clear.
I did not mean that it will not (ever) be implemented, but that it is not to be expected any soon.
The ‘Console Event Framework’ issue was first labeled with milestones ‘Next Up’ and ‘2021Q2’ which appears to have shifted to Q3 (which could possibly shift again).
I understand that implementing a new framework will take quite some efforts and time.
Looking forward to (and have to be patient for) the results. 
You could have your very own console design - see your PM’s