Plot data card - for making custom graph #868

Danielhiversen · 2018-02-06T13:03:56Z

This will add a possibility for a component to make a custom graph. All components can provide a _plot_data dictionary as an attribute, and this will result in a custom graph in the frontend.

I am planing to use it in the backend like this: https://github.com/home-assistant/home-assistant/compare/tibber_plot?expand=1#diff-43f211c43ec818fda11c8afe6bab1ee5R95

This will allow the Tibber sensor to show the coming electricity prices, and not only the historic ones.
I guess other components could use this functionality too. And I already have an idea of adding another Tibber sensor, where this will be required.

(I have not done much frontend development, so hope to get some good feedback)

c727 · 2018-02-06T16:19:05Z

isn't it better to create a new domain for this?
I think we don't want to store tons of data in the state attributes so we will need an API for this
Since we want to replace Google charts maybe you can check the PR Replace Google Charts with Chart.js #429 by @fanthos and use this lib

Danielhiversen · 2018-02-06T18:40:25Z

isn't it better to create a new domain for this?

Maybe.

But from a backend perspective it feels strange to change the domain to use a different frontend card. I think it would be strange to have the Tibber sensor as something else than a sensor. We could also make it possible for the user to choose if (s)he wants a "normal" sensor where only the current state is shown or this new view with a graph. Then it would be strange if the domain changes according to this this. Then the entity_id will also change.

I think we don't want to store tons of data in the state attributes so we will need an API for this

Maybe we should have an api/refactoring such that the frontend cards can be chosen independently of the domain?

Since we want to replace Google charts maybe you can check the PR #429 by @fanthos and use this lib

Yes, when this pr is merged, the plot_data cards also needs to be updated

balloob · 2018-02-07T00:48:38Z

This data should not be stored in the state machine. We should get it from an API.

Cards are tied to a domain because of simplicity. If you want fancy stuff, use custom UI. It's otherwise unmaintainable for us as every card should be able to render every entity 🤔

Danielhiversen · 2018-02-07T09:55:50Z

i think this is such a generic feature, that it should be part of the official UI.

Ok, how can such an API be implemented? Do we have any examples?

(Btw, this is the same way we send forecast data to the frontend in the weather components)

c727 · 2018-02-07T13:23:46Z

I'm not sure if it's a good example but I did something similar here https://github.com/home-assistant/home-assistant/pull/11866/files

balloob · 2018-02-08T00:48:01Z

Would it make sense to allow the history component to make entities which show graphs for that entity ?

I also want to make sure that we do not merge this before we merge the chart.js PR #429. It's almost ready to go.

balloob · 2018-02-08T00:53:19Z

I would say that adding / removing history entities is a great use case to use the new Config Entries component home-assistant/core#12079 #861 (this example shows all that we need to do)

Danielhiversen · 2018-02-08T14:08:42Z

Would it make sense to allow the history component to make entities which show graphs for that entity ?

That could work. Then we have to accept future dates in the database. And the frontend should plot future dates if it exists.

c727 · 2018-02-08T17:01:12Z

I think we should keep this generic graph card separated from the history graph to make it more flexible.
Someone posted this in the forums yesterday, maybe we can adopt some good stuff
https://community.home-assistant.io/t/google-charts-state-card-for-home-assistant/42400

Danielhiversen · 2018-02-08T17:10:16Z

Yes. To use the history graph would work for my use case.
But I think we should have a generic graph card, that allow a backend component to generate a custom graph.

balloob · 2018-02-08T18:32:18Z

We should not get a generic graph card. We always tie all frontend stuff to specific components. We can reuse building blocks that we use to build cards but won't have one card serve multiple domains.

If you want other data than history data you will need a graph component, but how will platforms work for it? Maybe better for custom UI..

Danielhiversen · 2018-02-08T18:52:00Z

Ok, the history entities and using the history graph would work for my two use cases. But will we allow future dates to be added to database and visualized?

c727 · 2018-02-09T03:16:54Z

I thought about this again and have to agree that I see this more as a custom component/ custom UI because the data is not directly bound to a component and the data + source + preferred UI can be so different.

We have an open PR #850 (maybe we can get this in 0.63? ;)) for custom cards that can be used for this together with your card and component.

Maybe we can also bring some glamour to the cookbook again and add links to some cool custom stuff but maybe this should be discussed somewhere else

Danielhiversen · 2018-02-09T09:01:13Z

I have two use cases where I think this is required, and I think it should be part of the official code. For the electricity price in Tibber we are currently showing the current price and the previous prices. But the future prices are much more interesting, since they can be used for automation and planing of the heating/ electricity usage. (Use less electricity when the price is high).

So I think we should support that sensor components can provide data, that are shown as a graph in the frontend.

I see two issues with my proposed code:

How to send the data to the frontend?
The data array for plotting is send to the frontend as an attribute. This mean the data array are stored in the database, and easily may take a lot disk space. This is the same way we do it for the weather component, so I thought it would be ok. The benefits of add the data as an attribute, is that you can easily use it for automation.
One way to solve this, is to filter out all attributes starting with _ from the database. Then we can rename forecast in the weather component to _forecast. This will also allow to add useful data to the state for automations, but without having to store it in the database.
How to choose UI card?
To day this is based on the domain name, but I think it should be possible for a sensor component to set some kind of a flag to use the plot_data_card
I have proposed one method, to set such a flag. But there are probably better ways.
The other option is to make a new domain (sensor_plot ?), that inherent the sensor component in the backend and adds a plot_data attribute.

(This is an important feature for me, so I really hope we can find a way to add it to the main repo.)

balloob · 2018-02-09T21:54:35Z

The recorder is going to record everything. It is not going to pick and choose attributes. It's opening a can of worms. We need to fetch that data via an API. We also can't store future dates in the recorder. it's only recording events/states that happened in the system.
This is exactly what the history entity would be, it would point at an entity and plot that graph.

Danielhiversen · 2018-02-10T08:47:19Z

Ok, an API will be the solution to send the data to the frontend. Any plans to fix that for the weather components? How can we make the data available for automations (if we can not add them as an attribute)?
It seems to be of great use. But not for my case, where I need to show future dates. So I still need to a way to plot the data, and I think it would require a new frontend card.

balloob · 2018-02-18T06:34:48Z

Realized this already exists as history_graph

andrey-git

I think such switching cards by _plot_data attribute is a hack.

andrey-git · 2018-02-18T06:42:50Z

src/cards/ha-plot_data-card.html

+          clear: both;
+        }
+    </style>
+    <google-legacy-loader on-api-load='googleApiLoaded'></google-legacy-loader>


We have already switched to chartsjs

andrey-git · 2018-02-18T06:43:14Z

src/cards/ha-plot_data-card.html

+    <google-legacy-loader on-api-load='googleApiLoaded'></google-legacy-loader>
+    <ha-card header='[[computeTitle(stateObj)]]'>
+      <div class='content'>
+          <div class='attribution attribution'>[[stateObj.state]] [[stateObj.attributes.unit_of_measurement]]</div>


you have attribution twice

andrey-git · 2018-02-18T06:46:01Z

src/cards/ha-plot_data-card.html

+    <ha-card header='[[computeTitle(stateObj)]]'>
+      <div class='content'>
+          <div class='attribution attribution'>[[stateObj.state]] [[stateObj.attributes.unit_of_measurement]]</div>
+        <div id='chart_id' hidden$="[[!attr._plot_data]]"></div>


attr is not defined anywhere

Danielhiversen · 2018-02-19T15:49:01Z

@balloob
No, the history_graph is not useful for me.
It plots historic data from the database. But I want to plot future values not in the database.
I have a similar use case as the weather component, where I want to plot the future electricity prices.

@andrey-git
Thanks for your review. I know I have to update the code to use chartsjs.

I think such switching cards by _plot_data attribute is a hack.

Yeah, you are probably right. But do you have any better solution?
I have two issues I have to solve for this:

How to send the data to the frontend?
How to choose UI card?

More details in #868 (comment)

magnusoverli · 2018-02-26T07:55:14Z

Hi all!

I cannot contribute to the development of this, but I just wanted to let you know that the ability to pull future data on the electricity is a huge deal. It really is the difference between doing simple on/off automations and a more intelligent design.

Not sure I really understand the issues that have come up here, but couldn't´t this be solved by having another two sensor entities that always pulls data from 1 hour and 5 (as an example) into the future?

c727 · 2018-04-23T15:16:31Z

Let's close this PR. We no longer use Google charts and a solid implementation requires some more changes. Maybe you can discuss this in the architecture repo first

Daniel Høyer Iversen added 3 commits February 6, 2018 13:34

plot data card

d9af637

remove newlines

2ac0ba8

remove newlines

b23e1cb

homeassistant added the cla-signed label Feb 6, 2018

Daniel Høyer Iversen added 3 commits February 6, 2018 14:27

style

1f7dbc8

style

aa614e6

style

8170390

andrey-git requested changes Feb 18, 2018

View reviewed changes

Danielhiversen mentioned this pull request Feb 27, 2018

States with forecasts home-assistant/architecture#15

Closed

c727 closed this Apr 23, 2018

github-actions bot locked and limited conversation to collaborators Jul 8, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Plot data card - for making custom graph #868

Plot data card - for making custom graph #868

Danielhiversen commented Feb 6, 2018

c727 commented Feb 6, 2018 •

edited

Loading

Danielhiversen commented Feb 6, 2018 •

edited

Loading

balloob commented Feb 7, 2018

Danielhiversen commented Feb 7, 2018 •

edited

Loading

c727 commented Feb 7, 2018

balloob commented Feb 8, 2018

balloob commented Feb 8, 2018

Danielhiversen commented Feb 8, 2018 •

edited

Loading

c727 commented Feb 8, 2018 •

edited

Loading

Danielhiversen commented Feb 8, 2018

balloob commented Feb 8, 2018

Danielhiversen commented Feb 8, 2018

c727 commented Feb 9, 2018 •

edited

Loading

Danielhiversen commented Feb 9, 2018 •

edited

Loading

balloob commented Feb 9, 2018

Danielhiversen commented Feb 10, 2018

balloob commented Feb 18, 2018

andrey-git left a comment

andrey-git Feb 18, 2018

andrey-git Feb 18, 2018

andrey-git Feb 18, 2018

Danielhiversen commented Feb 19, 2018

magnusoverli commented Feb 26, 2018 •

edited

Loading

c727 commented Apr 23, 2018

Plot data card - for making custom graph #868

Plot data card - for making custom graph #868

Conversation

Danielhiversen commented Feb 6, 2018

c727 commented Feb 6, 2018 • edited Loading

Danielhiversen commented Feb 6, 2018 • edited Loading

balloob commented Feb 7, 2018

Danielhiversen commented Feb 7, 2018 • edited Loading

c727 commented Feb 7, 2018

balloob commented Feb 8, 2018

balloob commented Feb 8, 2018

Danielhiversen commented Feb 8, 2018 • edited Loading

c727 commented Feb 8, 2018 • edited Loading

Danielhiversen commented Feb 8, 2018

balloob commented Feb 8, 2018

Danielhiversen commented Feb 8, 2018

c727 commented Feb 9, 2018 • edited Loading

Danielhiversen commented Feb 9, 2018 • edited Loading

balloob commented Feb 9, 2018

Danielhiversen commented Feb 10, 2018

balloob commented Feb 18, 2018

andrey-git left a comment

Choose a reason for hiding this comment

andrey-git Feb 18, 2018

Choose a reason for hiding this comment

andrey-git Feb 18, 2018

Choose a reason for hiding this comment

andrey-git Feb 18, 2018

Choose a reason for hiding this comment

Danielhiversen commented Feb 19, 2018

magnusoverli commented Feb 26, 2018 • edited Loading

c727 commented Apr 23, 2018

c727 commented Feb 6, 2018 •

edited

Loading

Danielhiversen commented Feb 6, 2018 •

edited

Loading

Danielhiversen commented Feb 7, 2018 •

edited

Loading

Danielhiversen commented Feb 8, 2018 •

edited

Loading

c727 commented Feb 8, 2018 •

edited

Loading

c727 commented Feb 9, 2018 •

edited

Loading

Danielhiversen commented Feb 9, 2018 •

edited

Loading

magnusoverli commented Feb 26, 2018 •

edited

Loading