[FEATURE REQUEST] Add display icon + text + status bar

[malinovsku]

Describe the solution / feature you'd like

The idea of a new version of the display is "icon_status_bar", an icon with text and a bar status bar at the bottom, which is set by the parameter "percent_status_bar" and is counted as 4% per 1 pixel, the brightness of the next pixel is done incrementally, or completely fill the remaining ones with dim, the parameter "fill_rem". The color of the status bar is also configurable, but if not specified, then we take the text color (rgb).

New parameters:

percent_status_bar - the bar under the text, % of 100
fill_rem - fill the remaining part with dim
r_sb, g_sb, b_sb - colors of the status bar

API:

icon_status_bar => {"icon_name", "text", "percent_status_bar", "lifetime", "screen_time", "default_font", "fill_rem", "r", "g", "b", "r_sb", "g_sb", "b_sb"}

Service:

void icon_status_bar(std::string icon, std::string text, int percent_status_bar, int lifetime=D_LIFETIME, int screen_time=D_SCREEN_TIME,bool default_font=true, bool fill_rem=false, int r=C_RED, int g=C_GREEN, int b=C_BLUE,int r_sb=?, int g_sb=?, int b_sb=?);

Additional context

As an example of use, you can display the status of printing with a 3d printer and in the status bar % completed, and the text of the remaining time. For a timer that would clearly show the time ratio. Show completed cases and % of cases from all.

[andrewjswan]

Interesting alternative to Gauge, which can now be displayed only vertically, and will eat up less space on the left, and in my opinion more informative and convenient.

[lubeda]

Yes this would be nice but i have redesign the code before. I am planning a more object orientated design which will make also the screen identifier #83 thingy possible.

[andrewjswan]

Yes this would be nice but i have redesign the code before. I am planning a more object orientated design which will make also the screen identifier #83 thingy possible.

Can you give me an approximate time frame, I can make my proposed changes to 83.
I can also try to make an Icon with data display. But I would not like to disturb you, if everything will be well with my free time, I plan to do it today tomorrow.

[andrewjswan]

I made the changes (2023.09 based), but I need to check them since I did them in a regular editor on my phone (no access to a computer), I'll try to check for errors and typos today, build the firmware, upload it to the display.
If I don't notice any regression, I will do a Pull Request, only thing is that it will be one commit (sorry).

[malinovsku]

@andrewjswan thank you, I tested the screen, and so far I haven't noticed any problems. Is it possible as a suggestion to consider specifying a color for the strip? for example, by analogy with the id, through the sign | if an array of colors is specified, then we take it, if not, then as now from red to green.

[andrewjswan]

@malinovsku You can't use | because it's int, but I can suggest red to green and green to red, it's very easy to do. It is possible to specify one color for the whole progress, or an array of colors as it is done in Gauge, but it must be stored somewhere, and this is at least one Color or an array of Color[100], and it is necessary to make a separate call to specify the array or to specify the color.
I haven't found how to specify for HA this parameter is optional in the service registered in ESPHome.
Maybe @lubeda has some ideas.

[andrewjswan]

Progress in MODE_ICON_PROGRESS screen:

• 0 .. -100 - from Green to Red
• 0 .. 100 - from Red to Green
  d612744

[andrewjswan]

2023,9,1 Released ...

[lubeda]

I still don't like the +/- percent to determine the color and adding progress to the queue. The color must be a parameter and the progress (or even better percentage) must not be a "global" variable. Theses are all reasons to put effort into this #96.

But at last, the result on the display is nice and useful.

[andrewjswan]

The color must be a parameter

I think it is more convenient to set only a percentage, and get automatic color, rather than to set separately, r, g, b, in my opinion, we need to get away from the individual channel to an array of rgb.

I still don't like the +/- percent to determine the color and adding progress to the queue.

Me too, but it was the easiest option :)

[andrewjswan]

Is it possible as a suggestion to consider specifying a color for the strip?

I can add a function to set the color for the progress bar and background, ie by default colors will be Black, and then will work automatically calculate the color depending on the progress, if set colors, it will be filled with them.

[malinovsku]

setting the progress color also works fine, an example on the screenshot where the parts are of a different shade

[andrewjswan]

Complete... We can close. :)