Am I missing something? running * Installation method Home Assistant OS
Core 2026.1.3
Supervisor 2026.01.1
Operating System 17.0
Frontend 20260107.2
I find today , This is the fourth CYD esphome device I was editing, (all WERE working just fine) that have now stopped connecting via WIFI after simple sensor edits, and upload. All items on line are up and running just fine. Testing led me through now this 4th device… where I took code from a similar yaml file for a similar device, and copied the main functions over leaving the orig api ap wifi esp and esphme section intact from the orig file. They compile just fine, and upload just fine, but afterwards I’m left with a non-op device, that is not connecting to esphome or HAOS via wifi
error logs
WARNING Can’t connect to ESPHome API for cydspec1 @ 192.168.1.166: Timeout while connecting to ‘’‘[AddrInfo(family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_STREAM: 1>, proto=6, sockaddr=IPv4Sockaddr(address=‘192.168.1.166’, port=6053))] (TimeoutAPIError)’‘’
Going through and creating a ‘new device’ from scratch, resulted in two of the working CYDs now not connecting, hence my c-a-p testing of two more. The only thing I can find in common with the two ‘scratch built’ runs, is partition issues, as they prevously had some pentest stuff installed. (yes that really screws your device up for anything later esphome related)
If you are doing pentesting, a full flash wipe, including wiping all partitions should be a given. Otherwise you are comparing apples with oranges.
Are you cloning security attributes or the MAC or static IP address, hence the first device connects but the identical clones you make don’t?
Any yaml and ESPHome compile/run logs for both working and non connecting devices to share? Maybe a second set of eyes on what’s the same and what’s different may help.
so many times what the originator Q’s… wording and readers ‘read’ almost always diverge. apparently here too. My Q PRIMARY was why would a code c-a-p effect the wifi? Well it appears now (with further testing) esphome is compiling a files, says it loaded. but does not. My variations is testing were to contrive why simple code changes would mess with the wifi and or the display functionality.
I can now cut out a 20 line lambda from my local screen print out and the device will work as expected. Screen writes work, unit connects.
Paste the lambda in and it stops connecting over wifi and the screen is speckeld snow.
This lambda works perfectly on three other devices, (a C3 an S3 and a wroom) all feeding 1306 displays. I tried to load this on a CYD and it can not handle it. I’m starting to guess the arrays are not being picked up by esphome for this device type .
lambda follows…
display:
- platform: ili9xxx
model: ILI9341
id: main_display
spi_id: lcd
cs_pin: GPIO15
dc_pin: GPIO2
rotation: 180
# transform:
# swap_xy: true
# mirror_x: true
# mirror_y: true
color_palette: 8bit
color_order: rgb
invert_colors: false
dimensions:
width: 320 # 320
height: 240 # 240
lambda: |-
// 1. Define your data array (Replace with your actual sensor names)
float values[10] = {
id(d415_nm).state, id(d445_nm).state, id(d480_nm).state, id(d515_nm).state,
id(d555_nm).state, id(d590_nm).state, id(d630_nm).state, id(d680_nm).state,
id(clear1).state, id(nir1).state
};
// 1a. add an array of colors for the bars
//float values[10] = {
// id(d415_nm).state, id(d445_nm).state, id(d480_nm).state, id(d515_nm).state,
// id(d555_nm).state, id(d590_nm).state, id(d630_nm).state, id(d680_nm).state,
// id(clear1).state, id(nir1).state
//};
// 2. Auto-ranging: Find the max value
float max_val = 0.001; // Avoid division by zero
for (int i = 0; i < 10; i++) {
if (values[i] > max_val) max_val = values[i];
}
// 3. Drawing Parameters
int graph_bottom = 100;
int bar_width = 10;
int spacing = 1;
for (int i = 0; i < 10; i++) {
// Calculate scaled height (max 100 pixels)
int bar_height = (values[i] / max_val) * 100;
// Calculate X position with 2px offset for the last two (S and N)
int x_pos = i * (bar_width + spacing);
if (i >= 8) x_pos += 2;
// 4. Set Colors (Example: Green for low, Red for high)
Color bar_color = Color(0, 255, 0);
if (bar_height > 80) bar_color = Color(255, 0, 0);
// 5. Draw the Bar
it.filled_rectangle(x_pos, graph_bottom - bar_height, bar_width, bar_height, bar_color);
// 6. Draw Labels (20px reserved at bottom)
std::string label = (i < 8) ? std::to_string(i + 1) : (i == 8 ? "S" : "N");
it.printf(x_pos + (bar_width/2), 110, id(font12), TextAlign::CENTER, "%s", label.c_str());
}
note: the code above is from the 1306 display… less than 128x128. The CYD would be 320x240 so could bump up the graph bar size as well as add color.
ok… prob solved(?).
I’ll have to do a write up on this. That rather short loop of simply printing ten variable height bars, overloaded the processor capabilities of the ESP32! C3 mini, xiao C3, S3, wroom all tested. Same issue.
There is VERY little ‘headroom’ on the CYD (ESP32-2432S028R) when WiFi and SPI are running simultaneously. The posted code loop, was more than enough to delay interrupts more than a few milliseconds (calc’ing the heights?) starving the WiFi stack, causing the “messy” connection and “snow” (partial/corrupted buffer writes) to the screen.
So… you ol’ timer C++ weenies out there… I guess we gotta’ learn how to STOP stacking code for efficiency sake he he.
to me it was stupefying why 400+ lines of screen it.prints with a zillion display conditionals (colors etc) works, and that simple loop wouldn’t.
TRICK: Move ALL calcs to a SCRIPT or INTERVAL. Array data still moves faster than individual sensor variables.
My Q PRIMARY was why would a code c-a-p effect the wifi? Well it appears now (with further testing) esphome is compiling a files, says it loaded. but does not. My variations is testing were to contrive why simple code changes would mess with the wifi and or the display functionality.