ESPHome, compile error

[stevemann (Stephen Mann (YAML-challenged))]

I am troubleshooting a problem where NodeMCU devices compiled using ESPHome V2024.4.x would not connect to WiFi.

I reinstalled ESPHome 2024.3.2 and the devices connect just fine.

On a spare Raspberry Pi-
I installed HAOS (Core2024.4.4, Supervisor2024.04.4) , and installed ESPHome 2024.4.2

When I compile the device, I get this error:

Compiling .pioenvs/wemosblink/src/esphome/components/api/api_connection.cpp.o
xtensa-lx106-elf-g++: fatal error: cannot execute 'cc1plus': execvp: No such file or directory
compilation terminated.
*** [.pioenvs/wemosblink/src/esphome/components/api/api_connection.cpp.o] Error 1
========================= [FAILED] Took 31.84 seconds =========================

I removed and reinstalled ESPHome Add-on, but the compile problem persists.

Any tips would be appreciated.

[Spiro]

[stevemann (Stephen Mann (YAML-challenged))]

I put the wifi and device base into separate packages because they are the same on most of my projects.

Device configuration:

# Blink the LED_BUILTIN (D4) on an ESP board

substitutions:
  device_name: wemosblink
  friendly_name: wemos blink
  my_ssid: iot

packages:
  wifi: !include common/wifi.yaml
  device_base: !include common/esp8266.yaml

#Override the default board:
esp8266:
  board: nodemcuv2

############################################

# Blink the LED on D4 (GPIO2, LED_BUILTIN)
switch:
  - platform: gpio
    pin:
      number: D4 
      mode: output
    id: builtinLED

interval:
  - interval: 750ms
    then:
      - switch.toggle: builtinLED

wifi.yaml:

wifi:
  ssid: !secret iot_ssid
  password: !secret iot_password

sensor:
  - platform: wifi_signal
    name: ${friendly_name} WiFi Level
    #id: ${device_name}_WiFi_level
    update_interval: 10s

# Get the WiFi details
text_sensor:
  - platform: wifi_info
    ip_address:
      name: ${friendly_name} IP
    ssid:
      name: ${friendly_name} SSID
    mac_address:
      name: ${friendly_name} Mac Address    

web_server:
  port: 80    

esp8266.yaml:

substitutions:
  project_name: ${device_name}
  project_version: "1.0"

esphome:
  name: ${project_name}
  project:
    name: steve.${device_name}
    version: ${project_version}
    
esp8266:
  board: esp01_1m
  framework:
    version: recommended
    
# Logger level "debug" is needed to get 1-Wire addresses, like the ds18b20.
logger:
  level: DEBUG

ota:
  safe_mode: True

# Enable Home Assistant API
api:

And, the log:

INFO ESPHome 2024.4.2
INFO Reading configuration /config/esphome/wemos-blink.yaml...
INFO Generating C++ source...
INFO Compiling app...
Processing wemosblink (board: nodemcuv2; framework: arduino; platform: platformio/[email protected])
--------------------------------------------------------------------------------
HARDWARE: ESP8266 80MHz, 80KB RAM, 4MB Flash
Dependency Graph
|-- ESPAsyncTCP-esphome @ 2.0.0
|-- ESPAsyncWebServer-esphome @ 3.1.0
|-- ESP8266WiFi @ 1.0
|-- ESP8266mDNS @ 1.2
|-- ArduinoJson @ 6.18.5
Compiling .pioenvs/wemosblink/src/esphome/components/api/api_connection.cpp.o
xtensa-lx106-elf-g++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
*** [.pioenvs/wemosblink/src/esphome/components/api/api_connection.cpp.o] Error 1
========================= [FAILED] Took 106.77 seconds =========================

It looks like the c++ compiler didn’t install.
This is HAOS on a Raspberry Pi3.

[brooksben11 (Ben)]

@stevemann

This is HAOS on a Raspberry Pi3

I was never able to compile ESPHome on my Pi3, not enough RAM.

[paddy0174 (Patrick)]

Yep, that looks very much like the Pi isn’t happy about the load and kills the process. Try again to compile and take a close look at CPU and RAM load. You’ll likely see 100% load and after a while, the process gets killed and the load falls back to normal.

That was the reason why I changed from Pi3 to Pi4 and ultimately to a small home server. ESPHome is quite heavy an your CPU load. Not long, but enough to kill a not very potent setup.

As an alternative you can install ESPHome on your normal PC or laptop, and use that one to compile the firmware. Afterwards you download it and flash it OTA via your standard ESPHome add-on from HA.

[stevemann (Stephen Mann (YAML-challenged))]

Thanks. I’ve never run Home Assistant on a Pi before so I wasn’t expecting any memory problems.

At any rate I installed ESPHome 2024.4.1 on my PC to continue my testing. The Pi goes back into the drawer.

[Spiro]

It is still possible to compile on RPI3 if you increase the swap file size. 2GB should do the trick. I had to do it for RPI3B+ that would usually crash HA when I tried to compile in esphome.
How to increase swap file size

[stevemann (Stephen Mann (YAML-challenged))]

Thanks for the information. I’ve marked it as the solution since others will likely have the same issue.

In my case, I was troubleshooting an ESPHome WiFi problem and wanted a “disposable” installation. Basically, a device compiled on ESPHome2024.4 will not connect to the WiFi, while the same device and configuration file compiled on ESPHome 2024.3 does connect.

My HomeAssistant host is an Intel NUC i3 with a 500Gb SSD. Since I found a way to have older versions of the ESPHome Add-On installed, I am able to continue my troubleshooting there.

FYI:

GitHub - khenderick/esphome-legacy-addons: ESPHome addons from previous...

[stevemann (Stephen Mann (YAML-challenged))]

I used to keep my ESPHome devices’ firmware up to date, but I stopped that when invariably some of my devices would brick and require a physical UART connection to upload. Of course, those devices would be the least accessible ones.

Lately, however, my OTA uploads are failing. Often the upload progress stops and I get a timeout error. I’ll hit “retry” and most of the time the upload finishes.

Any ideas for the cause? It probably isn’t the WiFi strength because when I connect to the device web page, the RSSI is in the low 60’s. Sometimes better.

Also, sometimes the MDNS won’t resolve the IP address, and the upload fails for that reason. Again, multiple retries usually succeed. Is there a way to skip the MDNS and just give ESPHome dashboard the device IP address instead of a hostname?

[indeeed]

Restart the esphome node into safe mode → do ota → win

[stevemann (Stephen Mann (YAML-challenged))]

Thanks. Doesn’t:

ota:
  safe_mode: True

do the same thing?

[indeeed]

@stevemann

same thing?

You tell us

[Masterzz]

IMHO not same thing. Here is description of OTA safe mode:

ESPHome also has an “OTA safe mode”. If for some reason your node gets into a boot loop, ESPHome will automatically try to detect this and will go over into a safe mode after the configured unsuccessful boot attempts (Defaults to 10 ).

It is for boot loops and is enabled by default.

[Protoncek (Pavel)]

I never used mdns for my esphome devices, only IP address, also i have only static IP’s, not dhcp.
So, if you have dynamic IP find current IP of your device, enter it and try (you can use advanced ip scanner to find it if you use windows):

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  manual_ip:
    static_ip: 192.168.x.y # enter desired static IP
    gateway: 192.168.x.1 # IP of your router
    subnet: 255.255.255.0 # your router's mask

if you want to change device’s IP then enter new IP above and add this line:

  use_address: current IP of your device 

Remember to delete or comment out this last line after succesfull flash.

[stevemann (Stephen Mann (YAML-challenged))]

@indeeed

You tell us

Unless I read the docs wrong…
safe_mode: true
Tells the ESP device to switch to the safe mode if an OTA fails, then try again.

[stevemann (Stephen Mann (YAML-challenged))]

@Protoncek

I never used mdns for my esphome devices, only IP address

I have over 100 LAN clients on my network, so managing dozens of static IPs is not a chore I would enjoy. That is what DHCP was made for. (Well, at least one reason).

I did try static IP on this device, and it made no difference.

[Edwin_D]

If you also configured bluetooth: agressie timing settings on that might interfere with wifi because they share the same radio.

I had trouble with that on the arduino framework. If you use BLE proxy switching to esp_idf may solve it.

[stevemann (Stephen Mann (YAML-challenged))]

Thanks for the input.
I have few BT devices, so that isn’t likely a problem.
Besides, channel overlap interference is highly overhyped. Transmissions are bursts in microseconds and both BT and WiFi (and Zigbee) protocols account for channel collisions.

Of the more than 100 clients on my LAN, the majority of them are on 2.4GHz WiFi, including 6 streaming cameras. If channel interference were a problem, my home would be the poster-child.

[Edwin_D]

@stevemann

Besides, channel overlap interference is highly overhyped. Transmissions are bursts in microseconds and both BT and WiFi (and Zigbee) protocols account for channel collisions.

It isn’t channel overlap I was talking about, it is time sharing in the radio itself if you configured both wifi and bluetooth. It switches between bluetooth and wifi, if Bluetooth is set to listen too long (on three bands consecutively I believe) the wifi has little time to use the radio. So those transmission busts might happen while it is listening for bluetooth, not wifi.

[stevemann (Stephen Mann (YAML-challenged))]

@Edwin_D

it is time sharing in the radio itself

That is different, and correct. Since none of my devices do both protocols, I’ve never encountered this. I can see how a device trying to transmit both BT and WiFi packets at the same time getting into a timing problem.