Resolving Perspective Time Series Chart JSON Binding

Perspective Time Series Chart data follows a short path: the view requests a named query, the database returns grouped rows, the binding serializes those rows as JSON, and the component resolves each series against the returned field names. Here, the rows reach the component, but resolution stops at the timestamp field because the chart requires the case-sensitive key time. The query returns Time.

Where does the chart request stop?

Follow the packet from the component toward the database, then follow the result back. The displayed query output proves that the database can execute the statement and produce timestamp/value pairs. The component error occurs later, when the Time Series Chart interprets the JSON schema.

No address or port change corrects a case-sensitive field mismatch. Once the named query returns data through the configured connection, keep the investigation on the return payload and component settings. The proof for this stage is a successful named-query result containing both a timestamp field and Count.

Is the physical and database path already working?

Layer one first. A disconnected database path, invalid connection, or failed query produces no usable row set. That is different from a component that errors while receiving rows. Test the named query independently of the chart and confirm that the result includes records such as a timestamp paired with 759, 708, or another returned count.

Then inspect the binding result rather than only the SQL editor grid. A grid heading can hide serialization details, while the JSON object exposes the exact property name the component receives. Check the data type as well: the time field must arrive as a date/time value the binding can serialize for the chart, and the count field must remain numeric rather than becoming display-formatted text.

The check passes when the binding preview contains populated JSON rows with a timestamp and numeric count.

Does the timestamp key match the chart contract?

The required correction is case-sensitive: change the SQL alias from Time to time. JSON object keys preserve case, so Time and time are different properties. A parser looking for time does not fall back to a visually similar key.

SELECT timestamp(t_stamp) AS time,
       COUNT(DISTINCT Total_Good_Count) AS Count
FROM mes.group_table_d01
GROUP BY HOUR(t_stamp), Date(t_stamp)
ORDER BY Date(t_stamp), HOUR(t_stamp);

Save the query, refresh the binding, and inspect the first returned object. The key must appear exactly as time. That observation proves the schema correction before series configuration begins.

Does each hourly row carry the intended timestamp?

The sample contains hourly-looking records, but one row is stamped 2019-09-10 01:15:39 while surrounding rows are on the hour. The query groups by HOUR(t_stamp) and Date(t_stamp) but selects timestamp(t_stamp). That selected expression is not the grouping key, so an hourly group can expose a source-row timestamp instead of a canonical hour boundary.

This issue is separate from the case error. Lowercasing time lets the component parse the rows; it does not normalize grouped timestamps. Decide what the x-axis should represent:

Do not introduce a database-specific bucketing expression without checking the database documentation and the column type. The check passes when every row has one deliberate timestamp whose meaning matches the grouping rule.

Is the series mapped to the returned value?

Bind the named-query JSON to the chart's data property under the relevant series entry, then configure that series to consume the numeric field returned as Count. Field matching remains case-sensitive throughout the path. If the configuration names count while the row contains Count, the time coordinate can parse while the plotted value remains missing.

1. Run the named query and confirm that every row contains time and Count.
2. Apply the JSON-return binding to the intended data property.
3. Point the series value mapping at Count with identical capitalization.
4. Refresh the view and confirm that the component no longer enters an error state.
5. Compare several plotted points with their corresponding query rows.

Remember that COUNT(DISTINCT Total_Good_Count) counts distinct values of Total_Good_Count within each group. It does not automatically calculate produced pieces or the change in a cumulative counter. If the chart is meant to show hourly production, validate this aggregation against the process definition. The check passes when the plotted y-value for a selected timestamp equals the query's Count for that row.

How do you verify the complete data path?

Use a small time range that includes the visible 2019-09-09 to 2019-09-10 transition and the 01:15:39 record. This exposes ordering, date rollover, timestamp normalization, and value mapping in one test.

1. Execute the named query with the production binding parameters.
2. Verify chronological ordering across midnight.
3. Inspect the serialized rows for exact time and Count keys.
4. Confirm that time is serialized as a usable date/time value and Count as a number.
5. Open the Perspective view and compare the first, last, and one middle chart point with the query result.
6. Trigger the normal refresh path and verify that new or changed rows appear without a component error.

The end-to-end check passes only when the query row, JSON object, series mapping, plotted timestamp, and plotted value agree.

FAQ