Chart for dashboard

[lqdung95ntp]

Hi, Thank you for your great work on developing a dashboard for mqtt communication. I want to view data in time series so I wonder how can I add a chart in this dashboard?

Thanks, LqDung

[adrianromero]

Hello

Actually the current version support simple charts. For example the following dashboard JSX:

<DashboardPage title="Chart example">
  <Card title="Sets chart data">
    <InputUnit
      topic="myhelloiot/chartexample"
    />   
  </Card>
  <Card title="Chart">
    <ViewUnit
      topic="myhelloiot/chartexample"
      format={ChartIconFormat({
        style: {
          data: {
            fill: "#0019ac66",
            stroke: "#0019ac",
            strokeWidth: 2,
            strokeLinecap: "round"
          },
        },
        domain: { y: [0, 100] }
      })}
    />     
  </Card>
</DashboardPage>

Generates the following dashboard:

Note the MQTT message value must be an array with the values data like: [10,20,50,30,80,10,20]

The chart uses the VictoryArea component from the Victory JS chart library and the ChartIconFormat properties style and domain of this component.

[mhaberler]

that rests on the assumption you can get a history window from the broker - typically you'd be getting just discrete value updates and I do not see an easy way to coerce brokers to provide such a history without server-side coding

A more flexible way would be to have something like a ViewHistoryUnit which can accumulate updates into a history window and pass that history to the sibling components on change

a ViewHistoryUnit would be different from ViewUnit as follows:

• there's a history which is a timeseries (arrival time, values), possibly limited in time or length
• it's subconvert method receives the current message with arrival time, and the current history as parameter to decide if the current value should be added to the history or not
• since history is timestamped comparison with current time can be used as a rate limiter

the format=iconFormat scheme actually could remain as-is

this covers a lot of cases like

• timeseries display like mentioned above
• map with a track history
• in the case of history size 1 usage as a rate limiter device

it would also the locus for making the history survive a reload, like saving inot localStorage and loading on init

the ConvertBuffertype should probably extended to accept optional extra parameters like the history

I'll give the idea a try