If I was you I would make a test setup to make just that post with 10s interval. But keep it completely static, and remove everything else.
- http_request.post:
url: "https://api.telegram.org/bot${telegram_token}/sendMessage"
json:
chat_id: ${telegram_chat}
text: "*Warning: Door is OPEN *"
parse_mode: "Markdown"
Set the logger to debug for http_request and observe your logs how it’s going and how long it takes.
SSL is hard bone for esp
Gotcha makes sense, thanks for still sticking around. Will try that. The interval is about receiving message, not the sending. So will try simplifying that.
Okay it’s now more than 24h without the firmware going blank. It’s restarted 2-3x due to lost connection, but recovered every time. In the original version, it’d sometimes go blank at least once in 24h after that restart.
I removed the JSON parsing in the interval http request & adding more debugging, but the debugging doesn’t really show anything.
So now it’s kinda strange how just having that JSON parsing can mess my ESP32 so much.
Meanwhile restoring back the JSON parsing would always get me this (moments before the firmware blanking):
INFO Successfully connected to smart-door @ 192.168.0.125 in 0.204s
INFO Successful handshake with smart-door @ 192.168.0.125 in 0.040s
[10:01:08.808][E][http_request.idf:207]: HTTP Request failed; URL: https://api.telegram.org/bot?????????:@@@@@@/getUpdates?offset=-1&limit=1; Code: -1
[10:01:08.819][E][component:314]: http_request set Error flag: unspecified
INFO Processing unexpected disconnect from ESPHome API for smart-door @ 192.168.0.125
WARNING Disconnected from API
INFO Successfully resolved smart-door @ 192.168.0.125 in 0.171s
INFO Successfully connected to smart-door @ 192.168.0.125 in 0.023s
Hi, nice to see you got it working. The lambda functions was my sole reason to start making fully programmed version of parsing as esp32+esphome+lambda is notorious for memory/ latency etc. Fun times!