Known issue - UDP messages dropped

79 views
Skip to first unread message

Mike P 4 MPP

unread,
Mar 13, 2020, 12:44:28 PM3/13/20
to MppDevices
Serg found this - the ESP8266 library (I think it's the espressif toolkit) is dropping some UDP messages at first connection over wifi.
They seem to have a startup buffer length of 3 - if you send any more than that during startup first messages get dropped and only the last 3 are sent.
It's discussed at:  https://github.com/esp8266/Arduino/issues/3481 - the last message there describes the fix.  It's a problem in ESP8266 2.4.2 (our current version) and 2.6.3 (the one I'm trying now to see if we should upgrade).  It looks like they tried to fix it in 2.5 but as a result caused the first UDP packet to always be dropped (which is why I stayed on 2.4.2).

The devices that are affected are battery type devices that wakeup and notify of status right away if they send too many UDP (notifyListener) messages quickly.
It doesn't affect non-battery devices since they tend to stay connected and it's only immediately after the initial connection.
In the existing devices it's not a problem because they don't send that many messages at startup, but if you build a custom version with more measurements you may lose the first that try to report.  
The workaround is to put a delay(250) or so after the first UDP message send (or before the 4th).

You might notice this if you enable OUTPUTIP for battery devices - the first boot up report messages may be lost -  it doesn't affect operation but can look weird.
MppGateway will capture and forward OUTPUTIP in the next version, there's something unique about the gateway connection (maybe it's faster?) that seems to make the startup loss more likely/obvious.

sergey

unread,
Mar 16, 2020, 6:32:55 AM3/16/20
to MppDevices

Frankly it was Mike, who has figured this out. :)  I've only  annoyed him with a problem!) 
Right now i can testify that delay (250) after first message combining with a delay(500) after third message (or notification) works fine (almost 95% of delivered). 
Thanks again Mike for your support!

DougC

unread,
Mar 28, 2020, 2:25:24 AM3/28/20
to MppDevices
Mike, getting OUTPUTIP through MppGateway is great. Though it can take (me) a bit of time to work out what device is saying what. I don't remember all my device's IP and MAC addresses :-) and in any case the gated device IP addresses are not really fixed.

Do you suppose it would be possible and/or useful to insert the device UDN  into the messages. Maybe right after the OUT: text?

Lone Surviver

unread,
Mar 28, 2020, 9:20:00 AM3/28/20
to MppDevices


Found this to be helpful.
In WINDOWS 
COMMAND PROMPT

arp -a

Will list everything on your network ip amd mac 

Mike P 4 MPP

unread,
Mar 28, 2020, 10:44:52 AM3/28/20
to MppDevices
The message has the device MAC and if you're monitoring with MppArduino it shows the source IP address.  Then you can use "Manage Devices", the sort button sorts by IP or a-z so it's easy to find.   Sending the device UDN feels a bit weird because the reboot message is from that MppServer rather than the 1 or more devices it's running.

Mike P 4 MPP

unread,
Apr 4, 2020, 9:52:04 PM4/4/20
to MppDevices
Found a bit of a weird problem when fiddling with assigning the wifi connection - some devices would crash and not take the updated value.. Resolved it by using the USB command "eraseConfig" which wipes the ESP's wifi configuration from it's flash, once I did that I was able to set it without a problem.    It could be because I was fiddling with them so much and the flash config got corrupted, but I'm not sure - once I found it wasn't a problem in my code I was done :).  There is no way to do this over wifi, it needs to be done over the usb/serial connection.

Mike P 4 MPP

unread,
Apr 6, 2020, 8:40:01 PM4/6/20
to MppDevices
A bit further to this problem - I was having trouble devices that would keep dropping the USB port as if they were disconnected.  I suspected a bad cable or loose USB ports on these devices.  This would often happen if I used the "reset" button through the USB, or it might take a few tries of unplugging/replugging to get the port to be seen by the OS and MppArduino.  

The devices with the misbehaving USB ports have since been fixed by sending the "eraseConfig" command.  It must be related to the wifi config problem though I'm at a loss to explain why...  Something to keep in mind if you find a device starting to act strangely.

DougC

unread,
Apr 7, 2020, 1:34:58 AM4/7/20
to MppDevices
One thing I've had happen at least once that caused me a lot of confusion at the time was apparently persistent IP address on one of my devices.

What I recall I did was to transfer a device from a regular AP onto an MppGateway.  That device did not have Staticip set, but it's ip address was of course listed in its Properties. On setting it's WiFi to the gateway SSID it connected to the WiFi, but continued to try to use it's old IP address (192.168.2.xxx) against the gateway (192.168.4.1). And that didn't work.

I didn't really pursue it at the time and haven't tried to recreate it but it is perhaps another one to bear in mind when troubleshooting.

Mike P 4 MPP

unread,
Apr 11, 2020, 10:34:20 AM4/11/20
to MppDevices
The "eraseConfig" didn't persist, it's still happening.  Seems like almost any time a device using the CH240 driver establishes a wifi connection it drops the USB port.  Frustrating because that happens within a few seconds every time I plug it in...  Usually it recovers and I can reconnect with MppArduino, but every reset loses it again. 

Mike P 4 MPP

unread,
Apr 12, 2020, 10:08:00 AM4/12/20
to MppDevices

Might be two problems - swapping cables seems to help, reducing but not always eliminating the crash.  Could be one of my cables is marginal.  Still frustrating :)!

Mike P 4 MPP

unread,
Apr 12, 2020, 10:10:05 AM4/12/20
to MppDevices
Memory leak when wifi connection is lost and re-established.  If the router is restarted, the MppDevice will reconnect.  This appears to lose a little over 1k from the heap each time.
Reply all
Reply to author
Forward
0 new messages