There is a bug in the Spark Core which means that the 255.255.255.255 broadcast address (and multicast addresses, such as those used for SSDP over UDP) do not work in MANUAL or SEMI-AUTOMATIC modes if the Spark Core is not or has not been connected to the Cloud. This is because the Spark Core does not initialise the TI CC3000 chip properly in that circumstance.
Update: @bko has discovered one need not connect first to the Cloud in order to allow UDP broadcasts to 255.255.255.255. Simply initially ping another device once, and then the 255.255.255.255 address can be used for UDP broadcasts. It is easy to determine the IP address of the network gateway and so that is the easiest device to ping:
Wifi.ping(WiFi.gatewayIP()); Until this discovery by @bko the following was a good workaround:
Ordinarily everywhere programmers use the 255.255.255.255 catch all IP address for UDP broadcasts and this works as intended because routers do not typically route UDP broadcasts beyond the local subnet. Otherwise the network broadcast address would have to be determined - and each subnet has it’s own broadcast address.
In the circumstances described 255.255.255.255 cannot be used on the Spark Core as a UDP broadcast address. A workaround, therefore, is not to use 255.255.255.255 but to use the local subnet’s broadcast address. Following is the code to determine the local subnet’s broadcast address.
IPAddress local_ip; IPAddress network_mask; IPAddress broadcast_addr; local_ip = WiFi.localIP(); network_mask = WiFi.subnetMask(); # Rule to determine broadcast address from own IP and network mask: # broadcast_addr = ( local_ip BITOR (BITNOT network_mask)) int i; for( i=0; i<=3; i++) broadcast_addr[i] = local_ip[i] | (~ network_mask[i]);
If the UDP broadcasts are sent to the subnet’s broadcast_addr, as determined above, then all devices on the subnet will see the broadcast.
Note that the easier workaround is, as described at the top, to issue one ping before starting the UDP broadcasts on the usual 255.255.255.255 address.