[Bug] Dashboard widgets do not load latest time series values since upgrading to 3.6.1

[tomhaddad]

Describe the bug
If a dashboard contains a widget such as Device Admin Table, which is configured to show the latest time series values for a device, the latest values should load instantly when you load the dashboard. Since upgrading to Thingsboard 3.6.1, the dashboard will initially load with empty spaces where the telemetry values should be.

Eventually when realtime telemetry is pushed from the device, the values in the widget will populate. This was not previously an issue in 3.6.0, and after downgrading 3.6.1 -> 3.6.0 the dashboards are behaving as expected again.

This only seems to be an issue for the latest timeseries values, attributes load straight away.

The behaviour is replicable via the WebSocket API /api/ws/plugins/telemetry, using the same JSON object that is used by a widget. Looking at the initial response, the data.data.latest.TIME_SERIES values are all empty, for example:

"temperature": {
    "ts": 0,
    "value": ""
},

It might be useful to note that when viewing a device detail page, the "Latest Telemetry" tab loads instantly with all of the latest values, so I've only seen this to affect dashboards.

We are using Cassandra as the time series data store, and the ts_kv_latest_cf table seems to be correctly populated with the latest values. The Postgres ts_kv_dictionary / ts_kv_latest tables are both empty, which I think is to be expected with a hybrid database configuration, however is it possible that with version 3.6.1, the data is attempted to be fetched from Postgres, even when a Cassandra DB is used as the timeseries data store?

Server Environment

• EKS microservices
• Thingsboard v3.6.1 w/ hybrid database (Postgres + Cassandra)

To Reproduce
Steps to reproduce the behavior:

1. Ensure Thingsboard 3.6.1 is running
2. Create a dashboard with a "Device Admin Table" widget
3. Select an active Device as the data source
4. Add at least one column with a time series value
5. Save & refresh the page
6. Note that the timeseries value will be empty until telemetry is pushed from the device

Expected behavior
The table will load the latest values from each device, regardless of whether it is actively pushing telemetry.

Screenshots
Note the empty temperature/humidity value. Provisioned / active are attributes.

[zwoabier]

Any news on that? I see the exact same behavior in thingsboard 3.6.3
Device admin tables do not show values anymore until you wait that a new telemetry message is coming in, it does not fetch historical values anymore.

[tomhaddad]

We are now using 3.6.3 and still seeing the same issue. I can confirm that the dashboard is attempting to load the latest values from the ts_kv_latest Postgres table, even though we have set:

DATABASE_TS_TYPE=cassandra
DATABASE_TS_LATEST_TYPE=cassandra

The latest values are correctly writing to Cassandra, and I can see them in the database. As mentioned in the issue, if I load the "Latest Timeseries" tab on an individual device page, I see all of the latest values from Cassandra straight away, so this issue seems to be centralized around how the dashboards are loading data.

@ashvayka @vvlladd28 could you assist with this? Are we missing some configuration that was introduced in 3.6.1?

[mykhailokornieiev]

Hi

If you are using hybrid deployment, for optimal performance and reliability, keep database.ts_latest.type=sql so that latest telemetry is stored in your SQL database.

By default, ThingsBoard stores ts_kv_latest (latest telemetry) data in a SQL database such as PostgreSQL, similar to how attribute data is stored. This design choice is intentional because Cassandra is not well-suited for frequent overwrites, which is the nature of the latest telemetry data.
Cassandra is optimized for storing large volumes of historical time-series data, which are mostly appended rather than updated. The ts_kv_latest table, on the other hand, is constantly overwritten as devices send new latest values. Storing such frequently updated data in Cassandra can lead to significant performance degradation.
Database telemetry parameters
More details in the ThingsBoard documentation: Core/rule engine deployment parameters

Only if you explicitly need to store the latest telemetry in Cassandra (which is generally not recommended) should you change this setting and thoroughly test for any performance impact.

I closed this ticket due to inactivity. If this question is still relevant to you, feel free to open a new ticket with a full description of your request.