Replies: 16 comments 8 replies
-
Can you try with a static IP and set a DNS server (e.g. 8.8.8.8) yourself? Seems there is an issue with the DNS server your DHCP server is giving to the device. It then eventually get disconnected when connecting to the MQTT server fails. |
Beta Was this translation helpful? Give feedback.
-
I tried setting up static details, unfortunately I don't fully understand how to do so. I can change |
Beta Was this translation helpful? Give feedback.
-
Do you have an Android or Apple device? You should be able to set it with either of those apps. |
Beta Was this translation helpful? Give feedback.
-
Thank you, setting static details via Android worked fine. Unfortunately the error still persists, connection does only work for a very limited time after re-connection:
Sometimes it's the timeout, sometimes it's the DNS error that hits first. The logic seems to be to restart the WiFi device after 5 failed connection attempts to the MQTT server. The first connection to the MQTT server after restarting the WiFi device works for a couple seconds |
Beta Was this translation helpful? Give feedback.
-
Did you try different DNS servers? Maybe it's a firewall issue?
Indeed: Lines 326 to 328 in db8f8db So, yeah, if the MQTT connection fails due to DNS failures, it is expected that it tries to reconnect WiFi afterwards. Edit: Also, you mention the first connection to the MQTT server works for a couple seconds. Are you using the default channel (LongFast)? If so, there's a lot of traffic there and it might be that that is causing problems. You could try changing the channel and see if it stays connected for longer. |
Beta Was this translation helpful? Give feedback.
-
I tried 4 different routers, 2 mobile APs, different DNS servers and couple different WAN - I'd say I can exclude any "external" networking issues at this point. Maybe I was not completely clear - the absolutely first connection after a reset works fine for minutes, up to hours (max was probably around 2 hours). Every subsequent re-connect after the first disconnect will only work for seconds. To me it feels like a buffer filling up and causing issues from there. Yes, I am using the default channel. I will try on a different channel and see if things change. Update: |
Beta Was this translation helpful? Give feedback.
-
Side comment: As can be seen on the official Discord Channel Announcements, https://discord.com/channels/867578229534359593/871558934916390953 It may be on and offline sporadically. |
Beta Was this translation helpful? Give feedback.
-
@major-tweaks thanks for the heads up. I'll probably stop being a pain in the ass over the Christmas holidays anyway. |
Beta Was this translation helpful? Give feedback.
-
What I can say, I've got two HelTec V3s ESP32, one via WiFi connected (WebApp), one via BT (iOS App). |
Beta Was this translation helpful? Give feedback.
-
Should you run into an infinite WiFi reconnection loop, flash the artifacts of #3026 ;-) |
Beta Was this translation helpful? Give feedback.
-
Disabled MQTT on the WiFi connected one, disabled it also on Channel 0, switched off BT also, results in a much much more responsive client.. so there IS actually some issue with WiFi and MQTT.. no problem with just BT and MQTT. |
Beta Was this translation helpful? Give feedback.
-
I don't think that the issue is with WiFi and MQTT per say, I think the issue is "just" when you are subscribed to a busy channel. I now disabled the default channel and things are working fine - admittedly with only very little load on that channel. Would be interesting what the "breaking" point is exactly. |
Beta Was this translation helpful? Give feedback.
-
Yes, when connected to the public MQTT server on the default channel, the device is basically receiving messages non-stop and may not function properly anymore. I have already opened a PR to the documentation to warn users about this (meshtastic/meshtastic#901). Since there is not really much we can do about this, I'm closing this and converting it to a discussion if you want to discuss further. |
Beta Was this translation helpful? Give feedback.
-
The problem isn't really that wifi disconnects--many things can cause that--but that it never manages to reconnect. This makes unattended MQTT nodes impossible, at least with T-Beams (I don't know whether any other device can manage to reconnect). If you can't fix the reconnect, can you at least give us an option to reboot the device if it doesn't reconnect within X seconds? That's what I'm going to have to do anyway, so it would save time if it just rebooted itself and I didn't have to go over and press the button. Also I'm not convinced that the disconnect is load-related. Looking at the device metrics last night the load wasn't particularly high when it disconnected and it had handled much higher loads earlier in the night without problems. But again it wouldn't matter if the device could reconnect after disconnecting. |
Beta Was this translation helpful? Give feedback.
-
I'm on the latest Beta as of a few days ago. 2.2.21? I'm not sure how to get the serial output, but if you can point me toward instructions I can connect the device to a PC and capture it for you. Edit: This is a T-Beam Supreme rather than a regular T-Beam, so I don't know whether that would make a difference. It's also possible it's showing the same behaviour of reconnecting for a few seconds and disconnecting behind the scenes, but the screen only shows 'Reconnecting'. |
Beta Was this translation helpful? Give feedback.
-
I'll have to trim the logs and upload them for you but it looks like it reconnects a few times but those connections only last a few minutes, then it finally reconnects but doesn't get an IP address and just sits there forever saying Reconnecting. |
Beta Was this translation helpful? Give feedback.
-
Category
WiFi
Hardware
T-Beam
Firmware Version
#3026
Description
Follow up to #2796
After flashing artifact from #3026 WiFi is now reconnecting correctly after some time, but it only does work for a couple of seconds. I verified this by pinging the device, also DNS resolution fails when connecting to the MQTT server as can be seen from the serial log:
This is the approximate ping section belonging to the above serial log
Relevant log output
No response
Beta Was this translation helpful? Give feedback.
All reactions