ESP8266 Community Forum

If ESP Basic had the ability for UDP send & receive it could open up all sorts of possibilities, by offering node-to-node communications without requiring any controlling AP or web server.
If it could broadcast text 'payload' messages which specific nodes could recognise and respond to, any nodes could be capable of sending messages (commands and parameters) to any other nodes, and only the ones that locally recognised a broadcast command would react to it.

That remote communications capability could amplify some unique ESP Basic advantages with enough potential to make it a boon for hackers.
If it's asumed that most ESP users want connectivity, and most ESP Basic users are hackers rather than C programmers, then node-to-node communications using ESP Basic could have a lot going for it...

Speaking as someone who had a BEEB model B, I think parsing for commands and parameters in Basic is luxury compared to the contortions of using C++.
But ESP Basic interpreter is based on parsing of commands and parameters anyway, so why not 'break out' some of those already-existing parsing routines and make them available to use as Basic functions and procedures?

Wow - wouldn't that offer a simple and efficient way of locally recognising incoming commands, effectively increasing any nodes command vocabulary to include whatever additional commands are wished to be looked for and actioned by jumping to a specified subroutine.
The ESP Basic interpreter is parsing sequential instructions anyway, so presumably it could be feasible to similarly parse a users command subroutines from files on SD if wished, in which case large libraries of additional command functionality could be added which far exceeded any memory constraints.


Coming at this from a slightly different angle with an even bigger potential wow... how feasible might it be for the ESP Basic interpreter itself to directly parse (and therefore interact with) incoming UDP text commands sent from other nodes?
Now wouldn't that make it a powerful but easily used interactive network tool.

Hi,
when you talk about parsing UDP, what is exactly your request ?

In fact, because the UDP are communications without connections, you need to make 2 links (server and client) at the same time to establish a communication.
Then you should be able to write (send) on the client side and receive from the server side.
An event should be triggered when an UDP packet is received, a kind of goto_on_UDP.

I think that this could be feasible, in particular for little packets with low frequency ( 2 - 3 /sec maximum, the time to parse and send back the answer).

Is this your question ?

Hi cicciocb, yes I think we're talking about the same thing, but perhaps I should better explain myself, then perhaps you might be able to tell me what I would actually need...

An arduino or ESP can do almost anything, but lack of memory means it can't do everything. So a solution could be to add more arduinos or ESPs as needed to obtain the same overall required functionality spread across multiple devices. But I'm not aware of an effective 'hacker-friendly' way for arduinos or ESPs to communicate with each other that doesn't require specific network setup and configuration.

I think a relatively simple ad-hoc way for them to communicate could be by broadcasting a UDP text "command [parameters]" string to all nodes. All nodes would receive and parse each message, but only those nodes programmed to respond to a specific command would recognise and 'action' the command, possibly by broadcasting commands of its own for other nodes to action as appropriate.

For instance, a node called 'Ping' could have an interactive network game of ping/pong with a node called 'Pong' without requiring any specific network node configuration - it just needs to broadcast a UDP "PING" command that the other Pong node recognises and responds to by broadcasting out its own UDP "PONG" command that the first Ping node responds to, and so on.

More usefully, an IR 'reader' node might recognise IR remote control button presses and broadcast commands such as "IRSEND NEC 0xFFEE1234" to an IR 'blaster' node in a different room. Additional IR 'reader's, and/or 'blasters', could be added in other locations without any network configuration being required. The existing IRlib send and receive demos could almost be used as-is for this, it just being a matter of diverting the serial output via UDP broadcast, and reading incoming network broadcast payloads instead of (or as well as) the serial port.
A remote IR extender may not have been an ideal example because I don't know if ESP Basic has IR capability, but any commands that ESP Basic can't cope with could be likewise passed on out the serial port for an attached arduino (or Cray supercomputer for that matter) to deal with. A unique ESP Basic advantage is the potential to run big programs that don't necessarilly all have to fit into working memory at the same time.

Perhaps a better example might be several PIR sensor nodes able to broadcast "ZONE nn TRIGGERED" to a 'supervisor' node which might have a list of relevent ZONE numbers with corresponding responses, such as...
ZONE 12: IR MUTETV, ANNOUNCE "Garage door opened", RELAY 5 ON, IR UNMUTEV.
The supervisor node would simply look up the appropriate triggered entry and parse out the appropriate responses, then broadcast each response in turn for the relevent remote nodes to recognise and action as instructed. Not all different functionality has to be on seperate nodes of course (but it could be), the IR and voice announcement functionality might be on one node by the sofa, and supervisor and relay switching functions on another node in the garage or office. It's just a matter of whatever is convenient.

The main thing is that the informal lack of structure allows nodes to communicate without any per-node network configuration being needed. I could add more voice ANNOUNCE nodes for additional announcements in other locations without having to change anything anywhere. I could even add a voice recognition node to the 'cluster' which would merely broadcast appropriate existing commands such as "IR MUTETV" if wished, and all done without having to do any specific network changes or reconfiguration.

The only 2 essential requirements for such a distributed cluster of functionality would seem to be...
1. An ability to parse out text commands and parameters - whether from serial port, network payload, or config file entries - which ESP Basic is potentially well-suited for.
2. The crucial ability to broadcast, and receive, UDP broadcasts. I don't think UDP is possible on ESP Basic at the moment, so I was asking if it might be a possible feature for the future?


At risk of unnecessarily complicating things further, but in an effort to complete the picture, I'm adding 'smarts' to the messaging system by adding some optional command line switches to the message for validation and any required node-specific addressing.
Source /s=nnn is added as a return address if a response is required.
Destination /d=nnn is added if the message is intended for a specific node.
Eventually addresses would probably automatically be the network LSB address byte, but for now I'm just assigning arbitrary individual numbers.
Message Length /l=nnn and Checksum /c=nnn are added for integrity testing (they're probably not both essential, but I'm still just evaluating things at the moment).

All nodes receive and parse all broadcast messages. If a node recognises an incoming command that doesn't include any option switches it branches to a specified function to 'action' it. But a command that is accompanied by option switches will only be 'actioned' if those switches evaluate true, so if destination /d=nnn is specified it must match the local address, and /l=nnn must match message length, and /c=nnn must match the message checksum.
If source /s=nnn is specified then a response or acknowledgment is requested to be broadcast back for the attention of that specified address, which if not received within a specified timeout would assume the original message is lost or corrupt and therefore re-transmit.
I've also made future provision for keeping track of different messages with an ID /i=nnn option, and pretty much anything might be similarly added if needed.

I was developing this on arduino in C++, but when I found out about ESP Basic I started realising the potential benefits it could offer if UDP was available.
Do you think it is something which might be possible?

Hi,
thanks for the very exhaustive answer.
If I resume, you are requesting for the possibility to make UDP communication in both directions (send and receive) with unicast and multicast.
I'm not familiar with multicast but, at least for the unicast, this should not be hard to implement.
For the multicast, it's slightly different, even if It seems faisable.