ESP8266 Community Forum

Hi all,
as you may know, we introduced recently some commands / functions enabling to manage UDP traffic.
Basically, these commands permits to receive and/or transmit an UDP message to another ESP8266 or another device (PC, tablet, ...)
I'll try to put a working example to show how this can be done very easily.
I order to support this example, I developed a simple utility that can be found here : https://github.com/cicciocb/UDP_tester/raw/master/UDP_tester/bin/Debug/UDP_controller.exe
This is a picture of the utility


This utility permit to send and receive messages to/from a group of ESPs;
in my case I tested with 3 at the same time.

This is the program installed in the 1st ESP


This is the program installed in the 2nd ESP


And this is the program installed in the 3rd ESP


As you can see into the basic code, all modules shares nearly the same code.
Each modules contains an ID, (ESP_LIGHT, ESP_TEMPERATURE, ESP_DISPLAY).
This correspond to a particular function dedicated at each module (light relay, temperature sensor, external display).

As soon as they receive the message "Who are you?", they answer back their ID.
This happens clicking on the button "Who is Connected"


What happens when clicking on the "Who is Connected?" button ?
A broadcast message is sent on the local IP (the PC IP with .255 at the end) on the port defined (5001).
All the modules are configured to receive messages on this port so all the ESPs receive it.
After that each module send back its ID and the utility understand that and fill the "ESP8266 list"
Now, we can send messages to the modules.
Each module has been "instructed" to understand a simple message :
- LIGHT_ON / LIGHT_OFF for the ESP_LIGHT
- TEMP for ESP_TEMPERATURE
- PRINT for ESP_DISPLAY

Clicking in the ESP8266 List permit to select the module we want communicate with.
For example we can click on the ESP_LIGHT and then select the demo message LIGHT_ON; Clicking on "Send" will send the message to this unique module; the module will send back a message "MSG_RECEIVED"


The same will be for the temperature module; in this case the message to select is TEMP and the message received will be the temperature (in fact a random number)


For the last module, same history, PRINT message.

Hoping this will permit to better understand how manage the ESP UDP communications

Regards
CiccioCB

Very impressive work - I wish the slow boat from china bringing my esp devices was as quick!

I see the 3 ESP Basic scripts are configured as udp responders that reply to the 'requester' test utility. So reading between the lines, I'm guessing the utility is mainly for a simple way of finding the IP addresses of any available but unknown dhcp udp nodes?
I think what that probably means though, is that each node can only join the ESP Basic udp network based by responding with a unique 'name', therefore all nodes must have uniquely tailored scripts loaded before they come online.

Thinking out loud... GPIO1 (D1) is the ESPs built-in blue LED anyway, so to help local identification of node addresses, perhaps it's worth flashing out the last unique digits of a nodes address at bootup. (eg: an assigned dhcp address of nnn.nnn.nnn.037 could give 3 flashes, pause, then 7 flashes). Knowing the address means it's just a matter of browsing to the node and editing the name if needed.

While I remember - in the Blink example, the line... print "How many times to blink" noOfBlinks... will need updating for V2 with the "&" print concatenation symbol (eg: print "How many times to blink" & noOfBlinks).

A universal indicator led could be matched by another free 'universal' facility if the GPIO00 flashing button/link was used as a way for any node to broadcast a "who's there" query.
It could also offer a very simple and hardware-independent udp "Hello World" example as well, by using any nodes GPIO00 button to toggle any other 'named' nodes GPIO01 led on and off.

Well done again guys, this is really top stuff.

Electroguard wrote:Very impressive work - I wish the slow boat from china bringing my esp devices was as quick!

I see the 3 ESP Basic scripts are configured as udp responders that reply to the 'requester' test utility. So reading between the lines, I'm guessing the utility is mainly for a simple way of finding the IP addresses of any available but unknown dhcp udp nodes?
I think what that probably means though, is that each node can only join the ESP Basic udp network based by responding with a unique 'name', therefore all nodes must have uniquely tailored scripts loaded before they come online.

Thinking out loud... GPIO1 (D1) is the ESPs built-in blue LED anyway, so to help local identification of node addresses, perhaps it's worth flashing out the last unique digits of a nodes address at bootup. (eg: an assigned dhcp address of nnn.nnn.nnn.037 could give 3 flashes, pause, then 7 flashes). Knowing the address means it's just a matter of browsing to the node and editing the name if needed.

While I remember - in the Blink example, the line... print "How many times to blink" noOfBlinks... will need updating for V2 with the "&" print concatenation symbol (eg: print "How many times to blink" & noOfBlinks).

A universal indicator led could be matched by another free 'universal' facility if the GPIO00 flashing button/link was used as a way for any node to broadcast a "who's there" query.
It could also offer a very simple and hardware-independent udp "Hello World" example as well, by using any nodes GPIO00 button to toggle any other 'named' nodes GPIO01 led on and off.

Well done again guys, this is really top stuff.

If all of the ESP's started with the same default program that announced themselves and then downloaded a new default program. That way it would be easy to start with a blank slate, do OTA per device, and have that device reboot with new program to access the network and function as needed.

Haha, just seen your "Other udp example" which shows you're already way ahead of me again pal.