Sorry I don’t agree with you, you can use it in the browser, I just made it work 
It is not easy, because you can’t use EventSource object, you need to make a POST with special header. You have to mess with XMLHttpRequest progress message and split the messages yourself.
You can look at the following code : events.service.ts and ttn-sse.ts. In live at TtnConsoleAlternative
The filtering and the nice presentation is for later
OK clever clogs, go and make it work as per the Event Stream specification then.
I had got as far as figuring out that even TTI weren’t using the proper interface to ES in their React code.
I hope you realise that you have just volunteered yourself to fix all the console bugs in v3 as you clearly know React & TS and all the other 
I am that grumpy old programmer that’s not hip and with the new tech. The only framework I use is VanillaJS.
Any chance you can turn your code in to plain JS - that would be doing the universe a huge favour and give you mucho kudos amongst the OAPs.
While looking i found that there is an official JS SDK (what I didn’t know) and found that they use a better way to get events : fetch in : the sdk source
I wanted to try this fetch method so I made a quick and dirty sample here. Only js no fancy framework
I will ask my employer to send a quote
Yup, looked at that too, only had one example at the time and it didn’t work. I see there is still only one example. It helps if you know React, which isn’t me, I’m more a make it work for the next 10+ years sort of guy.
Brilliant, will have a go with that in the morning.
Well if he uses TTN for free, seems a small price to pay to have his favourite employee help out on bug fixes …
PS, if you want to see the side effects of 30 years at the coalface, see how I facilitated this: HTTP Integration with Perl - #4 by descartes
Still brilliant, a little bit of refactoring for understandability and I can look at implementing it.
Do rather wonder about the server loads if we all have our very own console-lite running with 24x7x365 (!) because it’s easier to read and convenient. Maybe a later edition of the API will allow us to subscribe to just the types we are interested in rather than receiving them and throwing them away. Or maybe a Console-lite API edition that only sends joins, uplinks & downlink related messages.
What is the main obstacle to NOT keep the existing console for existing devices and gateways and just prevent registering new ones?
Erm, none, that’s what read-only will be.
Beyond the no small matter of a, paying for the servers and b, supporting them. Whilst none of us pay for the servers or the staff.
So, by the end of the year we will have the v3 console which will run on servers we don’t pay for, supported by staff we don’t pay for.
When making a list also have a look at issues already reported in The Things Stack repository.
Issues that have already been fixed may be closed already but not yet rolled out. So it is useful to also check issues already closed.
Things that have previously been mentioned (IIRC):
I just checked an issue “add context sensitive help” that has been closed and was listed as implemented in the release rolled out yesterday.
Very disappointing to see that this has been implemented only half-baked. When adding an ABP device as a test many fields still don’t contain any help whatsoever.
Where is TTI in this discussion? I presume they are already processing all suggestions in to new releases?
Hey everyone! Thanks so much for all of your feedback. Threads like these are very valuable to us and I can assure you that we have been reading along very carefully and take this criticism and feedback very seriously.
EDIT: For any TTI core team members who read this thread remember:
- We are not beating up on you!
- We are not the enemy but are here to help and trying to make TTN/TTS/TTI better for all!
- This is to be a mechanism for reasoned positive contributions and explainations for why something might be wrong or open for improvement - not (just) to dump on you guys
Of course, this is understood as such and it makes me worried that apparently, we might have given the impression to frown feedback in the past (?).
I cannot comment on all points but can give more of a general response to the discussion so far.
Regarding device onboarding
We are aware of the UX issues with onboarding new devices and as a result already added the onboarding via the Device Repository. The coverage of the DR is already quite impressive but still far from complete. We’re confident though that it will further improve over the next months. The DR is however only one effort we took to improve the flow. We are also working on improving the manual device onboarding, which will shrink it down to a single form that is aimed to accommodate new users while still offering the flexibility to tackle advanced use cases as well (side note: this trade-off is basically the one defining challenge of the v3 Console). You can see the plan for this new onboarding form in this issue which also includes a wireframe that I designed in line with direct feedback that I got from V3 users.
It is currently actively being worked on the implementation and I expect this to land in the following weeks.
One thing to keep in mind with regards to v2 is that TTS supports significantly more end device functionality than v2 did, mainly due to the fact that almost all LoRaWAN specifications and device classes are now supported. With all this added functionality, configurability, and added use cases, it is not possible to keep the end device onboarding as straightforward as it was for v2. Our strategy here is to use sane defaults and also “canned solutions” (Device Repository) and contextual tooltips and hiding advanced settings initially. All of this will help to make the added complexity more digestible. Let me assure you that designing such form that covers all use-cases (ABP, OTAA, Multicast, LW versions, RPs, MAC settings, device class capabilities, external join servers, etc etc) but still stays simple enough for everyday use is not trivial which is also the reason why this is taking so long, but we’re getting there!
Regarding payload formatters
The relationship between end device and application level payload formatters is currently not clear enough. The biggest takeaway is that end device level formatters (exist and) take precedence. We have already tried to improve the communication around that fact in the Console, but there’s still room for improvement and a concept like device profiles is in consideration. I’ll take another look at that with the feedback from this thread.
Regarding event views
We are also aware of the current verbosity of the event stream in the Console. The reason this has not been fixed yet is that there are a variety of issues with the current event mechanic both technical and UX-wise, which need to be addressed holistically rather than by patchworking. You can see an overview on this in this issue.
Given the significance of this feature, we will reconsider adding some quick provisional mitigations that will make life easier for you in the short term.
Some direct comments
Not sure if I got this correctly, but the device overview will show a “Last seen” value. For this to be shown the device needs to have had an active session.
Within uplink events raw data, you should see in data.uplink_message.rx_metadata which gateways picked up the signal.
We had to start somewhere rather than delaying this further. New tooltips are coming up very soon.
Rest assured, we do ;). For many of the issues discussed here, we are already in the process of fixing or at least aware of and working on planning fixes. We’re a small team for the Console, doing everything from UX to implementation and also many issues are not as easily fixed as it might seem on first glance. This can sometimes mean that things are lying dormant for a while but we definitely track them and a thread like this will make sure we get the prioritization right.
Our action points to sum up:
I will make sure that we align our internal prioritization based on the feedback of this thread.
Once again: thanks to everybody for this valuable and constructive feedback. Please do not hesitate to word any other concerns or issues that you have with regards to the Console and also feel welcome to file issues in the TTS repository directly, or to search for existing issues and giving a thumb-up which also helps us with prioritizing.
Thanks for your feedback.
Be aware that for many (e.g. DIY / non-commercial) developers the device repository is useless during development because there are no matching devices in the repository.
On several places ‘sane defaults’ are not used at all, driving the user insane because so much has to be typed manually. Manually adding an ABP device is a very ‘good’ example of this:
If region and LoRaWAN spec are already known default values for RX 1 delay, all frequencies that need to be added etc. can be automatically be filled with default values if the users selects to add values for these options.
It’s this bit at the end we’d prefer a last seen or number of minutes/hours/days since last seen but as that would have to come from the hot data I understand that may not be possible.
The Created days ago is sort of meaningless and therefore UI clutter.
And even the professional ones too!
Yes, I was talking about the upcoming update.
Exactly, and this is precisely what we’ll add with the new manual onboarding. You can see that in the wireframes as well (page 13).
Ah ok, got it now. Yeah, we’re currently not showing this there since it means running a separate API call per end device. We’re also already doing that with gateways though, so we’ll look to update this here too.
Please keep this in mind next time you “force” the community to migrate from V2 to V3. There are many things on V3 which are not yet in a state to allow us to easily move over. Rather postpone the V2 sunset, sort out all the V3 issues, and when those are done, ask us again to migrate.
Architecturally speaking I’d want you to simplify the server workloads - I can run my own “what’s not called in for a while” query on my own infrastructure.
In the same respect, having access to a fire hydrant console view option is useful, but having a standard console show the ‘normal’ stuff to reduce load/traffic.
It is possible to have too much of a good thing and some elements are definitely in that domain.
What would help with new users is having to avoid the CLI - for generating the API key file, and the CUPS configuration etc.
Can these be added to the console as buttons?
I also feel that the V3 console is too complicated. The V2 console had some limitations but it was very easy to use. Looking at the V3 console, my feeling is that it has been designed by engineers for engineers but not for end-users like me (and yet, I am an engineer myself…). Hence, even though I really wish to give this new console a chance, I’m not sure I will use it any longer.
So you will be stopping using TTN?
Hi Kevin, thank you for your reply.
Please be aware that you can do so much good but if your audience does not know there is no benefit. Therefore I always advise “Be good at it, but tell it”.
Please put 1% of your and the teams time in communication with your biggest group of stakeholders. It will make the dust come down very rapidly so we can focus on the real topics.
Thanks in advance.
