1 Like
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.
I was never able to compile ESPHome on my Pi3, not enough RAM.
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.
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.
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
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:
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?
Restart the esphome node into safe mode → do ota → win
Thanks. Doesn’t:
ota:
safe_mode: True
do the same thing?
You tell us
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.
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.
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.
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.
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.
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.
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.
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.
But that (BT) shouldn’t be a problem when doing OTA, since then esp is in programming mode and it doesn’t execute regular program, consequently it doesn’t use BT… right?