Watermeter history to graph on esphome-display?

I have an MQTT device on my home assistant that gets the value of my water meter. On my home assistant dashboard, I have a “Statistics graph Card” that shows me the last 12 days of the changes (value[n]-value[n-1]).
Some of the values from home assistant I show on my e-ink-display an ESPhome.
Now I saw that ESPhome also has a graph component and I wonder whether I can show a similar statistic of my water meter on my e-ink-display.

I tried like this:

graph:
  - id: waterUsage
    sensor: watermeter_value
    duration: 20h
    width: 150
    height: 50

sensor:
  - platform: homeassistant
    id: watermeter_value
    name: "Water Statistic"
    entity_id: sensor.watermeter_value

display:
  - platform: waveshare_epaper
    lambda: |
...
      it.graph(100, 100, id(waterUsage));

The current value of sensor.watermeter_value is 2630.2637

Unfortunately, only a single rectangle is shown on my display - what do I need to change? Did anyone implement something like that?

It is a very basic graph, it only shows points of data that came in while it was running. The graph has no history other than in memory. Let it sit for a while. Usually the datapoints are too rare to make anything useful out of it. It also does not interpolate between danapoints. So it looks more like a scatterplot than a graph.

This is why you should just read the documentation yourself and then you can be more informed and weed out bad and wrong answers.

No matter what your doing from gpio outputs to lcd displays, the first thing you should do is go look at the documentation to learn how to do whatever it is your doing or read through them to refresh your memory and check for updates in documentation.

If you use the bare minimum configuration and assume people commenting on here are correct then yes, youll have a pretty basic looking scatterplot graph that isnt very impressive looking.

If you instead just go read the documentation then you would quickly know that the lackluster scatterplot graph is just the default settings and you have lots of options to change the appearance, graph style, add colors, add multiple sensors, etc…

continuous (Optional): connects the individual points to make a continuous line. Defaults to false.

Simply changing “false” to “true” and you have a line graph instead of a scatterplot graph now.

Although that is somewhat true, you can change the time for how long it collects, stores, and then graphs the data. If you also keep in mind that its a 3$ esp board, not a 500Gb NAS and in no way meant to be used for saving and backing up large amounts of historical data then this seems more like a logical limitation than a deal breaking disappointment. You can always get creative and pull blocks of historical data from HA if its so crltical to have that feature.

Just read it…

They are still pretty basic graphs. Other options are to generate the graphs on HA and upload them to the esp once this is merged Add runtime online image support by guillempages · Pull Request #4710 · esphome/esphome · GitHub or to base your display on openhasp which can upload dynamic images.

That is a very long post to tell me I missed the continuous line option. The rest of it is not wrong. I’m pretty sure that continuous wasn’t there last time I looked - and I definitely read it more than once. Granted, I do not not read the docs again every day, but I do read all the release notes. I might have missed that announcement too, or it wasn’t mentioned.

The in memory bit isn’t somewhat true, it is totally true. It is on top of the docs you refer to. Setting how long does not make it less true.

So yeah, I make mistakes. Sorry for that. But I do not deserve this kind of verbal abuse.

That would be how to do it indeed, and it would make the graph way more useful. I know how to get it to the esp, but how do I do I get that data in the current graph? For rain forecasts I needed something similar, but I could not find any way to supply datapoints myself so I made my own (even more basic) graph. For long distance visibility I wanted a fill below the line, and that also was not an option I could find.

When using auto range, there’s no way in the current graph component to interpret the data for lack of a way to add labels to the axis, because you do not know the values needed. Not knowing the min/max will make small variations look like big changes. The grid lines may help a little, but not enough for my taste. These things make why I thought the graph was too basic for my needs at this time.

1 Like

Thank you for that clarification - I was assuming that it’s a “graph”, not a “collect sensor to memory and make a graph of that memory values” component. So, my misconception about that was, that I thought it gets the whole time series from a sensor - which would enable a much more flexible way of using it - the collection part of its functionality could have been implemented as another sensor, so that that collected data could have been used elsewhere, too.
I will have a look how I can create a single string on Home Assistant as a sensor value that I can then split on the esp32 to generate a simple graph with rectangles.

Well, it wasn’t personal and the purpose wasnt wasnt to attack you or tell you, you were wrong. I apologize if you took it personally, your comment stood out to me because it was inaccurate or arguably lacking more information.

I only meant to make the point that its in people’s best interest to take advantage of the docs and read them because you can get poor or even dangerous information from complete strangers online and that has 100% happened to me on more than 1 occasion. You would hope the reason is always well intentioned people but they’re just wrong and not malicious people purposely trying to cause chaos or damage but a person that doesnt use or know about the documentation has no chance of spotting the difference.

No matter the reason I argue the best option is people try official help sources first, thats all I meant and again it wasnt personal, it was just convenient for an example to my point but, again I apologize if it seemed over the line. My intentions were well meaning and to help.

On a side note…
I hadnt considered that you may have been answering based on older documentation that has since changed and improved. That definitely happens and for sure happens to me. Im definitely wrong sometimes too if im honest.

1 Like