Open ychieux opened 6 months ago
I believe, I found the root cause... the valves' run duration was set to 10sec for testing purposes while the overlap was set to 5s i.e. exactly half the valve run duration. This led to a situation where timers failed when transitioning from valve no 2 to 3.
I'm not sure If I had the same root cause, but my board crash when I do monkey test and switch manually my zones fast on web server ui or by pressing the next valve button.
Sometimes controller do not switch off previous zone and enable the next one, then attempting to switch to the next zone, crash the system:
Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled.
Core 1 register dump:
PC : 0x400e0d90 PS : 0x00060f30 A0 : 0x8018c404 A1 : 0x3ffb2770
A2 : 0x3ffb46e4 A3 : 0x00000000 A4 : 0x3ffb4880 A5 : 0x0000a540
A6 : 0x3ffb2754 A7 : 0x0000000a A8 : 0x800e0d82 A9 : 0x3ffb2750
A10 : 0x3ffb4850 A11 : 0x00000000 A12 : 0x000493e0 A13 : 0x00060323
A14 : 0x00060320 A15 : 0x00000001 SAR : 0x0000000a EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000028 LBEG : 0x400849ad LEND : 0x400849b5 LCOUNT : 0x00000027
Backtrace:0x400e0d8d:0x3ffb27700x4018c401:0x3ffb2790 0x4018c49d:0x3ffb27b0 0x400ebc28:0x3ffb27d0 0x400ef0d6:0x3ffb2800 0x401038e5:0x3ffb2820
My initial sprinkler configuration is like:
sprinkler:
- id: $devicename
valve_open_delay: 1s
next_prev_ignore_disabled: true
pump_switch_off_during_valve_open_delay: false
main_switch:
id: main_switch
name: "Start/Stop/Resume"
icon: "mdi:play-pause"
web_server_sorting_weight: 1
standby_switch:
id: standby_switch
name: "Standby"
icon: "mdi:play-pause"
web_server_sorting_weight: 1
auto_advance_switch:
name: "Auto Advance"
icon: "mdi:brightness-auto"
web_server_sorting_weight: 2
repeat_number:
name: "Repeat Cycles"
mode: box
icon: "mdi:repeat"
web_server_sorting_weight: 3
initial_value: 0
min_value: 0
max_value: 10
step: 1
restore_value: true
disabled_by_default: false
entity_category: config
multiplier_number:
name: "Multiplier number"
mode: box
icon: "mdi:multiplication"
web_server_sorting_weight: 5
initial_value: 1
min_value: 0.1
max_value: 10
step: 0.1
unit_of_measurement: $uom
restore_value: true
disabled_by_default: false
entity_category: config
valves:
....
I don't use valve_overlap settings.
Moreover when I set valve_open_delay to 4s and play with switches it's even faster when It's crash. Also when I notice in web ui that two zones are on and switch one of them off and press next button then esp not crash but when run_duration time for that zone elapsed then it crash.
For me it looks like controller keeps some old reference about previous zone and try to switch it off when is already off and then crash on that.
So definitely something wrong with valve_open_delay and switches state.
BTW: I also notice that controller have issues when activate more then one zone at a time eg. Activate zone 1 switch on web ui, then before it change his state to on, activate zone 2, wait a bit and controller will activate both zone at the same time and this should not be allowed ;(
Edit: After discord support I put below more details of my crash for other viewers that can find this issue: Dump decoded by: esp-stacktrace-decoder
Crash in area of sprinkler.cpp#L411-L413, probably due sprinkler.cpp#L355-L360
I still see the problem in ESPHome 8. I run sprinkler zones separately based on moisture needs so auto advance is turned off. I get the same panic issue. It seems to happen when transitioning from one zone to another but I can't pinpoint the exact scenario to recreate it, because it doesn't always occur.
The problem
ESP32 crashes and reboots when running a cycle. I ran the same YAML on an ESP8266 based board and get the same crash/reboot while running an irrigation cycle.
Which version of ESPHome has the issue?
2024.4.1
What type of installation are you using?
Home Assistant Add-on
Which version of Home Assistant has the issue?
2024.4.4
What platform are you using?
ESP32
Board
LILYGO T-Relay ESP32 (4ch with ESP32-WROOM-B)
Component causing the issue
Sprinkler Controller
Example YAML snippet
Anything in the logs that might be useful for us?
Additional information
No response