-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Calling syslog.log too early in the boot process prevents esp8266 from booting #7
Comments
Humm this is interesting, I don't really know what's going on here. |
I hooked up a serial connection tonight to see what's going on and it appears calling syslog.log early is creating a boot loop.
And after 10 unsuccesful boot attempts:
|
Thanks, I think I'll have time to look at it this weekend, hopefully I can find the cause |
I think I've found the cause, but I'm not convinced I have a good solution. I modified syslog_component.cpp to add some serial logging and commented out the syslog.log call as follows:
During the boot event I see the following: |
My guess is that the Wi-Fi client is initialized but not actually connected yet. Causing the crash the moment it tries to send |
I thought that might be the case too, however testing that theory just now (I included ESP8266WiFi.h and tested for WiFi.Status()) and it's returning a state of WL_CONNECTED. I'm getting out of my depth at this point unfortunately. |
I believe I am experiencing something similar. After installing the code and using the below config my esp won't boot at all. Hooking up directly with serial, looks like the wifi cant be found anymore?? Stuck in a loop until the fallback AP kicks in then dies again. FYI - In the end I commented out the config to get the board to boot again |
Odd. I moved the syslog location after the wifi startup and now the board boots fine!! Thanks for an esphome syslog ability :-)
|
Weird, maybe the upload got corrupted at some point because the order of the YAML should have any impact as you need to specify the order manually in the component (See |
@pmannk So fixing the boot loop was dead simple: Now, I changed the priority to |
Ok, so I was wrong there is internet, and the logs are being sent if the priority is -100 (had a wrong filter on my server).
Here is what I think is going on when using
To solve this, I choose to simply init But for some reason, WifiUDP still errors out with Bit more work, commits one way |
Error 12 is The thing is I don't have a esp8266 that I can plug on my computer right now but uploading the new version to an already running one seems to work even with a lot of messages. So I guess the udp implementation is better 🥳. I'll add a warning for the esp32 because it's not something I can fix easily (would require either that the arcao/Syslog lib to actually realize that there is an issue or that esphome compiles with a bigger buffer and I'm not sure on how it will impact other things) |
Here we go, this should be fixed, please let me know if there is still an issue. Sorry it took so long 😅 |
works perfectly for me now!! Thanks for the great work :-) FYI, I downloaded the new code and put the config back to "normal" as below.
|
Nice one, that did the trick. I can't trigger the fault anymore. |
Hi there!
Firstly thanks for this great component, I've been using it to log time-based events and it's been very useful.
This evening I stumbled on a scenario where I believe esphome_syslog prevents an esp device from booting successfully.
In this scenario the esphome api, web_server and remote logger all stop functioning. Fortunately OTA is still available.
I have a script which is called by "on_boot" and under normal circumstances it never calls syslog.log until well after the esp boots, time syncs, api connects, etc.
Tonight the script tried to call syslog.log immediately after a reboot and that's where things went awry.
I use the following syslog configuration:
The following on_boot reproduces the problem:
This on_boot also causes issues:
However this on_boot works fine:
I can see you have return setup_priority::LATE; defined, so I'm not sure where else to go looking for the cause of this issue.
For the moment I have a workaround in place (testing for api.connected anywhere that I call syslog.log).
Thanks!
The text was updated successfully, but these errors were encountered: