momu/esp32-alarmlicht

ESPHome basierte, automatisierte Alarmauslösung über einen http request bei Alarmierung eines Melders in einer LGRA Ladestation.

esp32-alarmlicht's Issues

[feature] when http request fails, implement some retry logic

Sometimes the http request fails with status -2. In this case no http request is sent and no Divera alert is created. To prevent loosing alerts, the response code of a http request should be checked and if it is not 200 or 429 (to many request in the 5 minute interval) there should be some (definable) retries.

[15:26:06][D][binary_sensor:036]: 'DME Relais': Sending state ON
[15:26:06][I][main:1059]: Pager received a message
[15:26:06][I][main:008]: Sending Divera alert.        
[15:26:06][I][main:019]: Response status: -2, Duration: 3 ms
[15:26:07][W][http_request:087]: HTTP Request failed; URL: https://www.divera247.com/api/alarm?accesskey=<redacted>; Error: send header failed; Duration: 3 ms
[15:26:16][D][binary_sensor:036]: 'DME Relais': Sending state OFF
[15:26:37][D][binary_sensor:036]: 'DME Relais': Sending state ON
[15:26:37][I][main:1059]: Pager received a message
[15:26:38][I][main:008]: Sending Divera alert.
[15:26:40][I][main:019]: Response status: 200, Duration: 2093 ms
[15:26:40][D][http_request:099]: HTTP Request completed; URL: https://www.divera247.com/api/alarm?accesskey=<redacted>; Code: 200; Duration: 2093 ms
[15:26:40][W][component:214]: Component binary_sensor took a long time for an operation (2.12 s).
[15:26:40][W][component:215]: Components should block for at most 20-30ms.
[15:26:44][D][binary_sensor:036]: 'DME Relais': Sending state OFF

Testing

• change the api key
• issue a test alert
• http response should be 403
• check if the http request is retried N times

[bug] frequent wifi disconnects every 30 mins

The wifi connection is pretty unstable, but predictable. It disconnects every 30 mins for 1-2 s.

Logs

[16:51:58][W][wifi:138]: WiFi Connection lost... Reconnecting...
[16:51:58][W][wifi_esp32:458]: Event: Disconnected ssid='<SSID>' bssid=AA:BB:CC:DD:EE:FF reason='Unspecified'
[16:51:58][W][wifi_esp32:458]: Event: Disconnected ssid='<SSID>' bssid=AA:BB:CC:DD:EE:FF reason='Authentication Failed'
[16:51:58][W][wifi:607]: Connecting to WiFi network failed. Are the credentials wrong?
[16:52:09][I][wifi:487]: - '<SSID>' (AA:BB:CC:DD:EE:FF) ▂▄▆█
[16:52:09][I][wifi:277]: WiFi Connecting to '<SSID>'...
[16:52:09][W][wifi_esp32:458]: Event: Disconnected ssid='<SSID>' bssid=AA:BB:CC:DD:EE:FF reason='Association Leave'
[16:52:09][W][wifi:612]: WiFi Unknown connection status 0
[16:52:09][I][wifi:277]: WiFi Connecting to '<SSID>'...
[16:52:09][W][wifi_esp32:458]: Event: Disconnected ssid='<SSID>' bssid=AA:BB:CC:DD:EE:FF reason='Association Failed'
[16:52:09][W][wifi_esp32:458]: Event: Disconnected ssid='<SSID>' bssid=AA:BB:CC:DD:EE:FF reason='Association Failed'
[16:52:09][W][wifi:591]: Error while connecting to network.
[16:52:09][W][wifi:627]: Restarting WiFi adapter...
[16:52:09][W][component:214]: Component wifi took a long time for an operation (0.11 s).
[16:52:09][W][component:215]: Components should block for at most 20-30ms.
[16:52:21][I][wifi:487]: - '<SSID>' (AA:BB:CC:DD:EE:FF) ▂▄▆█
[16:52:21][I][wifi:277]: WiFi Connecting to '<SSID>'...
[16:52:22][I][wifi:560]: WiFi Connected!
[16:57:40][I][main:578]: Light switched on by remote control.
[16:59:18][I][main:578]: Light switched on by remote control.
[17:22:25][W][wifi_esp32:458]: Event: Disconnected ssid='<SSID>' bssid=AA:BB:CC:DD:EE:FF reason='Unspecified'
[17:22:25][W][wifi:138]: WiFi Connection lost... Reconnecting...
[17:22:25][I][wifi:277]: WiFi Connecting to '<SSID>'...
[17:22:26][I][wifi:560]: WiFi Connected!

Ping

243 packets transmitted, 240 received, 1.23457% packet loss, time 242295ms
rtt min/avg/max/mdev = 75.584/91.944/189.828/25.980 ms

138 packets transmitted, 136 received, 1.44928% packet loss, time 137218ms
rtt min/avg/max/mdev = 78.068/120.949/207.613/25.195 ms

To Do

• put logs here
• check connectivity/link quality by pinging the esp
• set power saving mode (https://esphome.io/components/wifi.html#power-save-mode) to none according to https://community.home-assistant.io/t/esp32-disconnects/370258/9 -> did not solve it
• add some magic to catch alerts during wifi disconnects and process them once wifi is back

[bug] software crashes when making http requests

When using the configuration as in 896cde2 an triggering a test alert using the testbutton, the devices crashes and reboots when sending an http request to http://ntfy.sh immediatly after sending a successful request to Divera.
Could be related to esphome/issues#2853.

First workaround is to disable the ntfy request and set the timeout for the http component to 1 s.

Log with loglevel: DEBUG

[20:57:10][C][mdns:116]:   Hostname: esp-alarmlicht
[20:57:10][C][http_request:014]: HTTP Request:
[20:57:10][C][http_request:015]:   Timeout: 5000ms
[20:57:10][C][http_request:016]:   User-Agent: esphome/esp-alarmlicht
[20:57:10][C][http_request:017]:   Follow Redirects: 1
[20:57:10][C][http_request:018]:   Redirect limit: 3
[20:57:28][D][binary_sensor:036]: 'BUT1': Sending state ON
[20:57:28][D][main:512]: Button BUT1 pressed
[20:57:28][D][binary_sensor:036]: 'BUT1': Sending state OFF
[20:57:28][D][main:016]: Sending Divera test alert.
[20:57:31][D][main:027]: Response status: 429, Duration: 2721 ms
[20:57:31][W][http_request:093]: HTTP Request failed; URL: https://www.divera247.com/api/alarm?accesskey=<redacted>; Code: 429; Duration: 2721 ms
[20:57:31][D][main:024]: Sending ntfy test alert.
[20:57:33]E (45555) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
[20:57:33]E (45555) task_wdt:  - loopTask (CPU 1)
[20:57:33]E (45555) task_wdt: Tasks currently running:
[20:57:33]E (45555) task_wdt: CPU 0: IDLE
[20:57:33]E (45555) task_wdt: CPU 1: loopTask
[20:57:33]E (45555) task_wdt: Aborting.
[20:57:33]abort() was called at PC 0x400ea529 on core 0
[20:57:33]Backtrace:0x40083881:0x3ffbe9bc |<-CORRUPTED
WARNING Found stack trace! Trying to dhttps://github.com/esphome/issues/issues/2853ecode it
WARNING Decoded 0x40083881: panic_abort at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/esp_system/panic.c:402
[20:57:33]ELF file SHA256: 0000000000000000
[20:57:33]Rebooting...
[20:57:33]ets Jul 29 2019 12:21:46
[20:57:33]rst:0xc (SW_CPU_RESET),boot:0x1b (SPI_FAST_FLASH_BOOT)
[20:57:33]configsip: 0, SPIWP:0xee
[20:57:33]clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
[20:57:33]mode:DIO, clock div:2
[20:57:33]load:0x3fff0030,len:1184
[20:57:33]load:0x40078000,len:13132
[20:57:33]load:0x40080400,len:3036
[20:57:33]entry 0x400805e4
[20:57:33][I][logger:326]: Log initialized
[20:57:33][I][app:029]: Running through setup()...
[20:57:33][D][binary_sensor:034]: 'Funklicht': Sending initial state OFF
[20:57:33][D][binary_sensor:034]: 'BUT1': Sending initial state OFF
[20:57:33][D][binary_sensor:034]: 'DME Relais': Sending initial state OFF

Log with loglevel: INFO

[21:00:38][I][wifi:560]: WiFi Connected!
[21:00:38][I][app:062]: setup() finished successfully!
[21:00:38][I][app:102]: ESPHome version 2023.10.4 compiled on Nov  2 2023, 20:59:39
[21:00:58]E (39574) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
[21:00:58]E (39574) task_wdt:  - loopTask (CPU 1)
[21:00:58]E (39574) task_wdt: Tasks currently running:
[21:00:58]E (39574) task_wdt: CPU 0: IDLE
[21:00:58]E (39574) task_wdt: CPU 1: IDLE
[21:00:58]E (39574) task_wdt: Aborting.
[21:00:58]abort() was called at PC 0x400e9aa1 on core 0
[21:00:58]Backtrace:0x40083881:0x3ffbe9bc |<-CORRUPTED
WARNING Found stack trace! Trying to decode it
WARNING Decoded 0x40083881: panic_abort at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/esp_system/panic.c:402
[21:00:58]ELF file SHA256: 0000000000000000
[21:00:58]
[21:00:58]Rebooting...
[21:00:58]ets Jul 29 2019 12:21:46

[feature] add health status via http request

For having an understanding of the overall health status, http requests on ntfy.sh can be used.
Parameters to be logged:

• uptime
• memory
• wifi reconnects
• alerts received/processed

The interval should be configurable and the logged events should be only account during this interval (resetted when submitted).

[feature] remember alerts when there is no wifi

Some of the alerts are missed. This is most likely due to no wifi connection during the alert.

• add variables for alert event and type of alert
• set them on alert
• reset them on wifi reconnect
• test it
  • testalert (only ntfy)
  • alert (only ntfy)
  • testalert (only divera)
  • alert (only divera)
  • all strings are correct
  • interrupt wifi
  • trigger testalert (ntfy only)
  • check if alarm is pending
  • restore wifi connectivity
  • testalert (ntfy is triggered)
  • interrupt wifi
  • trigger alert (ntfy only)
  • check if alarm is pending
  • restore wifi connectivity
  • alert (ntfy is triggered)
  • interrupt wifi
  • trigger testalert (divera only)
  • check if alert is pending
  • restore wifi connectivity
  • testalert (divera is triggered)
  • interrupt wifi
  • trigger alert (divera only)
  • check if alert is pending
  • restore wifi connectivity
  • alert (divera is triggered)

Build this thing and document it

Documentation

• BOM
• connection scheme (fritzing?)
• esphome setup

Code

• two wifis
• secrets in .gitignore
• when button is pushed, a test alarm on divera should be triggered
• when relays is closed on docking station, trigger two different http requests

Hardware

• pullup (10 k) with 220R protection