HA ESP display

[Apd]

I've started a new thread topic because the other one was getting too
long and deeply nested for my liking. This display code should do what
you requested in MID: <uqnbn7$3q8ii$1...@dont-email.me>

The text for the actual temperature is always shown unless the target
bar is showing. When the bar for actual temperature is showing, the
last (current) block should flash if heating. Let me know if you'd
like a new gif image.


lambda: |-
auto swc = id(lhsw_cond).state;
auto hvc = id(hvac).state;
auto tgt = id(target).state;
auto act = id(actual).state;
auto colr = id(color_white);
auto box_x = 1;
auto box_y = 1;
auto box_h = 40;
auto box_w = it.get_width() - (box_x * 2);
auto temp_lo = 20;
auto temp_hi = 25;
auto bar_inc = int(box_w / (1 + temp_hi - temp_lo));
auto gap = 4;
auto bar_h = box_h - gap * 2;
auto stat = false;
auto heat = false;
auto show_temp = true;

if (swc != "unavailable") {
if (hvc == "idle") {
colr = id(color_green);
stat = true;
}
else if (hvc == "heating") {
colr = id(color_red);
stat = true;
heat = true;
}
}

it.rectangle(0, 0, it.get_width(), it.get_height(), id(color_gray));

//it.rectangle(box_x, box_y, box_w, box_h, id(color_gray));

for (auto last_x = 0; auto x = box_x + gap, i = temp_lo; i <= temp_hi; i++) {
if (i > int(act)) {
if (heat) {
it.filled_rectangle(last_x, box_y + gap, bar_inc - gap, bar_h, id(color_black));
it.image(last_x, box_y + gap, id(anim_blk), COLOR_ON, COLOR_OFF);
}
break;
}
it.filled_rectangle(x, box_y + gap, bar_inc - gap, bar_h, colr);
last_x = x;
x += bar_inc;
}

box_y += box_h + 10;
box_h = 80;
bar_h = box_h - gap * 2;

if (stat) {
//it.rectangle(box_x, box_y, box_w, box_h, id(color_gray));

for (auto x = box_x + gap, i = temp_lo; i <= temp_hi; i++) {
if (i > int(tgt)) break;
it.filled_rectangle(x, box_y + gap, bar_inc - gap, bar_h, colr);
x += bar_inc;
show_temp = false;
}
}

if (show_temp) {
it.printf(it.get_width()/2, box_y - 35, id(font_90), id(colr),
TextAlign::CENTER_HORIZONTAL, "%.1f°c", act);
}

[T i m]

On 17/02/2024 15:08, Apd wrote:
> I've started a new thread topic because the other one was getting too
> long

Agreed.

> and deeply nested for my liking.

I lost track of that ages ago! ;-)

> This display code should do what
> you requested in MID: <uqnbn7$3q8ii$1...@dont-email.me>
>
> The text for the actual temperature is always shown unless the target
> bar is showing. When the bar for actual temperature is showing, the
> last (current) block should flash if heating.

That sounds like the job.

> Let me know if you'd
> like a new gif image.

OK, thanks.

When I paste that I get:

'Couldn't find ID 'colr'. Please check you have defined an ID with that
name in your configuration. These IDs look similar: "color_red".'

If I ignore the IDE warning, save and run the validator I get:

- id: page11

Couldn't find ID 'colr'. Please check you have defined an ID with
that name in your configuration. These IDs look similar: "color_red".

Cheers, T i m

[Apd]

"T i m" wrote:
> 'Couldn't find ID 'colr'. Please check you have defined an ID with that
> name in your configuration. These IDs look similar: "color_red".'

Forgot to remove the "id" when I changed to the variable that already
is one.

Change this line:

it.printf(it.get_width()/2, box_y - 35, id(font_90), id(colr),

To this:

it.printf(it.get_width()/2, box_y - 35, id(font_90), colr,

[T i m]

Thanks.

That placates the IDE and validation but on compile it gives:

Compiling .pioenvs/lounge-thermostat/src/main.cpp.o
<unicode string>: In lambda function:
<unicode string>:578:49: error: expected ';' before ',' token
<unicode string>:578:49: error: expected primary-expression before ',' token
<unicode string>:578:51: error: 'i' was not declared in this scope
<unicode string>:578:62: error: expected ')' before ';' token
<unicode string>:578:64: error: 'i' was not declared in this scope
<unicode string>:578:64: note: suggested alternative: 'it'
*** [.pioenvs/lounge-thermostat/src/main.cpp.o] Error 1
========================= [FAILED] Took 12.17 seconds
=========================

Where line 578 is:

for (auto last_x = 0; auto x = box_x + gap, i = temp_lo; i <= temp_hi;
i++) {

Cheers, T i m

[Apd]

"T i m" wrote:
> Compiling .pioenvs/lounge-thermostat/src/main.cpp.o
> <unicode string>: In lambda function:
> <unicode string>:578:49: error: expected ';' before ',' token

> Where line 578 is:
> for (auto last_x = 0; auto x = box_x + gap, i = temp_lo; i <= temp_hi; i++) {

Sorry, used a semicolon after "0" when I should have used a comma and
had a redundant "auto". Should read like this:

for (auto last_x = 0, x = box_x + gap, i = temp_lo; i <= temp_hi; i++) {

[T i m]

That seems to have done the trick. ;-)

So far I've seen a green temp text display of 20.2 with one solid green
block on the actual with the actual temp of 19.1 (check).

I've seen the same when the stat is turned off (check).

I've seen two solid green blocks, one representing a target of 20.1 and
and actual of 20.8 (check).

And with the target set to 21.1 and actual of 20.8 I see two red target
blocks and one slightly different colour of red (and smaller) flashing
actual block. (check). ;-)

Now waiting for the temp to increase ... but so far so good!

<10 seconds later>

Bing, Two green actual and two green target blocks. (check)

Up the target one deg, 3 red target blocks two solid actual block tlc
and a flashing block in pos 3. (check)

Up to 3 of each green block. (check)

Turn off stat with Ikea remote, display turns white showing 22.6 and 3
actual blocks. (check)!

I've give that a RW run tomorrow morning but it's looking very nice so
far. ;-)

Cheers, T i m

p.s. I'm thinking I should set the increment on the stat to be 1.0 Deg
to match the Ikea remote as 1 Deg is a pretty tight increment compared
with most stats. As long as it starts / defaults to whole degrees, then
it should should stay that way?

[T i m]

On 17/02/2024 23:23, T i m wrote:

<snip>

> So far I've seen a green temp text display of 20.2 with one solid green
> block on the actual with the actual temp of 19.1 (check).
>
> I've seen the same when the stat is turned off (check).

But in white. ;-)

Cheers, T i m

[Apd]

"T i m" wrote:
> I've give that a RW run tomorrow morning but it's looking very nice so
> far. ;-)

Good stuff. I hope it's ok when the temp is not showing the bars.

> So far I've seen a green temp text display of 20.2 with one solid green
> block on the actual with the actual temp of 19.1 (check).

I don't follow. If the "actual" is 19.1, that's what it will show.

> p.s. I'm thinking I should set the increment on the stat to be 1.0 Deg to
> match the Ikea remote as 1 Deg is a pretty tight increment compared with
> most stats. As long as it starts / defaults to whole degrees, then it
> should should stay that way?

However you want. I can also remove the fractional part from the
displayed text but I don't think that's an improvement.

[T i m]

On 18/02/2024 12:25, Apd wrote:
> "T i m" wrote:
>> I've give that a RW run tomorrow morning but it's looking very nice so
>> far. ;-)
>
> Good stuff. I hope it's ok when the temp is not showing the bars.

It was indeed. ;-)

>
>> So far I've seen a green temp text display of 20.2 with one solid green
>> block on the actual with the actual temp of 19.1 (check).
>
> I don't follow. If the "actual" is 19.1, that's what it will show.

Sri, my bad, 'target temp of 19.1'.

>
>> p.s. I'm thinking I should set the increment on the stat to be 1.0 Deg to
>> match the Ikea remote as 1 Deg is a pretty tight increment compared with
>> most stats. As long as it starts / defaults to whole degrees, then it
>> should should stay that way?
>
> However you want.

I have done that and I'll check it out over the next few days but I
think it's looking more sensible (whilst 1 DegC is a fair step compared
with 1 DegF, I think it's sufficiently granular to be appropriate).

> I can also remove the fractional part from the
> displayed text but I don't think that's an improvement.
>

No, I don't think it would be as the factional does give you (those able
to comprehend it) which end of a range it's at.

Cheers, T i m

[T i m]

On 18/02/2024 12:25, Apd wrote:

Just an observation so far ....

Say the display is showing two green actual and two green target blocks
and you tweak the temp up by one degree, you then get the *second*
actual temp block flashing.

What I think might look batter (if it wasn't supposed to be this way
anyway) is with the target set to 22 (3 blocks) and the actual
previously indicating that it was 21 (two blocks), that you still get
the two solid red blocks and the 3rd actual block flashing, indicating
that's the one that's currently trying to complete?

Cheers, T i m

[Apd]

"T i m" wrote:
> Just an observation so far ....
>
> Say the display is showing two green actual and two green target blocks
> and you tweak the temp up by one degree, you then get the *second* actual
> temp block flashing.

That was the intention.

> What I think might look batter (if it wasn't supposed to be this way
> anyway) is with the target set to 22 (3 blocks) and the actual previously
> indicating that it was 21 (two blocks), that you still get the two solid
> red blocks and the 3rd actual block flashing, indicating that's the one
> that's currently trying to complete?

Ok. I'll think up some new code.

[T i m]

On 19/02/2024 17:51, Apd wrote:
> "T i m" wrote:
>> Just an observation so far ....
>>
>> Say the display is showing two green actual and two green target blocks
>> and you tweak the temp up by one degree, you then get the *second* actual
>> temp block flashing.
>
> That was the intention.

Ah, ok.

>
>> What I think might look batter (if it wasn't supposed to be this way
>> anyway) is with the target set to 22 (3 blocks) and the actual previously
>> indicating that it was 21 (two blocks), that you still get the two solid
>> red blocks and the 3rd actual block flashing, indicating that's the one
>> that's currently trying to complete?
>
> Ok. I'll think up some new code.
>

Hopefully it will just be adding 1 somewhere. ;-)

Cheers, T i m

[Apd]

Actually, removing code and I think this should do it. Replace the
first "for" code block which currently looks like this...

for (auto last_x = 0, x = box_x + gap, i = temp_lo; i <= temp_hi; i++) {

if (i > int(act)) {
if (heat) {
it.filled_rectangle(last_x, box_y + gap, bar_inc - gap, bar_h, id(color_black));
it.image(last_x, box_y + gap, id(anim_blk), COLOR_ON, COLOR_OFF);
}
break;
}
it.filled_rectangle(x, box_y + gap, bar_inc - gap, bar_h, colr);
last_x = x;
x += bar_inc;
}

with this:

for (auto x = box_x + gap, i = temp_lo; i <= temp_hi; i++) {

if (i > int(act)) {
if (heat) {

it.image(x, box_y + gap, id(anim_blk), COLOR_ON, COLOR_OFF);

}
break;
}
it.filled_rectangle(x, box_y + gap, bar_inc - gap, bar_h, colr);

x += bar_inc;
}

[T i m]

I believe I've done that but we don't seem to have the flashing square now?

- id: page11

for (auto x = box_x + gap, i = temp_lo; i <= temp_hi; i++) {
if (i > int(act)) {
if (heat) {
it.image(x, box_y + gap, id(anim_blk), COLOR_ON,
COLOR_OFF);
}
break;
}
it.filled_rectangle(x, box_y + gap, bar_inc - gap, bar_h,
colr);
x += bar_inc;
}

box_y += box_h + 10;
box_h = 80;
bar_h = box_h - gap * 2;

if (stat) {
//it.rectangle(box_x, box_y, box_w, box_h, id(color_gray));

for (auto x = box_x + gap, i = temp_lo; i <= temp_hi; i++) {

if (i > int(tgt)) break;

it.filled_rectangle(x, box_y + gap, bar_inc - gap, bar_h,
colr);
x += bar_inc;

show_temp = false;
}
}

if (show_temp) {

it.printf(it.get_width()/2, box_y - 35, id(font_90), colr,

TextAlign::CENTER_HORIZONTAL, "%.1f°c", act);
}

Cheers, T i m

[Apd]

"T i m" wrote:

> On 19/02/2024 21:51, Apd wrote:
>> Actually, removing code and I think this should do it.

[...]

> I believe I've done that but we don't seem to have the flashing square
> now?

You made the change correctly. Have you changed anything else in the
file? It should work. I need more info. How many blocks show and at
what temps when it's heating?

[T i m]

Morning mate,

I'm not quite sure what happened last night or what I was looking at at
the time but it now seems to be working (when I came down, I've not
touched anything etc), at least afa the flashing square is concerned.

I'm just waiting for the room temperature to catch up to the target ...

Cheers, T i m

[T i m]

Which it's just done (21 DegC) and it seems to be working fine now
thanks (sorry for the / my glitch).

I just need to tweak the size of the square and maybe ask you to change
the colour to match the rest, or make it something contrasting like orange?

I just happened to be looking at the display as it went into idle mode.

What I had was two solid target bars and one solid actual square and the
flashing one.

As it got to temp the second actual went solid and I got a brief flash
of the 3rd actual square before all 4 went green.

That could be the 'flash' function still completing even after the code
had gone into idle but then wouldn't that have still been on pos 2?

Not as biggie of course and happy to leave it as-is but I just mentioned
it in case you were interested in tidying it up etc? In this scenario
it's hardly noticeable (and likely wouldn't be noticed at all by the
Mrs) but if we were to use the same routine for something similar, it
might be etc.

Cheers, T i m

[Apd]

"T i m" wrote:
> On 20/02/2024 08:15, T i m wrote:
>> I'm just waiting for the room temperature to catch up to the target ...
>>
> Which it's just done (21 DegC) and it seems to be working fine now thanks
> (sorry for the / my glitch).
>
> I just need to tweak the size of the square and maybe ask you to change
> the colour to match the rest, or make it something contrasting like
> orange?

Here's a couple:
https://i.ibb.co/Wk8g5JW/block-red.gif
https://i.ibb.co/CVdXTq5/block-orange.gif

Remember to change the filename in the "animation" entry.

> I just happened to be looking at the display as it went into idle mode.
>
> What I had was two solid target bars and one solid actual square and the
> flashing one.
>
> As it got to temp the second actual went solid and I got a brief flash of
> the 3rd actual square before all 4 went green.

From two to four and the target was 2? That can't be right.

> That could be the 'flash' function still completing even after the code
> had gone into idle but then wouldn't that have still been on pos 2?

I don't follow. If the target was 2, and 1 was solid and 2 was
flashing, then 2 would have gone solid when idle (up to temp).

If 1 & 2 were solid and 3 was flashing, then 3 would have gone from
flashing to solid.

Did the number of solid bars when up to temp reflect the temp as shown
by the text?

Please clarify or do another check.

[T i m]

On 20/02/2024 12:48, Apd wrote:

> Here's a couple:
> https://i.ibb.co/Wk8g5JW/block-red.gif
> https://i.ibb.co/CVdXTq5/block-orange.gif

Thanks mate.

>
> Remember to change the filename in the "animation" entry.

Noted. Just tried the block_red and it looks fine (slight size
difference I can't seem to resolve, possibly for the scaling reason you
mentioned previously).

>
>> I just happened to be looking at the display as it went into idle mode.
>>
>> What I had was two solid target bars and one solid actual square and the
>> flashing one.
>>
>> As it got to temp the second actual went solid and I got a brief flash of
>> the 3rd actual square before all 4 went green.
>
> From two to four and the target was 2? That can't be right.

Sorry, two top, two bottom.

>
>> That could be the 'flash' function still completing even after the code
>> had gone into idle but then wouldn't that have still been on pos 2?
>
> I don't follow. If the target was 2, and 1 was solid and 2 was
> flashing, then 2 would have gone solid when idle (up to temp).
>
> If 1 & 2 were solid and 3 was flashing, then 3 would have gone from
> flashing to solid.
>
> Did the number of solid bars when up to temp reflect the temp as shown
> by the text?
>
> Please clarify or do another check.

Sure, I have the same state now (I have to take the temperature sensor
out into the hall to get it to display a lower 'actual' for experiments etc.

So, we have two greens, one actual and one target. I tweak the temp up
one Deg with the remote and now have 3 solid red (one actual and two
target) and the flashing actual as / where expected.

As it comes to temp and about to go to 4 greens, there is a momentary
flash of red in the next column (pos 3 of actual).

So it's as if the routine is first inserting the second solid red but
also flashing the next block, before switching back to all green on idle?

What I'd expect (in case it makes it easier to understand), is that the
flashing block would simply go green, I would get the glimpse of the
next block being flashed?

Cheers, T i m
>
>

[Apd]

"T i m" wrote:
> On 20/02/2024 12:48, Apd wrote:
>> Remember to change the filename in the "animation" entry.
>
> Noted. Just tried the block_red and it looks fine (slight size difference
> I can't seem to resolve, possibly for the scaling reason you mentioned
> previously).

It should always be square and the width should be 35 pixels, so the
"animation" entry ought to contain:

resize: 35x35

The first value is width.

>> Please clarify or do another check.
>
> Sure, I have the same state now (I have to take the temperature sensor out
> into the hall to get it to display a lower 'actual' for experiments etc.
>
> So, we have two greens, one actual and one target. I tweak the temp up one
> Deg with the remote and now have 3 solid red (one actual and two target)
> and the flashing actual as / where expected.
>
> As it comes to temp and about to go to 4 greens, there is a momentary
> flash of red in the next column (pos 3 of actual).

I see.

> So it's as if the routine is first inserting the second solid red but also
> flashing the next block, before switching back to all green on idle?
>
> What I'd expect (in case it makes it easier to understand), is that the
> flashing block would simply go green,

Yes, that's what I'd expect.

> I would get the glimpse of the next block being flashed?

You mean you would not (or should not). It may be caused by a small
delay between sensors; i.e. the "heating" state overuns slightly
before it has properly detected it's up to temp. Or, that may be
nonesense and it's my code. I'll have a think about it.

[Apd]

"T i m" wrote:
> So, we have two greens, one actual and one target. I tweak the temp up one
> Deg with the remote and now have 3 solid red (one actual and two target)
> and the flashing actual as / where expected.
>
> As it comes to temp and about to go to 4 greens, there is a momentary
> flash of red in the next column (pos 3 of actual).

I'm hoping the following will fix it.

Change this within the first "for" code block:

if (heat) {
it.image(x, box_y + gap, id(anim_blk), COLOR_ON, COLOR_OFF);
}

to this:

if (heat && i <= int(tgt) ) {

it.image(x, box_y + gap, id(anim_blk), COLOR_ON, COLOR_OFF);
}

(I think the indent's right)

[T i m]

On 20/02/2024 22:50, Apd wrote:
> "T i m" wrote:
>> On 20/02/2024 12:48, Apd wrote:
>>> Remember to change the filename in the "animation" entry.
>>
>> Noted. Just tried the block_red and it looks fine (slight size difference
>> I can't seem to resolve, possibly for the scaling reason you mentioned
>> previously).
>
> It should always be square and the width should be 35 pixels, so the
> "animation" entry ought to contain:
>
> resize: 35x35
>
> The first value is width.

Yeah, I played with that the first time you mentioned it but it seemed
to remain square. I believe you felt that it was retaining the aspect ratio?

>
>>> Please clarify or do another check.
>>
>> Sure, I have the same state now (I have to take the temperature sensor out
>> into the hall to get it to display a lower 'actual' for experiments etc.
>>
>> So, we have two greens, one actual and one target. I tweak the temp up one
>> Deg with the remote and now have 3 solid red (one actual and two target)
>> and the flashing actual as / where expected.
>>
>> As it comes to temp and about to go to 4 greens, there is a momentary
>> flash of red in the next column (pos 3 of actual).
>
> I see.
>
>> So it's as if the routine is first inserting the second solid red but also
>> flashing the next block, before switching back to all green on idle?
>>
>> What I'd expect (in case it makes it easier to understand), is that the
>> flashing block would simply go green,
>
> Yes, that's what I'd expect.
>
>> I would get the glimpse of the next block being flashed?
>
> You mean you would not (or should not).

Well, I isn't 'needed' so I would think we would say 'should'?

> It may be caused by a small
> delay between sensors; i.e. the "heating" state overuns slightly
> before it has properly detected it's up to temp.

Yeah, that makes sense ...

> Or, that may be
> nonesense and it's my code. I'll have a think about it.
>

Thanks.

I wouldn't say it's any 'nonsense' in your code, more that there could
be a very subtle ordering that *might* possibly have an effect?

Cheers, T i m

[T i m]

Done (thanks). ;-)

>
>
> (I think the indent's right)

It was indeed, perfect. ;-)

I'll have to watch it for a bit to catch it as it switches so I'll let
you know. ;-)

Cheers, T i m
>
>

[T i m]

Just as an aside, this is the latest update (as in doing it now) to ESPHome:

ESPHome is a *Subset* to / of Home Assistant and one of many (for anyone
thinking they could easily duplicate what HA does themselves). ;-)

(Oooh, my lounge lights have just gone off and my curtains opened). ;-)

Cheers, T i m


New Components

feat: add AS5600 component/sensor esphome#5174 by @ammmze
(new-integration)
Support for ST7567 display 128x64 (I2C, SPI) esphome#5952 by
@latonita (new-integration)
BME280 SPI esphome#5538 by @apbodrov (new-integration)
(breaking-change)
Add support for VEML3235 lux sensor esphome#5959 by @kbx81
(new-integration)
Add support of Honeywell HumidIcon (I2C HIH series) Temperature &
Humidity sensor esphome#5730 by @Benichou34 (new-integration)
Add combination sensor and remove absorbed kalman_combinator
component esphome#5438 by @kahrendt (new-integration) (breaking-change)
Add micro_wake_word component esphome#6136 by @kahrendt
(new-integration)

Breaking Changes

PMSx003 add relevant device and state classes to default config
esphome#5633 by @wheimbigner (breaking-change)
BME280 SPI esphome#5538 by @apbodrov (new-integration)
(breaking-change)
convert cse7766 to non-polling esphome#6095 by @ssieb (breaking-change)
Add combination sensor and remove absorbed kalman_combinator
component esphome#5438 by @kahrendt (new-integration) (breaking-change)

Beta Changes

AUTO_LOAD sensor for shelly_dimmer esphome#6223 by @kbx81
Add more debugging logs to microWakeWord esphome#6238 by @kahrendt
Fix to RF receiver for Drayton Digistat heating controller
esphome#6235 by @marshn
WRGB Use correct multiplier esphome#6237 by @mhetzi
Add optional minimum esphome version to microWakeWord manifest
esphome#6240 by @jesserockz
Fix xl9535 pin reads esphome#6242 by @jesserockz
hold interrupt disable for dallas one-wire esphome#6244 by @ssieb
Fix tm1651 enum esphome#6248 by @kbx81
Clear UART read buffer before sending next command esphome#6200 by
@fototakas
Voice Assistant: add on_idle trigger and fix nevermind esphome#6141
by @synesthesiam
Tuya Fan component fix to handle enum datapoint type esphome#6135
by @sibowler

All changes

Bump esptool from 4.6.2 to 4.7.0 esphome#5935 by @dependabot[bot]
Bump actions/download-artifact from 3.0.2 to 4.0.0 esphome#5936 by
@dependabot[bot]
Bump build-image action versions esphome#5954 by @jesserockz
Revert "Bump build-image action versions" esphome#5955 by @jesserockz
Revert "Bump actions/download-artifact from 3.0.2 to 4.0.0"
esphome#5956 by @jesserockz
Bump zeroconf from 0.130.0 to 0.131.0 esphome#5967 by @dependabot[bot]
Add ability to lock to set mode esphome#5924 by @ysmilda
feat: add AS5600 component/sensor esphome#5174 by @ammmze
(new-integration)
Add default substitutions for package includes esphome#5752 by @mknjc
Add gradient option to addressable color wipe effect esphome#5689
by @lifeisafractal
Added alarm processing for Haier component (hOn protocol)
esphome#5965 by @paveldn
Allow haier remote protocol to use lambdas esphome#5898 by @catlee
PMSx003 add relevant device and state classes to default config
esphome#5633 by @wheimbigner (breaking-change)
Add waveshare 2.7in V2 model esphome#5903 by @gumulka
Add support for waveshare 2.9in B V3 version esphome#5902 by @gumulka
Fix pin reuse in test1 esphome#5978 by @jesserockz
Add Waveshare 1.47in 172x320 to ST7789v component esphome#5884 by
@mrtoy-me
(fingerprint_grow) Added on_finger_scan_invalid automation.
esphome#5885 by @RubenNL
Alarm panel: Add changes to support enhanced features esphome#5671
by @hwstar
support default pins for adafruit esp32 feather v2 esphome#5482 by
@sbrudenell
Bug: Unwanted change resistance in x9c component esphome#5483 by
@fizista
Improvements to RF receiver for Drayton Digistat heating controller
esphome#5504 by @marshn
Reduce memory usage with StringRef in MQTT Components esphome#5719
by @kahrendt
Nextion allow underscore on names esphome#5979 by @edwardtfn
Add Keeloq RF protocol esphome#5511 by @marshn
Add a Binary Sensor Filter for state settling esphome#5900 by @cottsay
Lint the script folder files esphome#5991 by @jesserockz
web_server support for home assistant like styling esphome#5854 by
@afarago
[Touchscreen] Add expire of touch record. esphome#5986 by
@Fabian-Schmidt
Support for ST7567 display 128x64 (I2C, SPI) esphome#5952 by
@latonita (new-integration)
Add constants used by multiple display drivers to global const.py
esphome#6033 by @clydebarrow
Nextion queue size esphome#6029 by @edwardtfn
Ble client additions and fixes esphome#5277 by @clydebarrow
HaierProtocol library updated to 0.9.25 to fix the answer_timeout
bug esphome#6015 by @paveldn
GT911 touchscreen: Fix bug causing touch button release to fail
esphome#6042 by @clydebarrow
Display: Introduce draw_pixels_at() method for fast block display
rendering esphome#6034 by @clydebarrow
clang-format and clang-tidy scripts: More robust algorithm to find
correct executable esphome#6041 by @clydebarrow
Don't crash with invalid adc pin esphome#6059 by @ssieb
Add questionmark to default glyphs. esphome#6053 by @RubenNL
pylontech: fix voltage_low and voltage_high wrong unit esphome#6060
by @functionpointer
Bump flake8 from 6.1.0 to 7.0.0 esphome#6058 by @dependabot[bot]
Nextion enable upload from https when using esp-idf esphome#6051 by
@edwardtfn
Extends UART change at runtime to ESP8266 esphome#6019 by @edwardtfn
Nextion draw QR code at runtime esphome#6027 by @edwardtfn
Extend i2s config options esphome#6056 by @Hadatko
Add getter for image data_start esphome#6036 by @clydebarrow
Bump hypothesis to 6.92.1 esphome#6011 by @bdraco
Bump recommended ESP32 IDF to 4.4.6 esphome#6048 by @bdraco
Bump pytest from 7.4.3 to 7.4.4 esphome#6046 by @dependabot[bot]
dashboard: refactor ping implementation to be more efficient
esphome#6002 by @bdraco
Bump pytest-asyncio from 0.23.2 to 0.23.3 esphome#6047 by
@dependabot[bot]
Bump black from 23.12.0 to 23.12.1 esphome#6018 by @dependabot[bot]
Run python tests on windows and macos esphome#6010 by @bdraco
BME280 SPI esphome#5538 by @apbodrov (new-integration)
(breaking-change)
Actions to enable and disable WireGuard connection esphome#5690 by
@droscy
hydreon_rgxx - fix missing cg.add(var.set_model(...)) esphome#6065
by @mrtoy-me
Bump pillow to 10.2.0. esphome#6091 by @pfrenssen
convert cse7766 to non-polling esphome#6095 by @ssieb (breaking-change)
Use touch state from ft63x6 driver. esphome#6055 by @nielsnl68
update script/setup so it works fine on windows esphome#6087 by
@nielsnl68
add Pico-ResTouch-LCD-3.5 esphome#6078 by @nielsnl68
Revert "add Pico-ResTouch-LCD-3.5" esphome#6098 by @nielsnl68
Add triangle shapes to display component esphome#6096 by @mathieu-mp
Fingerprint_grow: Trigger on finger scan start and on finger scan
misplaced esphome#6003 by @alexborro
Add continuous option to the graph esphome#6093 by @ssieb
Add NFC binary sensor platform esphome#6068 by @kbx81
Socket: Add recvfrom method to receive UDP with source address.
esphome#6103 by @clydebarrow
Add support for VEML3235 lux sensor esphome#5959 by @kbx81
(new-integration)
CV: tidy up Schema wrapper esphome#6105 by @jesserockz
Add support X.509 client certificates for MQTT. esphome#5778 by @h2zero
Fix color observation for triangle outline in display component
esphome#6107 by @mathieu-mp
Add support of Honeywell HumidIcon (I2C HIH series) Temperature &
Humidity sensor esphome#5730 by @Benichou34 (new-integration)
Proposal: Test yaml for each component esphome#5398 by @Fabian-Schmidt
WiFi fast_connect: save/load BSSID and channel for faster connect
from sleep esphome#5931 by @rguca
Fixes Waveshare 7.5in B V2 and V3 esphome#6079 by @Pofilo
Add combination sensor and remove absorbed kalman_combinator
component esphome#5438 by @kahrendt (new-integration) (breaking-change)
Bump platformio from 6.1.11 to 6.1.13 esphome#6086 by @dependabot[bot]
Bump actions/cache from 3.3.2 to 4.0.0 esphome#6110 by @dependabot[bot]
Enable networking and some other components on host platform
esphome#6114 by @clydebarrow
Fix time component for host platform esphome#6118 by @clydebarrow
Add quad spi features esphome#5925 by @clydebarrow
add AM2120 device type esphome#6115 by @alexbuit
Add support for Waveshare EPD 2.13" V3 esphome#5363 by @clydebarrow
OTA 2 which confirm each written chunk esphome#6066 by @tomaszduda23
Remove optional<> for pointer types esphome#6120 by @kroimon
Improve temperature precision in BME280 and BMP280 esphome#6124 by
@jxl77
Nextion TFT upload IDF memory optimization esphome#6128 by @edwardtfn
Add support for Pico-ResTouch-LCD-3.5 to ili9xxx driver
esphome#6129 by @clydebarrow
Ensure filename is shown when YAML raises an error esphome#6139 by
@bdraco
ILI9XXX: Restore offset usage in set_addr_window esphome#6147 by
@clydebarrow
Minimum 1 for full_update_every to prevent IntegerDivideByZero.
esphome#6150 by @RubenNL
Support tri-color waveshare eink displays 2.7inch B and B V2
esphome#4238 by @rnauber
Synchronise Device Classes from Home Assistant esphome#6158 by
@esphomebot
dfrobot_sen0395: Use setLatency instead of outputLatency
esphome#5665 by @jfroy
Add some components to the new testing framework (A part 1)
esphome#6142 by @kbx81
WRGB or RGBW? WS2814 esphome#6164 by @mhetzi
Add some components to the new testing framework (A part 2)
esphome#6162 by @kbx81
Bump aioesphomeapi to 21.0.2 esphome#6188 by @bdraco
Add some components to the new testing framework (B) esphome#6173
by @kbx81
Add "transformer_active" flag for use in effects. esphome#6157 by
@TikiBill
CSE7766: fix power and current measurements at low loads
esphome#6180 by @twasilczyk
host platform: improvements and bugfixes esphome#6137 by @clydebarrow
WLED Sync fix and BK72XX support esphome#6190 by @ChuckMash
Add missing vector.h for lightwaverf esphome#6196 by @kbx81
Add some components to the new testing framework (C) esphome#6174
by @kbx81
update docstrings in cpp_generator.py esphome#6212 by @nielsnl68
Fixed group mask logic for WLED Sync fix esphome#6193 by @ChuckMash
Add micro_wake_word component esphome#6136 by @kahrendt
(new-integration)
AUTO_LOAD sensor for shelly_dimmer esphome#6223 by @kbx81
Add more debugging logs to microWakeWord esphome#6238 by @kahrendt
Fix to RF receiver for Drayton Digistat heating controller
esphome#6235 by @marshn
WRGB Use correct multiplier esphome#6237 by @mhetzi
Add optional minimum esphome version to microWakeWord manifest
esphome#6240 by @jesserockz
Fix xl9535 pin reads esphome#6242 by @jesserockz
hold interrupt disable for dallas one-wire esphome#6244 by @ssieb
Fix tm1651 enum esphome#6248 by @kbx81
Clear UART read buffer before sending next command esphome#6200 by
@fototakas
Voice Assistant: add on_idle trigger and fix nevermind esphome#6141
by @synesthesiam
Tuya Fan component fix to handle enum datapoint type esphome#6135
by @sibowler

[Apd]

"T i m" wrote:

> On 20/02/2024 22:50, Apd wrote:
>> It should always be square and the width should be 35 pixels, so the
>> "animation" entry ought to contain:
>>
>> resize: 35x35
>>
>> The first value is width.
>
> Yeah, I played with that the first time you mentioned it but it seemed to
> remain square.

It will.

> I believe you felt that it was retaining the aspect ratio?

Correct. I made a square and it will stay that way. If you want an
oblong I'll have to make one with appropriate height/width ratio. The
last snapshot you showed indicated the drawn block (rather than the
image) was square:

https://i.ibb.co/s1jLC9k/TTGO-T-Display-18.jpg

So you should be able to match that with the current image.

>> It may be caused by a small delay between sensors; i.e. the "heating"
>> state overuns slightly before it has properly detected it's up to temp.
>
> Yeah, that makes sense ...
>
>> Or, that may be nonesense and it's my code. I'll have a think about it.
>>
>
> Thanks.
>
> I wouldn't say it's any 'nonsense' in your code, more that there could be
> a very subtle ordering that *might* possibly have an effect?

The code's checking if the state is "heating", which it still could be
briefly even if up to temp. I added another check to ensure it doesn't
flash the next block if the target has been reached.

[T i m]

On 21/02/2024 11:51, Apd wrote:

<snip>

>> I believe you felt that it was retaining the aspect ratio?
>
> Correct. I made a square and it will stay that way. If you want an
> oblong I'll have to make one with appropriate height/width ratio. The
> last snapshot you showed indicated the drawn block (rather than the
> image) was square:
>
> https://i.ibb.co/s1jLC9k/TTGO-T-Display-18.jpg
>
> So you should be able to match that with the current image.

I'm not sure how I could, other than by trial and error do you mean?
>

<snip>

> The code's checking if the state is "heating", which it still could be
> briefly even if up to temp. I added another check to ensure it doesn't
> flash the next block if the target has been reached.
>

Ok cool, thanks.

What If we replaced the block with a triangle pointing right, or a '>'
as that might be less obvious re matching up?

Sort of indicating the temperature is going >>> way?

Given you never see anything to the right of the block, you only really
need to make it 'look' right?

Cheers, T i m

[Apd]

"T i m" wrote:
> On 21/02/2024 11:51, Apd wrote:
>> https://i.ibb.co/s1jLC9k/TTGO-T-Display-18.jpg
>>
>> So you should be able to match that with the current image.
>
> I'm not sure how I could, other than by trial and error do you mean?

Of course; adjusting by a pixel or two until it looks ok.

>> The code's checking if the state is "heating", which it still could be
>> briefly even if up to temp. I added another check to ensure it doesn't
>> flash the next block if the target has been reached.
>
> Ok cool, thanks.

Has the spurious flash now gone?

> What If we replaced the block with a triangle pointing right, or a '>' as
> that might be less obvious re matching up?
>
> Sort of indicating the temperature is going >>> way?
>
> Given you never see anything to the right of the block, you only really
> need to make it 'look' right?

It might look better. Try this:
https://i.ibb.co/x7FwxQp/trg-red.gif

[T i m]

On 21/02/2024 21:32, Apd wrote:

<snip>

> Has the spurious flash now gone?

I think (believe) so, or at least I've not seen it since. ;-)

The thing is I've also set the minimum temperature increment to 1 DegC
so I can't inch it up and down around the threshold to make it easier to
spot. Toggling the temp up and down around the threshold with the remote
or the dashboard stat hasn't as yet allowed me to said said spurious
flash. ;-)

>
>> What If we replaced the block with a triangle pointing right, or a '>' as
>> that might be less obvious re matching up?
>>
>> Sort of indicating the temperature is going >>> way?
>>
>> Given you never see anything to the right of the block, you only really
>> need to make it 'look' right?
>
> It might look better. Try this:
> https://i.ibb.co/x7FwxQp/trg-red.gif
>

I think it looks great (thanks again). ;-)

https://ibb.co/k9yCWFq

Looking at that picture it seems the bottom of the triangle is slightly
lower than that of the blocks but you can't really see it in the flesh etc.

I've had a little purge of the stepping stone / duplicate display pages
but kept some of the more interesting steps so I can put them in an archive.

I was wondering if they had to be in numerical order or if I could order
them by simply changing the pageN value? I think I've not had the
numbers contiguous and it just counted the ones present.

Cheers, T i m

[Apd]

"T i m" wrote:
> On 21/02/2024 21:32, Apd wrote:
>> Has the spurious flash now gone?
>
> I think (believe) so, or at least I've not seen it since. ;-)
>
> The thing is I've also set the minimum temperature increment to 1 DegC so
> I can't inch it up and down around the threshold to make it easier to
> spot. Toggling the temp up and down around the threshold with the remote
> or the dashboard stat hasn't as yet allowed me to said said spurious
> flash. ;-)

Good - it's gone.

>> It might look better. Try this:
>> https://i.ibb.co/x7FwxQp/trg-red.gif
>>
>
> I think it looks great (thanks again). ;-)
>
> https://ibb.co/k9yCWFq

Yes, I think that's fine.

> Looking at that picture it seems the bottom of the triangle is slightly
> lower than that of the blocks but you can't really see it in the flesh
> etc.

It is. The top of the triangle is also one pixel below the blocks
because I gave it a 1px black border. To match it to the block height,
reduce the image resize height by a couple of pixels (or perhaps one
is enough). So, if it's currently 35x35, it could be:

resize: 33x33

> I've had a little purge of the stepping stone / duplicate display pages
> but kept some of the more interesting steps so I can put them in an
> archive.
>
> I was wondering if they had to be in numerical order or if I could order
> them by simply changing the pageN value? I think I've not had the numbers
> contiguous and it just counted the ones present.

I don't know. The manual says nothing about the ordering. You'll have
to experiment.

[T i m]

On 21/02/2024 23:14, Apd wrote:

<snip>

>> I think it looks great (thanks again). ;-)
>>
>> https://ibb.co/k9yCWFq
>
> Yes, I think that's fine.
>
>> Looking at that picture it seems the bottom of the triangle is slightly
>> lower than that of the blocks but you can't really see it in the flesh
>> etc.
>
> It is. The top of the triangle is also one pixel below the blocks
> because I gave it a 1px black border. To match it to the block height,
> reduce the image resize height by a couple of pixels (or perhaps one
> is enough). So, if it's currently 35x35, it could be:
>
> resize: 33x33

It actually was that so I've now dropped it one more and now it seems to
'blend in' more naturally (when viewed under a magnifier). ;-)

>
>> I've had a little purge of the stepping stone / duplicate display pages
>> but kept some of the more interesting steps so I can put them in an
>> archive.
>>
>> I was wondering if they had to be in numerical order or if I could order
>> them by simply changing the pageN value? I think I've not had the numbers
>> contiguous and it just counted the ones present.
>
> I don't know. The manual says nothing about the ordering. You'll have
> to experiment.

I just did whilst making that last adjustment by swapping the first and
last page numbers and that seems to make no difference, so it looks like
the page numbers just need to be unique, don't need to be contiguous and
are displayed in the same order they are in the code.

I then put the wifes display in the top in the ESP code and yes, it does
display that first / automagically, after you re-flash it and it reboots
etc.

Thanks again, T i m