The orientation of the node may also have an impact.
For example, most antennas for WiFi have a vertical polarization.
Meaning that it will cover an area in the horizontal plane around the antenna.
If the node does have its radiation pattern not in the same plane, you will loose a lot in your signal-noise-ratio, although the RSSI may appear similar.
RSSI is an indication of the power of the signal, but has little to do with the "quality" or "stability" of the signal.
The radiation pattern of an ESP is also not uniform for all modules. For example a PCB trace antenna (most common) has a different radiation pattern compared to those ceramic antenna's you also see on some nodes (often white rectangular shaped) and some also have metal "3D" antenna's.
The RSSI can show some positive effect when you orient the node to have its radiation plane parallel to the radiation plane of the access point.
But you have to monitor it a number of cycles, without being near the node yourself to see its real effect.
In the core library, I can select several "SDK versions" and the one I now have active is that of July 3rd. (PIO_FRAMEWORK_ARDUINO_ESPRESSIF_SDK22x_190703)
See here in the PlatformIO definitions:
https://github.com/letscontrolit/ESPEas ... i#L98-L139
You can try the difference between "SDK3" and "SDK2.x" and I can also make you a build based on later builds of the SDK.
It does seem to make a difference in stability for nodes in a certain range of reported RSSI values.
I chose this one as it is most stable in the RSSI values you normally see. (either very low, or very bad)
Yours is probably a bit inbetween.
Apart from that there is also a difference between nodes themselves.
Maybe you could exchange the node with just any other node and use the "unstable" one in a place with different RSSI.
Another thing you may want to try and what is maybe a bit counter intuitive, is to shield the node from WiFi.
The whole idea behind it is that if you have a lower RSSI, it will connect to the access point at a lower bit rate.
I can also add some selector in the settings to force a module to only accept lower bit rates.
A lower bit rate does make it less susceptible to changes in noise.
I have the feeling that's also what makes the difference between the "July" and "November" builds of the SDK, that its preset WiFI parameters do select different bit rates (and time-out values) based on the observed RSSI at connection time.
These time out values are not made available for me to set, but the bitrates we can advertise to the access point are.
Some more elaborate access points (not more expensive as the cheapest MikroTik ones also support) do allow to show the used bit rate.
Not sure if I can show it in the status page, but maybe that's also nice to have for debugging, or at least to make it look like we do know what we are talking about
What you can do is select "Periodical send Gratuitous ARP" and "Force WiFi No Sleep".
I think the first one makes the most sense to have and even if it doesn't help, it does also no harm.
Problem is that the ESP may sometimes miss a beacon interval of the access point so also ARP requests may be missed and then the switches in the network no longer know how to reach your node.
This may make the ESP wait forever on a reply it was expecting. (N.B. an access point is also a switch)
By sending out Gratuitous ARP, you will be the one in the room continuously giving answers to questions nobody asked, so it may feel a bit socially awkward, but we're not running a "social network" here, so don't think too much about it