Regression in 7‑Segment Display Plugin After Update to Build 20260108

[rvangelder11]

Description:
After updating my ESP8266 device to ESPEasy build 20260108, the 7‑segment display stopped showing any digits. The device boots normally, the plugin initializes, and ESPEasy accepts display commands, but no segments light up at all.

Rolling back to the previous stable build (20250430) immediately restores correct operation, so the issue appears to be a regression introduced in or shortly before 20260108.

Hardware setup:
• ESP8266 module
• 7‑segment display driven via 74HC595 shift register
• Standard ESPEasy 7‑segment plugin (no custom modifications)
• Same wiring and configuration that worked reliably on earlier builds

Symptoms on 20260108:
• Display remains completely blank
• No segment activity during boot
• Display commands produce no visible output
• Plugin appears active in the UI, but digits are not rendered on the hardware

What I’ve verified:
• Hardware is confirmed working (retested on 20241222)
• Configuration unchanged between builds
• No wiring or power issues
• Issue is reproducible across multiple reboots and clean flashes
. Switching from manual to clock does not show any text on the display

Request:
Could someone confirm whether recent changes to the display/rendering layer or GPIO initialization might have affected the 7‑segment plugin? If needed, I can provide logs or run specific tests.

using: ESP_Easy_mega_20260108_climate_A_ESP8266_4M1M.bin

[tonhuisman]

Not sure how you have a 7-segment display based on 74HC595 working in Release builds before 20260108, as this new ESPEasy feature has been merged on July 2nd, 2025... 🤔
And if you have been using a pre-release, that has been working as intended, it's still weird, as nothing was changed since that merge

[rvangelder11]

that was a wrong assumption made by co-pilot (that I should have checked).
It is a standard 7 segment 4 digits display with TM1637 with CLK, DIO, VCC, GNd pins.

I used the P073 Display - 7-segment display.

it worked fine in the 20250430 release

[tonhuisman]

that was a wrong assumption made by co-pilot

That's one of the reasons I'm quite skeptical about all that AI 'intervention' in many conversations. There's a lot of hallucination in the response, so please double-check any AI-suggestion.

Will have a look at why this might be broken.

[TD-er]

Also keep in mind that the weeks of lost time I had to spend on trying to keep the forum running was due to AI scraper bots literally attacking the server with 1000's of bots all at the same time, with peaks of 10's of thousands of bots at the same time, fetching 500k - 1M pages a day from the forum and wiki (both don't have so many pages).
So not only the AI answers are 'halucinations' but also the scraper bots written for all those AI companies ripping the whole internet hoping to earn some money later on.

[tonhuisman]

• Display remains completely blank

@rvangelder11
Have you saved the settings for the task, since the upgrade to 20260108 ?
If not, then saving them when the 20260108 build is installed will most likely solve the issue of not displaying anything, as the number of digits to use is now stored in settings, but defaults to 0 when not saved using the new build.

[rvangelder11]

Do you mean submit? I tried that and it didt not help. I then tried: going back to 20250430 and noted that there I do have to submit before it shows, but it works. I saved the settings, and reinstalled 20260108 and tried to update the settings file, finding out that the 2026 build is back to expecting a config.dat file only (and no longer provides the option to save all settings in a .tar file). So i derived the config.dat from the .tart settings that I had from the 2025 build, without success, even after again submitting the display task.

[TD-er]

This is the change Ton made to the pull request to fix this:

  if (0 == digits) {
    digits = P073_getDefaultDigits(P073_CFG_DISPLAYTYPE);
  }

So can you select the number of digits somewhere? (and then save)
If not, then I can make a test build for you with this change.

[rvangelder11]

there is no place where i can enter the number of digits.

[TD-er]

I started a single build of climate_A for ESP8266 here: https://github.com/letscontrolit/ESPEasy/actions/runs/20935996372
Should be done in a minute...

[tonhuisman]

That selector is only available for the 74HC595-based displays, as there you can have between 2 and 8 digits in different configurations. For other display types there is a known number of digits, so no selector available in the device configuration.

[rvangelder11]

the single build gives the same result: nothing on the display. choosing clock 24 or 12 does not result in anything on the display

[tonhuisman]

I'm looking into it (using similar hardware).
MAX7219 displays work as intended, for ESP8266 support for 74HC595 displays is not included (by default), will validate that too once I get TM1637 working again.

[tonhuisman]

@rvangelder11 Are you using the TM1637 display at 3.3V? As officially, that chip should run at 5V, though for red displays often it does work at 3.3V.
I have changed the routines for TM1637 to use the 'direct-GPIO' library while restructuring the source, as that works better on ESP32, but it may also cause this display to no longer work on 3.3V for ESP8266. I have been testing using a blue and yellow display, that require 5V anyway, as the LEDs have a slightly higher threshold, and this wasn't working at 3.3V. Now that I've added a level converter and power the display at 5V it is working as intended.

I've built an ESP8266 Climate_A build that's using the original Arduino GPIO function (for ESP32 it's still using 'direct-GPIO' lib), for you to test:

ESP_Easy_mega_20260117_climate_A_ESP8266_4M1M.zip

[rvangelder11]

I have rewired my display to run on 5V and it works OK now.
Thank you!