brandond
commented
4 years ago Looks to me like it's running out of memory. What were you doing at the time of the crash? Can it be reproduced on demand?
Closed abmantis closed 3 years ago
brandond
commented
4 years ago Looks to me like it's running out of memory. What were you doing at the time of the crash? Can it be reproduced on demand?
abmantis
commented
4 years ago I had the remote_receiver dumping raw messages, and it was receiving a lot of garbage. Maybe having that with a floating pin would reproduce this too.
samnewman86
commented
4 years ago as soon as i try to open the esp hosted web page the device crashes. this is happening on nodemcu 32 and also a sonoff 4ch pro r2
brandond
commented
4 years ago @samnewman86 the web server component has been around for quite a while, and is in general pretty stable. Can you post more information on your configuration?
abmantis
commented
4 years ago @brandond have you tried my suggestion?
netpok
commented
4 years ago Can confirm the issue it crashes for me too, only when it's open in the browser. I can reproduce the problem by refreshing the page few times but it crashes on it's own too.
I don't have access to the stack trace, I guess it is printed out to the serial port and my device is not connected to my computer (if really needed probably I can connect an other esp to forward the serial logs).
My config:
esphome:
name: watersensors
platform: ESP32
board: esp32doit-devkit-v1
wifi:
ssid: "<REMOVED>"
password: "<REMOVED>"
domain: <REMOVED>
# Enable fallback hotspot (captive portal) in case wifi connection fails
# ap:
# ssid: "ws Fallback Hotspot"
# password: "<REMOVED>"
#captive_portal:
#debug:
# Enable logging
logger:
# level: debug
baud_rate: 0
ota:
web_server:
port: 80
time:
- platform: sntp
mqtt:
broker: <REMOVED>
username: <REMOVED>
password: <REMOVED>
on_json_message:
topic: tele/lights/SENSOR
then:
- sensor.template.publish:
id: humidity
state: !lambda 'return x["SHT3X-0x44"]["Humidity"];'
switch:
# - platform: gpio
# name: LED
# id: blue_led
# pin: 2
- platform: gpio
name: "Toilet Vent"
id: toilet_vent
pin: 13
- platform: gpio
name: "Mirror Light"
id: mirror_light
pin: 12
- platform: gpio
name: "Pantry Light"
id: pantry_light
pin: 14
- platform: gpio
name: "Mirror Heating"
id: mirror_heating
command_topic: cmnd/digoo/POWER1
pin: 27
- platform: gpio
name: "Toilet Light"
id: toilet_light
pin: 15
- platform: gpio
name: "Bathroom Speaker"
id: bathroom_speaker
pin: 19
- platform: gpio
name: "Bathroom Light"
id: bathroom_light
pin: 21
command_topic: cmnd/lights/POWER3
on_turn_off:
- switch.turn_off: mirror_light
- switch.turn_off: bathroom_speaker
- platform: restart
name: "WaterSensors Restart"
dallas:
- pin: 4
update_interval: 10s
binary_sensor:
- platform: gpio
name: "Mirror switch"
pin:
number: 26
mode: INPUT_PULLUP
inverted: True
on_click:
- max_length: 1000ms
then:
- switch.toggle: mirror_light
- min_length: 2000ms
max_length: 5000ms
then:
- switch.toggle: bathroom_speaker
- platform: gpio
name: "Pantry switch"
pin:
number: 25
mode: INPUT_PULLUP
inverted: True
on_press:
- switch.turn_on: pantry_light
on_release:
- switch.turn_off: pantry_light
- platform: gpio
name: "Toilet switch"
pin:
number: 23
mode: INPUT_PULLUP
inverted: True
on_press:
- switch.turn_on: toilet_light
on_release:
- switch.turn_off: toilet_light
sensor:
- platform: dallas
address: 0xBD3C01A816748028
name: "Mixed water temperature"
- platform: dallas
address: 0xB33C01A816709D28
name: "Cold water temperature"
- platform: dallas
address: 0xF33C01A816A35728
name: "Hot water temperature"
- platform: pulse_counter
pin:
number: 34
mode: INPUT
unit_of_measurement: 'l/min'
name: 'Toilet flow rate'
id: fs1
filters:
- multiply: 0.0015
update_interval: 10s
- platform: integration
name: "Water 1"
sensor: fs1
time_unit: min
- platform: pulse_counter
pin:
number: 33
mode: INPUT
unit_of_measurement: 'l'
name: 'Flow sensor 2'
id: fs2
filters:
- multiply: 0.0015
update_interval: 10s
- platform: integration
name: "Water 2"
sensor: fs2
time_unit: min
- platform: pulse_counter
pin:
number: 36
mode: INPUT
unit_of_measurement: 'l'
name: 'Incoming water flow rate'
id: fs3
filters:
- multiply: 0.0018837
update_interval: 10s
- platform: integration
name: "Water 3"
sensor: fs3
time_unit: min
- platform: pulse_counter
pin:
number: 39
mode: INPUT
unit_of_measurement: 'l'
name: 'Flow sensor 4'
id: fs4
filters:
- multiply: 0.0015
update_interval: 10s
- platform: integration
name: "Water 4"
sensor: fs4
time_unit: min
- platform: adc
pin: 32
name: "Filtered Water Pressure"
filters:
- multiply: 1.68
- calibrate_linear:
- 0.5 -> 0.0
- 4.5 -> 12.0
attenuation: 11db
unit_of_measurement: 'bar'
update_interval: 10s
- platform: adc
pin: 35
name: "Incoming Water Pressure"
filters:
- multiply: 1.67
- calibrate_linear:
- 0.5 -> 0.0
- 4.5 -> 12.0
attenuation: 11db
unit_of_measurement: 'bar'
update_interval: 10s
- platform: template
name: "Bathroom humidity"
id: humidity
# Extra sensor to keep track of plug uptime
- platform: uptime
name: Uptime
- platform: wifi_signal
name: "Wi-Fi Signal"
update_interval: 60s
text_sensor:
- platform: version
name: firmware_versionExtra lines in the main.cpp:
// ========= YOU CAN EDIT AFTER THIS LINE =========
App.setup();
gpio_set_drive_capability((gpio_num_t)13, GPIO_DRIVE_CAP_3);
gpio_set_drive_capability((gpio_num_t)12, GPIO_DRIVE_CAP_3);
gpio_set_drive_capability((gpio_num_t)14, GPIO_DRIVE_CAP_3);
gpio_set_drive_capability((gpio_num_t)27, GPIO_DRIVE_CAP_3);
gpio_set_drive_capability((gpio_num_t)15, GPIO_DRIVE_CAP_3);
gpio_set_pull_mode(GPIO_NUM_33, GPIO_FLOATING);Removing the extra lines, sensors and additional mqtt related commands does not seem to affect the crashes.
stale[bot]
commented
3 years ago This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Operating environment/Installation (Hass.io/Docker/pip/etc.):
Arch Linux, Pip installation. ESP (ESP32/ESP8266, Board/Sonoff):
nodemcu-32s (clone probably). Affected component:
https://esphome.io/components/web_server.html
Description of problem: The web server component is calling abort(), causing the ESP to reboot.
Problem-relevant YAML-configuration entries:
Logs (if applicable):
Additional information and things you've tried: This may be caused by long or fast log messages, since I had the RC receiver enabled, dumping ray and rc_switch messages, and it was receiving a lot of them.