Ability to have Events appear as individual points on a time series graph

Hi

I would love the ability to have Events appear on a time series graph.

For instance tag an event with a property type (ie level).
A workflow raises an alarm based on hi level and creates a Event identifying level value as a property.

Then on the timeseries graph be able to display the event as a colored point/icon on the level graph and the time stamp of the event. Mouse over this and see the event summary.

This then allows you to see reportable activity on and in the context of time series data.

Cheers

Tim

Hi Tim,

I will definitely file these specs as a ticket but I’m not sure when it will get done. In the meantime you cant do all of this, but you could add a boolean field on the device that gets flagged whenever an event occurs. And then you can add it to an existing graph using a “bar” view.

Thanks,
Erin

Like this suggestion, add another vote from me

Hi

I could build this directly using the new custom charts.

What is missing on that front is the ability to perform a query on Events. We have device data queries and data table queries. Adding Event queries would make it pretty straight forward.

Could I change my feature request to add Event Queries to custom chart data sets ?
In the meantime I can write Events to a data table, but that is a bit redundant, especially if you want to query and discriminate Acknowledged, or Resolved Events.

Thanks

Tim

We actually already wrote up adding “Events” as a data source type for the custom chart as a result of your original request. It may take a couple release cycles but we should be able to get that out.

In the meantime, instead of pushing your events to a data table, you could write a GET experience endpoint and use it as a data source for the block, as in this Vega-Lite schema …

{
  "width": {{block.width}},
  "height": {{block.height}},
  "autosize": {
    "type": "fit",
    "contains": "padding"
  },
"description": "A simple bar chart pulling data from an experience endpoint",
  "data": {
    "url": "https://MY-EXPERIENCE-SLUG.onlosant./MY-GET-ENDPOINT?t={{block.time}}",
    "format": {
        "type": "json"
    }
  },
  "mark": "bar",
  "encoding": {
    "x": {"field": "time", "type": "temporal", "timeUnit": "minutes" },
    "y": {"field": "value", "type": "quantitative"}
  }
}

The inclusion of ?t={{block.time}} acts as a cache buster, and ensures that the data is re-fetched every time the dashboard’s refresh timer turns over.

In the workflow that handles the request, string together …

  • An Endpoint Trigger to kick things off
  • A Losant API Node to make an Events: Get request (you can filter these if you’d like, including using parameters on the endpoint that are backed by dashboard context)
  • Potentially some additional nodes to transform that data into a format you want to work with, such as numberifying different event levels or open / resolved statuses (you can also do this in the Vega-Lite config but it may be easier and more efficient to do it here)
  • An Endpoint Reply Node to respond to the request. The data should be an array of objects in JSON format

Excellent news.

The main problem I think I will face is we don’t use Experience Users (hence Experience Endpoint Authenication), all of our users are Losant users.
So the question that raises is how to authenicate against Experience endpoints for Real Losant Users.

You suggested an approach that was a bit complicated in a separate discussion.

Or am I missing something :wink:

T

Yes, that’s something I should have mentioned: Going the experience endpoint route, the endpoint would have to be public, as in unauthenticated against either Losant or experience users. Your dashboard can remain private and only available to Losant users, but anybody who got their hands on that experience URL could query the data you’re returning for that custom chart block. So consider that before taking this approach.

HI Dylan

Any chance Losant auth could be introduced for endpoint auth method in addition experience auth ?

T

It wouldn’t work in this case, because there’s no way to pass the credentials to the experience endpoint. The user isn’t entering a username and password anywhere on the dashboard, nor do you have any way of passing along their access token.