Using your course I built a web socket server for an IOT application. It works fine on the bench. When deployed, it has a WiFi connection to an access port on a mesh network (CloudTrax) which is one hop from the router, but not a gateway (the RSSI is -57). The IP is correctly assigned by the main router, and is seen on the router table. If the client is on the same AP it works, but it does not work from the associated wired Network or if the client is attached to another AP. When attached to a Gateway AP, it works from anywhere. Other devices, such as an Arlo Camera and a Rain Machine do work fine when attached to the one-hop AP. Any thoughts?
I’m sorry, but I’m not familiar with those kind of issues as I never had to deal with a setup like that.
I found this question that seems similar to yours: https://esp32.com/viewtopic.php?t=19868
But, it doesn’t have any answers…
I found this comment by one of our readers related to a similar issue, but I’m not sure if it helps:
“I have followed your advice regarding assigning a static IP to the ESP, however this was unsuccesful. What i did find out is the following:
Im using a Fritz Repeater. When the esp32 is working correctly with wifi the funkchannel in the repeater is channel 1. When the esp32 stops working i have checked the channel in the repeater has automatically changed to channel 11.
In order to solve this issue one should configure the repeater not to change channels automatically. I have read in some forum the ESP’s work ideally with channels < 10.
I still havent changed the channel but I have come one step closer to the solution.
thanks for your help”
I’m sorry that I couldn’t help much.
Thank you, Sarah. I have done some additional research on this that I would like to share. It appears that there are multiple problems that can arise using websockets over mesh access points and/or various kinds of proxy servers. Many of these devices (especially older ones) do not understand web sockets and long-life connections, and will block traffic or fail to recognize messages. In addition, vendor-specific issues, such as sleep modes channel switching, and abandonment protocols may cause the access point to disconnect a client from which no recent message has been received. I am going to try changing my application to a polling interface, and see if that corrects the problem. I will let you know the results. In the meantime, it might be best for developers to do some pre-testing if they are going to deploy an application over a mesh network or through any kind of local proxy server.