UDP + red LED restart loop

thanks that’s really interesting and very helpful. we’re already starting to put IP addresses in the packet and this makes sense. The UDP acting like a byte stream is sort of unfortunate, but in our case, we’re going to make all the packets the same size, which should mitigate things.

One thing that’s helping for stability is removing all the starting and stopping of UDP objects – I think this code is around the forum but with the current firmware there is no timeout and the main thing is just starting the udp object with the device is online. Since we’ve disabled the cloud, setup() isn’t a great place to put code like starting udp since that code runs while the device may not have an IP address (blinking green). I’ve taken to doing the udp objects setup in the following way in loop:

void loop()
{

    //------------------------------------------------------------------------- are we just coming online
    
    bool bOnlinePrev = bOnline;
    
    IPAddress addr = Network.localIP();

    if  (addr[0] == 0 && addr[1] == 0 && addr[2] == 0 && addr[3] == 0){
        bOnline = false;
    } else {
        bOnline = true;
    }
        
    if (bOnline == true && bOnlinePrev == false){
        Udp.begin(localPort);
        UdpOut.begin(outgoingPort);
    }

this seems to help, and we just use flush to deal with things. This seems way more stable then restarting the UDP object, which was kind of voodoo.

@firmread has switched to one UDP object, which also seems to help.

thanks everyone for the tips and help. this community is great.