After finally getting my hands on V3 console its a major improvement - congrats to all those who have worked on it. The live data feed whist very comprehensive could do with a few mods in my view as it feels like information overload.
Filtering is the top issue, I’ve seen discussion on github but that seems to have closed down so my question would be is filtering a missing feature? This could be built into the console functionality for example.
Also colour highlighting of key values would be very helpful, just one example if the FCnt value was say on a green background.
I am wondering if there is any option here for customising the live view data stream, perhaps some CSS we can edit to change the look and feel?
Just bouncing ideas around (if I’ve duplicated something let me know, I did search).
For the most part, my understanding is that the console is for quick debug; to really work with your data, you probably want to be routing things to a data platform of your choosing. For that matter, I end up doing a lot with tail and grep working on simple subscription logs…
In the console for a busy gateway it is useful to be able to filter an address and types of traffic (uplink/downlink/activation). Some sites have too much traffic to be able to find the information by just looking at the console.
V2 console has data filters and they are used to help diagnose issues, V3 console provides even more granular information (which is great) so filters would be very useful - a single uplink from one device can now involve 10+ lines in the live data window, without filtering application live data view will be pointless given the amount of data rushing past.
Also noted that V3 console live data seems to have a timeout, this is new and a bit frustrating.
Yes a filter for the Live Data feed would be very useful. Currently all events are shows, making it difficult to spot the actual uplink message with payload.
Are you looking at a device view or a gateway view?
I’m not meaning that there’s never a role for filtering a raw feed, but in general the console isn’t typically where you’d want to look for application-level device data. Especially you wouldn’t look at a gateway view, as the device data is still encrypted there.
In terms of debugging devices from a gateway feed also seeing others, one of the challenges for filtering is what you’d be looking for. Device address gets changed each join accept, and the code presenting a gateway view may not really have access to the information needed to turn that back into a Device EUI. That EUI is present in join requests, but then vanishes from the resulting packets within a session…
When doing device development, hacking a packet forwarder or system it’s running on to twin the feed to a textual logfile you can grep might not be a bad idea.
You keep mentioning gateway view, no not yet, not even looked at moving gateways to V3 yet - this is simply about the device live data and application live data feeds.
Exactly what am I doing wrong that your not happy with?
It’s not hard this, the filters exist in V2 and I use them in diagnosing issues in both applications and devices (I’m guessing others do too), I just thought they would be of value in V3 given the information in the new live view is even greater.
You seems to be suggesting I am doing it wrong, I’m just using the live data to help me that’s all and I can see it being of no use once large numbers of devices populate an application - in fact the application live date view will be pointless without filtering as the data will volumes will be too high.
You’re indeed right, there isn’t much use for an “application” web view - as I was explaining earlier, you really should be routing your data into a data platform which you can query in whatever way you desire, and which will show you historic data in a way that the web view cannot.
Note that filtering out verbose events by default is a feature coming up in the next release which will be deployed shortly thereafter. It is a first step towards improving the usability of the event views in the Console (as in taming the firehose ).
Cool - your’s is Lego Technic - mine is very much Lego Duplo.
@kschiffer, assuming you are at the heart of the Matrix, can you explain the correlation ids please - what are they, how might we use them and more importantly, particularly for mobile apps, can we turn them off?
Cool - your’s is Lego Technic - mine is very much Lego Duplo.
Not sure if that is good or bad. You mean that you would like to have even less data displayed (even more data filtered out)?
Correlation IDs are, as the name suggests, IDs that allow you to link an event to other event based on a specific topic. E.g. for gateways, you’ll see a correlation ID for the connection, allowing you to identify all gateway events that are related to this particular gateway connection. Another topic would be e.g. an uplink. You will see that all gateway events relating to the same uplink will share the same correlation ID starting with gs:uplink:.
In the future we will use these IDs in the Console to highlight related events.
I’m not exactly sure what you mean by “turning them off”. If you mean to make the event stream omit the correlation IDs (or any other event property), then yes, something like this is in consideration.
Both - I like yours for the detail but when I’m running round the garden pouring water on to sensors, I’d rather have a really simple display that just shows me that an uplink was triggered which means the alarm was triggered. I’ve got something that replicates the v2 traffic view without the expanding detail working, just needs a bit more tidy up before beta-testing.
Plus mobile needs the bare minimum unless you have an A2 side iPad Air.
But when it gets gritty, return to “The Source” - the official console - what would be considered “The Truth”.
I’d not worry about the many variants of live data that people could aspire to - the API’s are there for people to roll their own and it means the wife is happy because I’m fully occupied.
Understand the correlation id’s now - very good - but mostly they are wasted bytes for the average console view - if I run out of things to do I could get some API feeds running and have different screens linking the entries via the correlation-ids - probably need to be a glass freestanding monitor with gesture control so I can swipe widgets around.
I see. Yeah indeed you’re always free to come up with your own interface that suits your specific needs (which is part of the power of TTS). Obviously though in the Console we try to come up with a design that suits as many needs as possible. As is known, we’re not quite there yet, but improvements will come in steadily now.
Btw, regarding mobile, the TTS Console is fully responsive and also the event views are optimized for mobile screensizes (obviously with some limitations). We will flesh this out further with the ability to hide columns as well, but it can already be used pretty smoothly (imho).
).