Closed emudryj closed 2 years ago
I did some debugging with my setup. I have 2 power_boards setup that works fine, until I add power_factor sensor, so I have left it off for now.
My conclusion. It binary size dependant.
Some of the failure above did get further into the set setup before crashing (and rebooting)
I can get 2 and half board to work without the extra 'template sensors'.
I can get 1 board to work with power_factor sensors.
My esp32 is reported as ESP32D0WDQ6 (revision 1). All these test were done with the esp32 not pluged into the power monitor board.
It seems like with this many sensors the ESP32 is running out of stack. A similar issue was posted here: https://github.com/esphome/issues/issues/773
After removing extra sensors and id's, I still got a meditation error with the following stack trace:
PC: 0x4012a9ff
EXCVADDR: 0x00000000
Decoding stack results
0x40123887: nvs::Page::findItem(unsigned char, nvs::ItemType, char const*, unsigned int&, nvs::Item&, unsigned char, nvs::VerOffset) at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/nvs_flash/src/nvs_page.cpp line 745
0x400d77f5: wifi_loop() at C:\Users\John\AppData\Local\Temp\arduino_build_454298\sketch\wifi.cpp line 359
0x400d7a15: wifi_loop() at C:\Users\John\AppData\Local\Temp\arduino_build_454298\sketch\wifi.cpp line 472
0x400de161: checkDigestAuthentication(char const*, char const*, char const*, char const*, char const*, bool, char const*, char const*, char const*) at C:\Users\John\Documents\Arduino\libraries\ESPAsyncWebServer\src\WebAuthentication.cpp line 179
0x400de18e: checkDigestAuthentication(char const*, char const*, char const*, char const*, char const*, bool, char const*, char const*, char const*) at C:\Users\John\Documents\Arduino\libraries\ESPAsyncWebServer\src\WebAuthentication.cpp line 180
0x400d79bd: wifi_loop() at C:\Users\John\AppData\Local\Temp\arduino_build_454298\sketch\wifi.cpp line 451
0x400df17d: AsyncStaticWebHandler::_fileExists(AsyncWebServerRequest*, String const&) at C:\Users\John\Documents\Arduino\libraries\ESPAsyncWebServer\src\WebHandlers.cpp line 145
0x400eb007: ultoa at C:\Users\John\AppData\Local\Arduino15\packages\esp32\hardware\esp32\1.0.4\cores\esp32\stdlib_noniso.c line 85
0x40088ff9: pxPortInitialiseStack at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/port.c line 227
It seems like the web services (captive portal, web server) are putting it over the edge.
After removing all templates and extra id's I got it to work will all boards. But then you'd have to do the totals for amps & watts somewhere else, along with kwh. Note that I also removed the web server, restart switch, and captive portal. This is the config I used:
substitutions:
# Change the disp_name to something you want
disp_name: south_panel
# Interval of how often the power is updated
update_time: 6s
# 30A/1V SCT-013-030: 8650
# 50A/1V SCT-013-050: 15420
# 100A/50ma SCT-013-000: 32498
current_cal: '36000'
#9VAC Transformer for versions > meter v1.2
voltage_cal: '7305'
esphome:
name: south_panel
platform: ESP32
board: nodemcu-32s
wifi:
ssid: "WIFI"
password: "wifi_password"
# Enable logging
logger:
# Enable Home Assistant API
api:
ota:
spi:
clk_pin: 18
miso_pin: 19
mosi_pin: 23
sensor:
#IC1 Main
- platform: atm90e32
cs_pin: 5
phase_a:
voltage:
name: ${disp_name} Volts A Main
accuracy_decimals: 1
current:
name: ${disp_name} CT1 Amps
power:
name: ${disp_name} CT1 Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_b:
current:
name: ${disp_name} CT2 Amps
power:
name: ${disp_name} CT2 Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_c:
current:
name: ${disp_name} CT3 Amps
power:
name: ${disp_name} CT3 Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
frequency:
name: ${disp_name} Freq A Main
line_frequency: 60Hz
gain_pga: 1X
update_interval: ${update_time}
#IC2 Main
- platform: atm90e32
cs_pin: 4
phase_a:
current:
name: ${disp_name} CT4 Amps
power:
name: ${disp_name} CT4 Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_b:
current:
name: ${disp_name} CT5 Amps
power:
name: ${disp_name} CT5 Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_c:
current:
name: ${disp_name} CT6 Amps
power:
name: ${disp_name} CT6 Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
line_frequency: 60Hz
gain_pga: 1X
update_interval: ${update_time}
#IC1 AddOn 1
- platform: atm90e32
cs_pin: 0
phase_a:
current:
name: ${disp_name} CT7 Amps
power:
name: ${disp_name} CT7 Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_b:
current:
name: ${disp_name} CT8 Amps
power:
name: ${disp_name} CT8 Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_c:
current:
name: ${disp_name} CT9 Amps
power:
name: ${disp_name} CT9 Watts
id: ct9Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
line_frequency: 60Hz
gain_pga: 1X
update_interval: ${update_time}
#IC2 AddOn 1
- platform: atm90e32
cs_pin: 16
phase_a:
current:
name: ${disp_name} CT10 Amps
power:
name: ${disp_name} CT10 Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_b:
current:
name: ${disp_name} CT11 Amps
power:
name: ${disp_name} CT11 Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_c:
current:
name: ${disp_name} CT12 Amps
power:
name: ${disp_name} CT12 Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
line_frequency: 60Hz
gain_pga: 1X
update_interval: ${update_time}
#IC1 AddOn 2
- platform: atm90e32
cs_pin: 2
phase_a:
current:
name: ${disp_name} CT13 Amps
id: ct13Amps
power:
name: ${disp_name} CT13 Watts
id: ct13Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_b:
current:
name: ${disp_name} CT14 Amps
id: ct14Amps
power:
name: ${disp_name} CT14 Watts
id: ct14Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_c:
current:
name: ${disp_name} CT15 Amps
id: ct15Amps
power:
name: ${disp_name} CT15 Watts
id: ct15Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
line_frequency: 60Hz
gain_pga: 1X
update_interval: ${update_time}
#IC2 AddOn 2
- platform: atm90e32
cs_pin: 17
phase_a:
current:
name: ${disp_name} CT16 Amps
power:
name: ${disp_name} CT16 Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_b:
current:
name: ${disp_name} CT17 Amps
power:
name: ${disp_name} CT17 Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_c:
current:
name: ${disp_name} CT18 Amps
power:
name: ${disp_name} CT18 Watts
id: ct18Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
line_frequency: 60Hz
gain_pga: 1X
update_interval: ${update_time}
#IC1 AddOn 3
- platform: atm90e32
cs_pin: 13
phase_a:
current:
name: ${disp_name} CT19 Amps
power:
name: ${disp_name} CT19 Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_b:
current:
name: ${disp_name} CT20 Amps
power:
name: ${disp_name} CT20 Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_c:
current:
name: ${disp_name} CT21 Amps
power:
name: ${disp_name} CT21 Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
line_frequency: 60Hz
gain_pga: 1X
update_interval: ${update_time}
#IC2 AddOn 3
- platform: atm90e32
cs_pin: 22
phase_a:
current:
name: ${disp_name} CT22 Amps
power:
name: ${disp_name} CT22 Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_b:
current:
name: ${disp_name} CT23 Amps
power:
name: ${disp_name} CT23 Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_c:
current:
name: ${disp_name} CT24 Amps
power:
name: ${disp_name} CT24 Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
line_frequency: 60Hz
gain_pga: 1X
update_interval: ${update_time}
#IC1 AddOn 4
- platform: atm90e32
cs_pin: 14
phase_a:
current:
name: ${disp_name} CT25 Amps
power:
name: ${disp_name} CT25 Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_b:
current:
name: ${disp_name} CT26 Amps
power:
name: ${disp_name} CT26 Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_c:
current:
name: ${disp_name} CT27 Amps
power:
name: ${disp_name} CT27 Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
line_frequency: 60Hz
gain_pga: 1X
update_interval: ${update_time}
#IC2 AddOn 4
- platform: atm90e32
cs_pin: 25
phase_a:
current:
name: ${disp_name} CT28 Amps
power:
name: ${disp_name} CT28 Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_b:
current:
name: ${disp_name} CT29 Amps
power:
name: ${disp_name} CT29 Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_c:
current:
name: ${disp_name} CT30 Amps
id: ct30Amps
power:
name: ${disp_name} CT30 Watts
id: ct30Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
line_frequency: 60Hz
gain_pga: 1X
update_interval: ${update_time}
#IC1 AddOn 5
- platform: atm90e32
cs_pin: 15
phase_a:
current:
name: ${disp_name} CT31 Amps
power:
name: ${disp_name} CT31 Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_b:
current:
name: ${disp_name} CT32 Amps
power:
name: ${disp_name} CT32 Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_c:
current:
name: ${disp_name} CT33 Amps
power:
name: ${disp_name} CT33 Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
line_frequency: 60Hz
gain_pga: 1X
update_interval: ${update_time}
#IC2 AddOn 5
- platform: atm90e32
cs_pin: 26
phase_a:
current:
name: ${disp_name} CT34 Amps
power:
name: ${disp_name} CT34 Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_b:
current:
name: ${disp_name} CT35 Amps
power:
name: ${disp_name} CT35 Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_c:
current:
name: ${disp_name} CT36 Amps
power:
name: ${disp_name} CT36 Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
line_frequency: 60Hz
gain_pga: 1X
update_interval: ${update_time}
time:
- platform: sntp
id: sntp_time
@OttoWinter is there a switch somewhere to free up some stack? Maybe something to turn off unused global variables?
I don't believe there's any way to do that. There are a few core things (wifi, logger, api, mqtt) that create globals when enabled. Because they need to be available to other components, they're present whenever enabled; the only way to get rid of them is to not include the component.
From what I'm seeing, platformio configures a 4kB stack for the main task. I don't know if there's a good way to change this without rebuilding the entire SDK, though. Seems like either raising the main task's stack size, or finding some way to move things into another task, is going to be necessary to support this many components.
Thanks @brandond. It sounds like allocating more stack for the main task could work. That setting is here. Changing that manually isn't that simple though, and it would probably revert every time an update was made.
A better long term solution may be to move some functions to a separate task though. I see that Otto moved the BLE stack into the main task previously because of race conditions, as indicated here.
@CircuitSetup
is there a switch somewhere to free up some stack? Maybe something to turn off unused global variables?
No, there is not.
The problem is all variables are used need to be stored somewhere (you can find them at the top of the generated main.cpp
). Some versions ago, they were all local in setup()
, but then custom code can't easily use them, which is not good. So now they're all global.
I don't see a good solution of moving the global variables somewhere else. Moving them back into setup()
isn't going to fix the issue, as the highest stack depth use is probably in App.setup()
anyway.
One option would be to move everything in a struct that is allocated on the heap, and only store a reference to it globally. Then, id()
would need to be turned into a macro and some major changes in the codegen would need to be made. And it's quite possible we then run out of heap space.
I'd be interested in the heap usage - could you enable the debug component and print what it says? I'd be interested in knowing how much heap is free on these devices to judge how effective a fix could be.
A better long term solution may be to move some functions to a separate task though.
That is for #773 and is just for BLE - the BLE feature uses a bunch of stack space. Putting it to a separate task would solve the problem there. This issue here is a different one - here it's globals that cause the majority of the stack use.
@OttoWinter thanks for explaining. That all makes a lot of sense. I'll get some debug info your way.
If there's enough heap, could more stack be allocated without editing sdkconfig.h?
Here is the debug output with the above config:
[11:45:55][D][debug:023]: ESPHome version 1.15.0-dev
[11:45:55][D][debug:025]: Free Heap Size: 206288 bytes
[11:45:55][D][debug:053]: Flash Chip: Size=4096kB Speed=40MHz Mode=DIO
[11:45:55][D][debug:086]: Chip: Model=ESP32, Features=WIFI_BGN,BLE,BT, Cores=2, Revision=1
[11:45:55][D][debug:088]: ESP-IDF Version: v3.2.3-14-gd3e562907
[11:45:55][D][debug:091]: EFuse MAC: 0000644675AE114C
[11:45:55][D][debug:143]: Reset Reason: Software Reset CPU
[11:45:55][D][debug:186]: Wakeup Reason: Unknown
If I add one more sensor then I get a panic.
@emudryj I also got it to work with the following. This is ideal if you really only need to get total power and kwh from that, although I left in current for the main board:
substitutions:
# Change the disp_name to something you want
disp_name: south_panel
# Interval of how often the power is updated
update_time: 6s
# 30A/1V SCT-013-030: 8650
# 50A/1V SCT-013-050: 15420
# 100A/50ma SCT-013-000: 32498
current_cal: '36000'
#9VAC Transformer for versions > meter v1.2
voltage_cal: '7305'
esphome:
name: south_panel
platform: ESP32
board: nodemcu-32s
wifi:
ssid: "WIFI"
password: "wifi_password"
# Enable logging
logger:
# Enable Home Assistant API
api:
ota:
spi:
clk_pin: 18
miso_pin: 19
mosi_pin: 23
sensor:
#IC1 Main
- platform: atm90e32
cs_pin: 5
phase_a:
voltage:
name: ${disp_name} Volts A Main
id: ic1Volts
accuracy_decimals: 1
current:
name: ${disp_name} CT1 Amps
id: ct1Amps
power:
name: ${disp_name} CT1 Watts
id: ct1Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_b:
current:
name: ${disp_name} CT2 Amps
id: ct2Amps
power:
name: ${disp_name} CT2 Watts
id: ct2Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_c:
current:
name: ${disp_name} CT3 Amps
id: ct3Amps
power:
name: ${disp_name} CT3 Watts
id: ct3Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
frequency:
name: ${disp_name} Freq A Main
line_frequency: 60Hz
gain_pga: 1X
update_interval: ${update_time}
#IC2 Main
- platform: atm90e32
cs_pin: 4
phase_a:
current:
name: ${disp_name} CT4 Amps
id: ct4Amps
power:
name: ${disp_name} CT4 Watts
id: ct4Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_b:
current:
name: ${disp_name} CT5 Amps
id: ct5Amps
power:
name: ${disp_name} CT5 Watts
id: ct5Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_c:
current:
name: ${disp_name} CT6 Amps
id: ct6Amps
power:
name: ${disp_name} CT6 Watts
id: ct6Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
line_frequency: 60Hz
gain_pga: 1X
update_interval: ${update_time}
#IC1 AddOn 1
- platform: atm90e32
cs_pin: 0
phase_a:
power:
name: ${disp_name} CT7 Watts
id: ct7Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_b:
power:
name: ${disp_name} CT8 Watts
id: ct8Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_c:
power:
name: ${disp_name} CT9 Watts
id: ct9Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
line_frequency: 60Hz
gain_pga: 1X
update_interval: ${update_time}
#IC2 AddOn 1
- platform: atm90e32
cs_pin: 16
phase_a:
power:
name: ${disp_name} CT10 Watts
id: ct10Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_b:
power:
name: ${disp_name} CT11 Watts
id: ct11Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_c:
power:
name: ${disp_name} CT12 Watts
id: ct12Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
line_frequency: 60Hz
gain_pga: 1X
update_interval: ${update_time}
#IC1 AddOn 2
- platform: atm90e32
cs_pin: 2
phase_a:
power:
name: ${disp_name} CT13 Watts
id: ct13Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_b:
power:
name: ${disp_name} CT14 Watts
id: ct14Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_c:
power:
name: ${disp_name} CT15 Watts
id: ct15Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
line_frequency: 60Hz
gain_pga: 1X
update_interval: ${update_time}
#IC2 AddOn 2
- platform: atm90e32
cs_pin: 17
phase_a:
power:
name: ${disp_name} CT16 Watts
id: ct16Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_b:
power:
name: ${disp_name} CT17 Watts
id: ct17Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_c:
power:
name: ${disp_name} CT18 Watts
id: ct18Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
line_frequency: 60Hz
gain_pga: 1X
update_interval: ${update_time}
#IC1 AddOn 3
- platform: atm90e32
cs_pin: 13
phase_a:
power:
name: ${disp_name} CT19 Watts
id: ct19Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_b:
power:
name: ${disp_name} CT20 Watts
id: ct20Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_c:
power:
name: ${disp_name} CT21 Watts
id: ct21Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
line_frequency: 60Hz
gain_pga: 1X
update_interval: ${update_time}
#IC2 AddOn 3
- platform: atm90e32
cs_pin: 22
phase_a:
power:
name: ${disp_name} CT22 Watts
id: ct22Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_b:
power:
name: ${disp_name} CT23 Watts
id: ct23Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_c:
power:
name: ${disp_name} CT24 Watts
id: ct24Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
line_frequency: 60Hz
gain_pga: 1X
update_interval: ${update_time}
#IC1 AddOn 4
- platform: atm90e32
cs_pin: 14
phase_a:
power:
name: ${disp_name} CT25 Watts
id: ct25Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_b:
power:
name: ${disp_name} CT26 Watts
id: ct26Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_c:
power:
name: ${disp_name} CT27 Watts
id: ct27Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
line_frequency: 60Hz
gain_pga: 1X
update_interval: ${update_time}
#IC2 AddOn 4
- platform: atm90e32
cs_pin: 25
phase_a:
power:
name: ${disp_name} CT28 Watts
id: ct28Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_b:
power:
name: ${disp_name} CT29 Watts
id: ct29Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_c:
power:
name: ${disp_name} CT30 Watts
id: ct30Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
line_frequency: 60Hz
gain_pga: 1X
update_interval: ${update_time}
#IC1 AddOn 5
- platform: atm90e32
cs_pin: 15
phase_a:
power:
name: ${disp_name} CT31 Watts
id: ct31Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_b:
power:
name: ${disp_name} CT32 Watts
id: ct32Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_c:
power:
name: ${disp_name} CT33 Watts
id: ct33Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
line_frequency: 60Hz
gain_pga: 1X
update_interval: ${update_time}
#IC2 AddOn 5
- platform: atm90e32
cs_pin: 26
phase_a:
power:
name: ${disp_name} CT34 Watts
id: ct34Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_b:
power:
name: ${disp_name} CT35 Watts
id: ct35Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
phase_c:
power:
name: ${disp_name} CT36 Watts
id: ct36Watts
gain_voltage: ${voltage_cal}
gain_ct: ${current_cal}
line_frequency: 60Hz
gain_pga: 1X
update_interval: ${update_time}
#Total Watts Main
- platform: template
name: ${disp_name} Total Watts Main
id: totalWattsMain
lambda: return id(ct1Watts).state + id(ct2Watts).state + id(ct3Watts).state + id(ct4Watts).state + id(ct5Watts).state + id(ct6Watts).state ;
accuracy_decimals: 1
unit_of_measurement: W
icon: "mdi:flash-circle"
update_interval: ${update_time}
#Total Watts AddOn1
- platform: template
name: ${disp_name} Total Watts Add-on1
id: totalWattsAddOn1
lambda: return id(ct7Watts).state + id(ct8Watts).state + id(ct9Watts).state + id(ct10Watts).state + id(ct11Watts).state + id(ct12Watts).state ;
accuracy_decimals: 1
unit_of_measurement: W
icon: "mdi:flash-circle"
update_interval: ${update_time}
#Total Watts AddOn2
- platform: template
name: ${disp_name} Total Watts Add-on2
id: totalWattsAddOn2
lambda: return id(ct13Watts).state + id(ct14Watts).state + id(ct15Watts).state + id(ct16Watts).state + id(ct17Watts).state + id(ct18Watts).state ;
accuracy_decimals: 1
unit_of_measurement: W
icon: "mdi:flash-circle"
update_interval: ${update_time}
#Total Watts AddOn3
- platform: template
name: ${disp_name} Total Watts Add-on3
id: totalWattsAddOn3
lambda: return id(ct19Watts).state + id(ct20Watts).state + id(ct21Watts).state + id(ct22Watts).state + id(ct23Watts).state + id(ct24Watts).state ;
accuracy_decimals: 1
unit_of_measurement: W
icon: "mdi:flash-circle"
update_interval: ${update_time}
#Total Watts AddOn4
- platform: template
name: ${disp_name} Total Watts Add-on4
id: totalWattsAddOn4
lambda: return id(ct25Watts).state + id(ct26Watts).state + id(ct27Watts).state + id(ct28Watts).state + id(ct29Watts).state + id(ct30Watts).state ;
accuracy_decimals: 1
unit_of_measurement: W
icon: "mdi:flash-circle"
update_interval: ${update_time}
#Total Watts AddOn5
- platform: template
name: ${disp_name} Total Watts Add-on5
id: totalWattsAddOn5
lambda: return id(ct31Watts).state + id(ct32Watts).state + id(ct33Watts).state + id(ct34Watts).state + id(ct35Watts).state + id(ct36Watts).state ;
accuracy_decimals: 1
unit_of_measurement: W
icon: "mdi:flash-circle"
update_interval: ${update_time}
#Total Watts
- platform: template
name: ${disp_name} Total Watts
id: totalWatts
lambda: return id(totalWattsMain).state + id(totalWattsAddOn1).state + id(totalWattsAddOn2).state + id(totalWattsAddOn3).state + id(totalWattsAddOn4).state + id(totalWattsAddOn5).state ;
accuracy_decimals: 1
unit_of_measurement: W
icon: "mdi:flash-circle"
update_interval: ${update_time}
#kWh
- platform: total_daily_energy
name: ${disp_name} Total kWh
power_id: totalWatts
filters:
- multiply: 0.001
unit_of_measurement: kWh
time:
- platform: sntp
id: sntp_time
I have the same issue on a configuration with hundreds of remote_receiver definitions. A way to increase (optionally) the stack size seems a sensible thing.
Any action on this? I'm running into the same problem after adding several more items to my power monitoring setup.
I'm running into the same/a similar issue on my power monitoring board. Just 1 atm90e32 with 2 phases, but panics when surfing to the web server on an ESP32s.
I'm running into the same/a similar issue on my power monitoring board. Just 1 atm90e32 with 2 phases, but panics when surfing to the web server on an ESP32s.
Are there other sensors connected to the esp32? If not you may want to try a different esp32.
Check heap
- platform: template
name: "ESP Free Heap"
lambda: |-
int heap = ESP.getFreeHeap();
return heap / 1024.0;
unit_of_measurement: "kB"
update_interval: 5s
icon: mdi:chip
Any update on this? I am also running into a bootloop with many binary sensors. The heap seems to be fine - ESP.getFreeHeap() shows 118456 before adding the sensor causing the panic which seems reasonable given that I have a display consuming 75 kB for its buffer and relatively many other things.
My problem is definitely the stack. I changed the stack size in ~/.platformio/packages/framework-arduinoespressif32@3.10004.210126/cores/esp32/main.cpp
from 8192 to 16384 and all is fine. The complete project leaves 100 kB heap after this.
@OttoWinter
I don't see a good solution of moving the global variables somewhere else. Moving them back into setup() isn't going to fix the issue, as the highest stack depth use is probably in App.setup() anyway.
Hmm, I don't really understand why an added sensor would need more of stack space. I admit that I don't know esp32, platformio nor arduino much so maybe they do things differently but on platforms I am used to a variable outside of any method is allocated in an (initialized) RAM segmet and not on stack. That seems to be confirmed asking the image
.../xtensa-esp32-elf-objdump -x firmware.elf | grep automation_2
3ffc14d4 g O .dram0.bss 00000004 automation_2
Most of them are pointers anyway and I guess they are generally setup one after another, not nested in some way, aren't they? Is there any way to pinpoint what exactly is the problem?
Thanks
The issue isn't the memory allocated globally, the issue is the stack size, most likely ESPHome not being "very" efficient in handling many components in loop task, which is everything.
Id like to know that too. I see the thing crashes quickly into the setup() call as if the stack is already full. I see no reason why it is full already though
In case you or anyone else don't know, this issue can be fixed by increasing the stack size. If you need more info on how to do that ask me here (I'm on mobile now)
Does FreeRTOS, ESP, Arduino or esphome have some way of tracking the stack usage, e.g. by pre-filling it and looking at how much was clobbered or something? I've seen things like that in other embedded OS-es.
8 kB is a lot and more likely than not this is just someone doing char foo[2048]
in some method. My prime suspect would be either the WiFi or the Home Assistant API as I had an instance of a situation where any interaction during the initial phase - but after the setup - caused a crash but it was working fine when everything settled, but of course the reality is often completely different with stack issues :)
And it still does not explain why it seems to be dependent of number of objects, that does not make much sense, unless the stack overflows into the heap or the used BSS storage making mess. That is actually a possibility as I think that I have seen messages Component already registered
before the crash, not seeing them when all was fine.
https://github.com/esphome/esphome/pull/1651 is related and there's a suggestion for how to increase the stack size.
How can I increase the stack size? The platformio.ini gets overwritten.
until https://github.com/esphome/esphome/pull/1651 is merged or something better happens, easiest solution might be editing this file...
My problem is definitely the stack. I changed the stack size in
~/.platformio/packages/framework-arduinoespressif32@3.10004.210126/cores/esp32/main.cpp
from 8192 to 16384 and all is fine. The complete project leaves 100 kB heap after this.
I'm unable to access the .platformio folder.
If you are using the ESPHome add-on it's located in the container.
Easiest way to access the container is to install the Portainer add-on. Then select the ESPHome container, then go to console
.
Main.cpp
is located here: ~/.platformio/packages/framework-arduinoespressif32/cores/esp32/main.cpp
.
I couldn't find an editor (I'm not very experienced in Linux nor Docker) so I installed it.
I want to copy my comment from https://github.com/esphome/esphome/pull/1651 to here in case someone missed it.
Increasing the stack size resolved my issue as well.
The https://github.com/esphome/esphome/pull/1651 PR does add build flags to the compile pipeline. However, I don't think -DARDUINO_LOOP_STACK_SIZE
will work yet.
After some digging, I found that we can't modify the ARDUINO_LOOP_STACK_SIZE
at compile time until https://github.com/espressif/arduino-esp32/pull/5173.
That PR was merged recently and it's part of the Arduino 2.0.0-rc1 release.
Since ESPHome is still pointing at 1.0.6
, it won't work without some changes.
Possible solutions:
arduino_version
to 2.0.0-rc1
. (latest
didn't work for me at the time of posting this).espressif/arduino-esp32
library is fully released to 2.0.0
-DCONFIG_ARDUINO_LOOP_STACK_SIZE=32768
to increase the loop stack size.As others have said, in the meantime just update the stack value inside .platformio/packages/framework-arduinoespressif32/cores/esp32/main.cpp
.
from:
xTaskCreateUniversal(loopTask, "loopTask", ARDUINO_LOOP_STACK_SIZE, NULL, 1, &loopTaskHandle, CONFIG_ARDUINO_RUNNING_CORE);
to:
xTaskCreateUniversal(loopTask, "loopTask", 32768, NULL, 1, &loopTaskHandle, CONFIG_ARDUINO_RUNNING_CORE);
It will be a manual process until things are released and updated upstream.
@aav7fl Thanks for your comment. I had to make the same manual change on my ESP32 board when adding a 2nd add-on card for the 6-channel Energy Monitor.
The following configuration changes allowed me to switch to using Arduino 2.0.0 and successfully increase the CONFIG_ARDUINO_LOOP_STACK_SIZE
to 32768
esphome:
name: power-monitor
platformio_options:
platform: https://github.com/platformio/platform-espressif32.git#feature/arduino-upstream
platform_packages:
- framework-arduinoespressif32 @ https://github.com/espressif/arduino-esp32.git#2.0.0
build_flags:
- -DCONFIG_ARDUINO_LOOP_STACK_SIZE=32768
esp32:
board: nodemcu-32s
framework:
type: arduino
version: 2.0.0
The following configuration changes allowed me to switch to using Arduino 2.0.0 and successfully increase the
CONFIG_ARDUINO_LOOP_STACK_SIZE
to 32768esphome: name: power-monitor platformio_options: platform: https://github.com/platformio/platform-espressif32.git#feature/arduino-upstream platform_packages: - framework-arduinoespressif32 @ https://github.com/espressif/arduino-esp32.git#2.0.0 build_flags: - -DCONFIG_ARDUINO_LOOP_STACK_SIZE=32768 esp32: board: nodemcu-32s framework: type: arduino version: 2.0.0
Not working on a raspberry pi 4, <<Error: Could not find the package with 'espressif/toolchain-xtensa-esp32 @ 8.4.0+2021r1' requirements for your system 'linux_aarch64'>>
I have install a complete backup in a widows virtual machine to get it working.
Thanks!
Thanks you guyz for this hard debug. @noderat the fix works for me.
"My problem is definitely the stack. I changed the stack size in ~/.platformio/packages/framework-arduinoespressif32@3.10004.210126/cores/esp32/main.cpp from 8192 to 16384 and all is fine. The complete project leaves 100 kB heap after this."
How do I actually edit this file? I tried to access it from the CLI in my home assistant but normal linux commands do not work.
"My problem is definitely the stack. I changed the stack size in ~/.platformio/packages/framework-arduinoespressif32@3.10004.210126/cores/esp32/main.cpp from 8192 to 16384 and all is fine. The complete project leaves 100 kB heap after this."
How do I actually edit this file? I tried to access it from the CLI in my home assistant but normal linux commands do not work.
I've been using noderat's solution posted above for the last few months. That way I don't need to remote into the container to make changes.
@aav7fl Regrettably I don't know how to do that either. I tried putting it in the ESPHome configuration tab in HA but it had no effect when I recompiled.
@aav7fl Regrettably I don't know how to do that either. I tried putting it in the ESPHome configuration tab in HA but it had no effect when I recompiled.
How certain are you that it's uploading the compiled firmware to the hardware you're trying to flash?
Does it error out when compiling or display any warnings?
I'm doing a manual download, then I take the .bin file and flash it with ESPHome Flasher. This is the error I get.
`Leaving... Hard Resetting... Hard resetting via RTS pin... Done! Flashing is complete!
Showing logs:
[12:06:04]Guru Meditation Error: Core 1 panic'ed (Unhandled debug exception)
[12:06:04]Debug exception reason: Stack canary watchpoint triggered (loopTask)
[12:06:04]Core 1 register dump:
[12:06:05]PC : 0x40111f84 PS : 0x00060736 A0 : 0x801177b1 A1 : 0x3ffafdc0
[12:06:05]A2 : 0x3ffb81bc A3 : 0x3ffb00d0 A4 : 0x3f401980 A5 : 0x3ffb0200
[12:06:05]A6 : 0x3ffb01d0 A7 : 0x00000008 A8 : 0x3ffb00d0 A9 : 0x3ffafdb0
[12:06:05]A10 : 0x00000001 A11 : 0x3ff9c510 A12 : 0x000000ff A13 : 0x0000ff00
[12:06:05]A14 : 0x00ff0000 A15 : 0xff000000 SAR : 0x0000001f EXCCAUSE: 0x00000001
[12:06:05]EXCVADDR: 0x00000000 LBEG : 0x400014fd LEND : 0x4000150d LCOUNT : 0xffffffff
[12:06:06]
[12:06:06]ELF file SHA256: 0000000000000000
[12:06:06]
[12:06:06]Backtrace: 0x40111f84:0x3ffafdc0 0x401177ae:0x3ffb00d0 0x401177ea:0x3ffb0160 0x400d8a75:0x3ffb01a0 0x400d8aa9:0x3ffb01d0 0x400d8add:0x3ffb0220 0x400d8c9d:0x3ffb0240 0x400e14ed:0x3ffb0260 0x400e151a:0x3ffb0290 0x400d8c4d:0x3ffb02f0 0x400e2582:0x3ffb0320 0x400f5e5e:0x3ffb1fb0 0x40089c1e:0x3ffb1fd0
[12:06:06]
[12:06:06]Rebooting...
[12:06:06]ets Jun 8 2016 00:22:57
[12:06:06]
[12:06:06]rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
[12:06:06]configsip: 0, SPIWP:0xee
[12:06:07]clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
[12:06:07]mode:DIO, clock div:2
[12:06:07]load:0x3fff0018,len:4
[12:06:07]load:0x3fff001c,len:1044
[12:06:07]load:0x40078000,len:8896
[12:06:07]load:0x40080400,len:5828
[12:06:07]entry 0x400806ac
[12:06:07]Guru Meditation Error: Core 1 panic'ed (Unhandled debug exception)
[12:06:07]Debug exception reason: Stack canary watchpoint triggered (loopTask)
[12:06:07]Core 1 register dump:
[12:06:07]PC : 0x40111f84 PS : 0x00060736 A0 : 0x801177b1 A1 : 0x3ffafdc0
[12:06:08]A2 : 0x3ffb8100 A3 : 0x3ffb00d0 A4 : 0x3f401980 A5 : 0x3ffb0200
[12:06:08]A6 : 0x3ffb01d0 A7 : 0x00000008 A8 : 0x3ffb00d0 A9 : 0x3ffafdb0
[12:06:08]A10 : 0x00000001 A11 : 0x3ff9c510 A12 : 0x000000ff A13 : 0x0000ff00
[12:06:08]A14 : 0x00ff0000 A15 : 0xff000000 SAR : 0x0000001f EXCCAUSE: 0x00000001
[12:06:08]EXCVADDR: 0x00000000 LBEG : 0x400014fd LEND : 0x4000150d LCOUNT : 0xffffffff
[12:06:08]
[12:06:08]ELF file SHA256: 0000000000000000
[12:06:08]
[12:06:09]Backtrace: 0x40111f84:0x3ffafdc0 0x401177ae:0x3ffb00d0 0x401177ea:0x3ffb0160 0x400d8a75:0x3ffb01a0 0x400d8aa9:0x3ffb01d0 0x400d8add:0x3ffb0220 0x400d8c9d:0x3ffb0240 0x400e14ed:0x3ffb0260 0x400e151a:0x3ffb0290 0x400d8c4d:0x3ffb02f0 0x400e2582:0x3ffb0320 0x400f5e5e:0x3ffb1fb0 0x40089c1e:0x3ffb1fd0
[12:06:09]
[12:06:09]Rebooting...`
This is what I'm using on the latest version of ESPHome with success:
esphome:
name: power-monitor
platformio_options:
build_flags:
- -DCONFIG_ARDUINO_LOOP_STACK_SIZE=32768
esp32:
board: nodemcu-32s
variant: esp32
framework:
type: arduino
version: 2.0.2
source: https://github.com/espressif/arduino-esp32.git#2.0.2
platform_version: https://github.com/platformio/platform-espressif32.git#feature/arduino-upstream
That doesn't work for me either :(
That doesn't work for me either :(
You're getting a guru meditation error with the above in the ESPHome config? Before you build are you doing a "Clean Build Files" in the ESPHome interface?
If I drop down to <19 sensor the flash works, and the esp check in with Home Assistant and I can browse to the page. I'm assuming I put the ESP home config in the wrong place, or maybe the compiler is not seeing the new settings?
I'm running ESP Home 2022.2.6 version
- I put the code in the ESP Home Config Page: config
This should be in the individual esp32 config, not the plugin config.
At the top of my code like this? If so that isn't compiling for me.
# Example config for when jp8-jp11 are all bridged - this connects all the voltage channels and allows for power to be calculated by the meter directly.
# Boards >= v1.4 jp8-jp11 are removed and have all voltage channels connected
# 1 add-on board
esphome:
name: power-monitor
platformio_options:
build_flags:
- '-DCONFIG_ARDUINO_LOOP_STACK_SIZE=32768'
esp32:
board: nodemcu-32s
variant: esp32
framework:
type: arduino
version: 2.0.2
source: https://github.com/espressif/arduino-esp32.git#2.0.2
platform_version: >-
https://github.com/platformio/platform-espressif32.git#feature/arduino-upstream
substitutions:
# Change the disp_name to something you want
disp_name: powermon
# Interval of how often the power is updated
update_time: 10s
# Current Transformers:
# 20A/25mA SCT-006: 11143
# 30A/1V SCT-013-030: 8650
# 50A/1V SCT-013-050: 15420
# 80A/26.6mA SCT-010: 41660
# 100A/50ma SCT-013-000: 27518
# 120A/40mA: SCT-016: 41787
# 200A/100mA SCT-024: 27518
current_cal: '27518'
# Jameco 9VAC Transformer:
# For meter versions:
# >= v1.3: 7305
# <= v1.2: 42620
voltage_cal: '7305'
esphome:
name: powermon
platform: ESP32
board: nodemcu-32s
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# mqtt:
# broker: !secret mqtt_broker
# username: !secret mqtt_user
# password: !secret mqtt_pass
# Enable logging
logger:
# Enable Home Assistant API
api:
Yes, just take out the second esphome
That did the trick. Thank you!
Just ran into this myself as I'm adding about 100 Home Assistant sensors to be displayed on an e-ink display. Working backward from a continuous reboot cycle when I added the "n+1" sensor wasn't easy - but this thread did the trick. Thanks!!
Guys I've applied the wisdom found in this thread to my ESPhome code (I used @noderat suggested code block), but I've hit a new problem that has created. When starting compilation with ESPhome I get a fatal error related to an unfound package. Anyone got a tip on how to sort that out ?
Configuring from remote
I'm running ESPhome on an Raspberry Pi 4B and HASSOS...
@mountainbiker54 @CircuitSetup @lux4rd0 @emudryj could you check if #3577 fixes your issue by reducing the stack usage?
@jpeletier Is there a prebuilt docker container for your PR to test with? Or will I need to build it myself to run/compile/test?
@aav7fl there you go: docker pull epiclabs/esphome:fix-885
@jpeletier Thanks! It was a success for me. 🥳
I left a comment over on #3577.
Easy way to test this thanks to @lux4rd0 is:
((removed - please see next comment ))
Those of you using my fix, please change to the following:
external_components:
- source: github://epiclabs-uc/esphome@fix-885-old
components: wifi
refresh: 0s
Otherwise it will fail to compile now.
This is due to formal changes in the PR that have dependencies with esphome's code generation, not in the way it essentially works. In any case, the above yaml snippet will keep your stuff running exactly as it was.
+1 for this issue, I am affected by this, in my case I needed to use both @jpeletier and @noderat solutions for my project to work. Also, it is generating a lot of warnings of type:
~/.platformio/packages/framework-arduinoespressif32@src-afacabbe58d012c05a6ee24950dc6ba1/tools/sdk/esp32/include/config/sdkconfig.h:68: warning: "CONFIG_ARDUINO_LOOP_STACK_SIZE" redefined
#define CONFIG_ARDUINO_LOOP_STACK_SIZE 8192
<command-line>: note: this is the location of the previous definition
Operating environment/Installation (Hass.io/Docker/pip/etc.):
Docker/hassio in Ubuntu X86
ESP (ESP32/ESP8266, Board/Sonoff):
NodeMCU ESP32 expressif ESP32-WROOM-32D
Tried with ESPhome 1.14.2, 1.14.3 and 1.15dev getting similar results with all of them I also tried OTA and serial communication flashing, again, with similar results
The issue seems to be similar to #836 after the compile fix. I assumed that since 1.14.3 addressed that issue, it would also fix my problem, but it made no difference.
Affected component:
I'm fairly new to all this, not sure how to answer. atm90e32 maybe? I think you refer to the Circuit Setup 6 channel energy monitor board
Description of problem: When uploading config YAML file with config for more than four power monitor boards the ESP32 enters a constant boot loop
Problem-relevant YAML-configuration entries:
Logs (if applicable):
Additional information and things you've tried: Since everything seemed to work fine with the basic connectivity config, I tried to upload the YAML file little by little. Everything works fine until I get over line 360 (sometimes 400, but most of the time line360). If I try to upload anything over that, the ESP32 enters in a boot loop, with the console error detailed above and all connectivity is lost, until flashed again through serial.
Please, do not hesitate to contact me if you have ANY question.