Custom Widget fetch data prior to "Maximum number of data by variable"

Hello,

New in tagoIO custom widgets here. I am trying to make a widget that shows data. As I understand with the “Maximum number of data by variable”, these max (latest) data are given to widget with onStart and ok we can get live data with the onRealtime.

In my case I am requested to create a custom widget that will plot data in the time period when user selects, meaning that might be prior to the given data initially. Which is the best way to achieve this? Bonus will be in case of large time ranges to reduce the frequency of data fetched to keep the sources allocation low - as other platforms do.

Hello @product,

You can achieve that by enabling the Dashboard Period Preset.
Once it’s activated, your widget will automatically receive data for the time range selected by the user on the dashboard.

You can find all the details on how to enable and configure it in our documentation:
:backhand_index_pointing_right: Dashboard Global Time Filter and Period Presets

Hello @gustavo.aguiar ,

Thank you very much for your reply! Unfortunately the Dashboard Period Preset doesn’t seem to 100% the solution, as user might need to see data behavior in large ranges. So the problem here is that he can only see the last “Maximum number of data by variable” number of values in the defined time range. Technically the only way to allow the user to achieve this is by sampling many times which is annoying for the end customer…

Is there any other way to solve this for large term data?

Hello @product,

When dealing with large time ranges and the limitation of “Maximum number of data by variable”, you have a couple of architectural approaches:

Option 1: Custom Backend + Custom Widget (Recommended)

This is the most robust solution for production environments:

  • Your custom widget makes requests to your own backend service (not directly to TagoIO)
  • Your backend receives the request with:
    • The RUN user’s token
    • Time range filters (datetime)
    • Any other necessary parameters
  • Your backend then:
    • Validates the user’s permissions
    • Makes the necessary API calls to TagoIO on behalf of the user
    • Implements data sampling/aggregation logic for large time ranges (e.g., averaging data points, reducing frequency)
    • Formats and optimizes the response before sending it back to the widget

Advantages:

  • Full control over data sampling and aggregation
  • Better security (tokens aren’t exposed in the frontend)
  • Can implement caching strategies
  • Optimizes resource allocation
  • More flexible for complex data transformations

Option 2: Direct API Calls from Widget

The widget makes requests directly to TagoIO API using the RUN user token:

Important considerations:

  • This approach has limitations and security concerns
  • Not recommended to expose Account Management (AM) permissions to any user making requests with the RUN user token
  • The RUN user token would be exposed in the browser, which is a security risk
  • Limited control over data sampling and optimization

Best regards!

1 Like

I’d like to add that you can remove those limits if you use a TagoDeploy instance. In the multi-tenant environment, there’s currently no native way to increase the amount of data a widget can retrieve in a single request, as doing so could overload our services.

That said, even with TagoDeploy, the recommended approach is to use aggregate queries in the widget. By aggregating—e.g., average/min/max per hour—you reduce the volume of data returned while still supporting user-selected time ranges, including periods outside the initial onStart payload.

If I do recall well, you can’t configure aggregate directly in the widget settings. You would need to use the API to edit the data JSON parameter of the widget and include the aggregate and function keys.

We’re working to improve the Custom Widgets API next year so you have more control over the data you fetch.