mirror of
https://github.com/tzapu/WiFiManager.git
synced 2026-04-27 17:15:53 +03:00
[GH-ISSUE #880] crash when trying to connect to MQTT server #743
Labels
No labels
📶 WiFi
🕸️ HTTP
Branch
DEV Help Wanted
Discussion
Documentation
ESP32
Example
Good First Issue
Hotfix
In Progress
Incomplete
Needs Feeback
Priority
QA
Question
Task
Upstream/Dependancy
bug
duplicate
enhancement
invalid
pull-request
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/WiFiManager#743
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @TinajaLabs on GitHub (May 5, 2019).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/880
Getting a crash on a wemos d1 mini (and also on the Feather Huzzah ESP8266 ) after a few minutes of the device trying to reconnect to the wifi router. The router's running openwrt and is about 8 feet away, so I doubt it's a problem with OTA connectivity.
I'm trying to make a room sensor with a collection of sensors (temp, humidity, pir, light level) and associated libraries -
WifiManager("version": "1.0.0" - from library.json),MQTT(pupsub),DHT22(temp/humidity),TSL2561 (lux), and aPIRsensor.Below is the list of libraries I use to accomplish this. I'm trying to understand any interaction between these libs. I've read that the FS library needs to always be first one defined. Are there any others that need to be sequenced in the order?
The code compiles fine and doesn't seem to be related to a memory problem:
Thanks for any tips,
Chris.
The error stack... in case it's meaningful to anyone. First some normal output, then a few dozen attempts to reconnect then - boom.
@TinajaLabs commented on GitHub (May 5, 2019):
Just happened again, and this is the lead up to the crash:
@tablatronix commented on GitHub (May 6, 2019):
see if you have time to decode the stack trace, it will tell you exactly where its crashing
@TinajaLabs commented on GitHub (May 8, 2019):
Just learned how to decode the stack trace. Please see below. This is a more recent crash, not from the prior post.
It is revealing. I added a check with
Serial.println(ESP.getFreeHeap());and it shows a slow reduction in free memory.Is there a trick to tell where the memory leak is happening?
Thank you,
Chris.
@TinajaLabs commented on GitHub (May 8, 2019):
Happened again when It was
Attempting connection to MQTT server: 192.168.1.138...Heapfree starts at
39344and is33344just before the crash. It took less than 5 minutes to happen and@TinajaLabs commented on GitHub (May 8, 2019):
And another after about an hour and 10 minutes of running OK:
Memory went from 40668 to 35408. It happened right after it's attempt to connect:
TL: Attempting connection to MQTT server: 192.168.1.138... Not connected, error code: -2... then
@tablatronix commented on GitHub (May 8, 2019):
are you writing to spiffs over and over ?
What are you using spiffs for?
is there a loop that updates some variables than then get saved ?
@TinajaLabs commented on GitHub (May 8, 2019):
I do write to the file system with spiffs library to save 2 parameters (as json), the MQTT server, and the location part of the topic string (e.g., ) for the calls being made when published. These are accessed in setup and during a reset when running wifimanager.
My code for my room sensor - PIR, TSL2561 (lux/light), DHT22 (temp, humidity), RSSI + MQTT and wifimanager.
It's a tedious bit of code, but I've broken out much of the bits into separate methods.
The key parts:
Variables:
I don't expect anyone to go through this code in any detail, but I appreciate any insights into where I'm going wrong here.
BTW, I'm hoping to show how this can work at Maker Faire next week.
Thank you,
Chris.
@TinajaLabs commented on GitHub (May 8, 2019):
Things I've done to try and fix the problem...
Aligned the variables associated with the payload value when publishing to MQTT.
Changed code like this:
to this:
Changed timer variables that change within the loop from
longtounsigned long.@tablatronix commented on GitHub (May 9, 2019):
Lots of code lol
Are you closing spiffs when done with it?
Are you passing any of those large char to a async pub func as refs
Are you creating any objects on loops say wifimanager?
I would reduce the complexity, bug could be any one of those sensor libraries, make your code so you can disable large pieces maybe use includes or defines also add a debugging wrapper.
Put a debug log call at every benchmark function say debug func name then in debuglog you can output memory logging and try to narrow it down.
@TinajaLabs commented on GitHub (May 9, 2019):
@TinajaLabs commented on GitHub (May 9, 2019):
The above is an image of the free heap over the afternoon. The code reboots after the crash. Once the leak starts it cascades out over about 15 minutes and eventually chokes.
The room sensor sends mqtt data (the publish routines) to node-red and node-red forwards to grafana.
Obviously I don't know where the leak is happening, but I'll look at your advice and see where I can inject a peek at the memory status. The tedious part is that, as you can see in the chart, it takes about an hour to an hour and a half to start the memory leak cascade... ugh.
Thank you.
@tablatronix commented on GitHub (May 9, 2019):
Yeah that is hard to debug, at least its not 24 hours..
maybe you can log what it was doing when the memory starts to change beyond a nominal value, and catch it that way, maybe you get a different response from something, maybe you hit a rate limit threshold
@tablatronix commented on GitHub (May 9, 2019):
I would also remove all string operations for testing, those strcat for example, and use dummy messages
@tablatronix commented on GitHub (May 9, 2019):
I would also suspect anything that you are doing repeatedly like getting something from a class or library, in case the leak in inside one of those, could even be in side esp lib.
ALSO
never use loops in esp
while (!Serial)
; // wait for serial monitor to open
these are all bad for the watch dog, make sure there is a yield in every loop
@dontsovcmc commented on GitHub (May 9, 2019):
@TinajaLabs a use MQTT with WiFiManager without problems. It can be a bug in char arrays operations...
This is a code in my project: https://github.com/dontsovcmc/waterius/blob/master/ESP8266/src/sender_mqtt.h
I don't use SPIFFS, maybe some heap problems...
I also had a bugs with arrays and dangerous functions that don't check null terminators.
And my favourite bug is unsigned/signed arithmetic... Every operations with millis() should be unsigned..
Refactor idea:
You needn't call setTopicsDevices
You can build topic realtime.
@TinajaLabs commented on GitHub (May 11, 2019):
Evgeny,
You have advised a refactoring similar to what I have just done. I refactored all the parts where I used
snprintfand it has been running for a few hours now without any change to the HeapFree value. We'll see if it holds.Instead of using the approach where I use something like this:
I am using this:
Also, your approach to create the concatenated topic string, real-time, with String(type) cast looks very efficient. My thought was to create all the topic strings within the setup and thereafter when I need them, they already exist.
As you can probably see all of the topic string manipulation is so I can use wifimanager to update the location part in the field. The rest of the topic is embedded and is associated with the set of sensors and values built into the device.
Thank you for your help,
Chris.
@TinajaLabs commented on GitHub (May 11, 2019):
Ach...
How does one read the stack? Top to bottom, bottom to top? Is this an exact trace through to the actual lines where the error occurred?
I see references to spiffs which I executed early on when launching the application. Perhaps that should be removed per Evgeny's suggestion. What is the alternative to persisting data on esp8266?
Thanks.
@bkrajendra commented on GitHub (May 12, 2019):
Hi @TinajaLabs , The best MQTT client i used till date is https://github.com/256dpi/arduino-mqtt
It does not have much features, but its light weight and has TLS support. Im using it with my mosquito broker in cloud..!
I also get these issues with Latest release of Arduino Esp8266 core and wifimanager not working together but everytime there was some or other issue i resolved by using some best practices.
Knowing the flow of code and laying things as per it.!
For example once I was having crashing issue with it, I figured it out was due to mDns. If i do mdns before mqtt begin, it used to crash. I resolved it by putting latter.
Next i did not understood but it was unable to connect if i use string for client id and topic. So made sure to convert those string with .c_str(), which resolved issue. I dont undesrstood the exact reson behind this or might be it was related to something else but it worked.
Recently everything was ok. But my server was refusing to connect. Now my code is similar to yours. Complex and long, im using for my IoT hardware... nothing was changed from previous code, but still it was refusing to subscribe or sometime wont connect.
After lot of tries i decide to put a scheduler delay to start mqtt connection after everything finishes on boot. using library https://github.com/Toshik/TickerScheduler
And everything started working fine.
Hope this might help you!
@SteveRMann commented on GitHub (Aug 14, 2019):
Don't know if you fixed this, but I just had the same issue.
In these lines:
myWifiClient must be unique within your LAN. If you have another device connecting to PubSubClient, it's client name has to also be unique.