Closed andrewjswan closed 1 year ago
case MODE_GRAPH_SCREEN::
color_ = this->text_color; // or Graph Color or ...
this->config_->display->graph(0, 0, id(graph_component: single_temperature_graph), color_);
break;
I support the idea! What about multiple graphs? The identifiers for the difference are already there. As an example, show different sensors under different conditions. Can you still consider the option of an icon with a graph? By name, icon_graph is possible. So it will be possible to distinguish between graphs or some additional information to the graph
I think it is also not difficult to realize, not to bind one chart ID in ehmtxv2 configuration, but to declare in ESPHome the necessary charts, and when calling a service or API to specify the necessary chart ID.
show_graph =>{"graph_id", "lifetime", "screen_time"}
It is also possible to output it with an icon, but then it will be necessary to define the graph as 8x24 and pass the icon name when calling it.
show_graph =>{"iconanme", "graph_id", "lifetime", "screen_time"}
Like:
graph:
- id: single_temperature_graph
sensor: temp_outside
duration: 64h
border: false
width: 24 or 23
height: 8
line_thickness: 1
show_graph =>{"temp", "temp_outside", "5", "5"}
case MODE_ICON_GRAPH_SCREEN:
{
color_ = this->text_color; // or Graph Color or ...
this->config_->display->graph(8 or 9, 0, id(graph_component: single_temperature_graph), color_);
this->config_->display->line(8, 0, 8, 7, esphome::display::COLOR_OFF);
this->config_->display->image(0, 0, this->config_->icons[this->icon]);
}
break;
@lubeda In case I have time and make changes for Pull Request, which branch is the best to do it based on? main
? 2023.8
?
Hi, for me, the 2023.8 is the base for further development. There are some breaking changes between main and 2023.8 it makes no sense to put effort into the main branch.
But I think drawing only charts from internal sensors is the wrong way. Sensors from the host should also be possible.
I'm happy about every pull request, but I still will follow my "unwritten" design ideas.
But I think drawing only charts from internal sensors is the wrong way. Sensors from the host should also be possible.
In the example above, the sensor is from HA.
I'm happy about every pull request, but I still will follow my "unwritten" design ideas.
It's understandable, if my ideas are bad, I don't have many options, go the parallel way, or use it personally.
Hi @andrewjswan, your ideas aren't! You an trip5 are very creative in extending ehmtx to the next level. But e.g. in my use cases I like to display the rain forecast as graph. This data is only available on the host not on the ESP. Showing graphs "only" from the ESP is a step in the right direction, even perhaps the easiest way. Keep your creative up and share your ideas.
Hi @lubeda ! ESPHome supports displaying graphs both from internal ESPHome sensors only and from sensors that are only in the HA. I.e. we can display graphs from any sensor, both single and combined (several graphs in one). Or did I misunderstand you?
But e.g. in my use cases I like to display the rain forecast as graph.
You can do it, no problem. Declare the graph in the Esp, specify your sensor from HA in it, and display it. This is a simple way and it is not difficult to implement. A bit more complicated, add graphs as you did with icons, i.e. in a component, and just like icons display them on the display by their names. This is a bit more complicated.
I'm interested in deriving a barometric trend from the HA, and perhaps a temperature trend over a couple days. As it is done in the graph above (screenshot).
PS: I have more ideas, but I'm nurturing them for now. I have to deal with the current ones first, but I don't have enough knowledge of ESPHome, but I'll play around. But if they will be realized by you, and faster than me, it will not be a problem, I will get knowledge. And knowledge is Power! :)
@lubeda @andrewjswan Is it possible to split the graph into parts by colors? And is it possible to add a dim fill parameter of the display below the line? As an example in the screenshot
See the 2023.9.0 branch and the wiki. The line color isn't working yet
I moved the config, initially there was an error about "'duration' is a required option for [0].", the error disappeared when I added the parameter to graph. the sensor was taken from ha, after a while the graph begins to draw. But it feels like there is a void on the left (icon?) Is it possible to have multiple graphs with different displays? I also added the border: false parameter to remove the frame. It's just a pity that the schedule with a reboot starts at 0, which is what is written in the dock..
@malinovsku
As an example in the screenshot
Not with the esphome graph, this looks nice but is quite complex to implement
@malinovsku
Is it possible to have multiple graphs with different displays
For the moment, only the esphome graph
functionality is available
@malinovsku
Is it possible to have multiple graphs with different displays
For the moment, only the esphome
graph
functionality is available
there is a display_graph parameter in the config: ehmtx_graph, is it possible to exclude it and create several ehmtx_graph graphs, then call the desired service by the graph id?
See the 2023.9.0 branch and the wiki. The line color isn't working yet
It's a simple implementation, but it's still better to give the option to output multiple charts and graphs with an icon, but as an initial step, great!
Is it possible to split the graph into parts by colors?
ESPHome doesn't allow this yet, you have to open Issue in ESPHome, so far only one color per line.
It is necessary to pass to the function the identifier of the chart, and by this identifier to set the screen identifier, if you also pass the icon identifier, it will be a universal variant, the icon identifier is passed, display it, no, do not display it.
@lubeda break; missing in Graph - https://github.com/andrewjswan/EspHoMaTriXv2/commit/f592629db99f9e3aa587a50faac711f7c30ebdc8
For the full operation of the graph, it is not enough to get historical data from HA, at least for sensors from HA, internal sensors will be accumulative since it will be difficult to get history from HA. It is also necessary to make a list of charts, similar to Icons, and by the identifier of the chart to display the necessary one. And the size of the chart output (24 or 32) we can set on the fly.... And then we can output an icon.
The simplest implementation is the last one, i.e. add an icon, everything else requires modernization of EspHoMaTriXv2 and ESPHome.
@malinovsku Can you check? https://github.com/lubeda/EspHoMaTriXv2/pull/108
@malinovsku Can you check? #108
I called the graph_screen service and as soon as it reaches the graph display, the esp restarts and the initial logo appears
I called the graph_screen service and as soon as it reaches the graph display, the esp restarts and the initial logo appears
Hmmm, any Debug log?
I called the graph_screen service and as soon as it reaches the graph display, the esp restarts and the initial logo appears
Hmmm, any Debug log?
my mistake, the line in the display_graph component was commented out. The icon with the graph works well, thank you!
@lubeda @malinovsku I believe that the minimum functionality of displaying charts is done.
To display more than one graph, it is necessary to make a mechanism similar to Icon, i.e. transfer the graph declaration to EspHoMaTriXv2 component, limit the number of graphs to 5 graphs, and display them according to the need, similar to Icon.
This can be solved in this Issue, and we can open a new one. Or we can make these changes in the new EspHoMaTriXv2 model. https://github.com/lubeda/EspHoMaTriXv2/issues/96
I'll probably close the Issue for now, and when we move to a new mechanism for creating screens, I'll open a new one. Or when I'm ready to make changes similar to Icons.
Feature Request
Describe the solution / feature you'd like
Add a graph display screen, in the configuration we specify the graph, pass the graph ID to the EspHoMaTriXv2 component, and when needed, the user will call the graph screen display service, indicating its lifecycle and indicating the rebound time, perhaps another color. The graph will be displayed on the screen from time to time.
Additional context
API:
Service