Chart: Add "timestamp" type for x-property

[joepavitt]

Description

• When recording some introduction tutorials for Dashboard, I found myself having to justify why an empty key meant that the x-value would then be a timestamp - it made no sense. So I stopped recording, and fixed it instead.
• It took some fiddling to account for the various states an existing chart could be in, but I think I've got the relevant defaults/backups setup correctly.
• Now, we have a "timestamp" type for the x-property, which follows the same convention as the "Inject" node.

This now means the config for a slider plugged straight into a chart looks like this:

Which reads far better.

• Adds E2E test for covering timestamp data in both new charts (where xAxisPropertyType defaults to timestamp, and legacy charts, where the xAxisPropertyType is still property, but the value is blank.

Related Issue(s)

No issue raised, was a frustration/confusion, and came straight in with the fix.

[m-schaeffler]

This is a good idea, but there is the risk of breaking existing Dashboard.
So please show this in the release note.

[joepavitt]

This is a good idea, but there is the risk of breaking existing Dashboard.
So please show this in the release note.

It will not break existing Dashboards, I've even added an E2E test in using a config from an older chart to make sure it doesn't. If you still choose the "key" type, but pass no "key", it will still fall back to a timestamp

[Steve-Mcl]

Is changing the default to msg.payload sane?

I am struggling to grasp why?

[joepavitt]

I think so, the first/easiest use case for a chart is to use a numerical value coming in via msg.payload (e.g. a slider) with the x-value being generated as a timestamp

[joepavitt]

Similarly, in a case where they have sensor data via MQTT, the payload may be a raw value, or an object, at which point msg.payload.sensor (or equivalent) is appropriate too.

[Steve-Mcl]

approved (with question)