ESP8266 Community Forum

- Sat Sep 10, 2016 9:35 am #54809 I think I see what you're getting at Oldbod, sure there's various ways to find out the subnet details like default gateway and subnet mask, but not actually from ESP_Basic.

I have been playing around with making a voice node speak out it's IP address (they can already blink it out on local LED), and I don't remember seeing any way to winkle out the other IP info. Not that it's really an issue though, the dhcp clients are already connected and happilly working anyway, and it's easy enough to confirm the subnet details from any non-ESP-Basic client node if wished (do an 'IPconfig' from a windows client).

Connectionless UDP clients SHOUTING at each other does not offer the best comms, it merely offers possibility for a configureless ease-to-use system I've had bouncing around my head for a while. If and when I get around to doing a working V3 version of the EasyNet client (which is still just proof of concept, and been a difficult moving target until now) I plan to include broadcast acknowledgement and retry facilities to ensure maximum UDP comms reliability. But until then, I think you need a fairly good reason to be using a UDP broadcast type network outside of it's intended subnet, because if nodes are configured to broadcast to the world by using 255.255.255.255 instead of just their local subnet prefix, you might be generating a lot of unnecessary broadcast traffic on any other reachable subnets. Plus if the default gateway is off of the local subnet, the 'connectionless' UDP broadcasts are likely to have a lot of external TCP traffic to compete with.
So the standard dhcp IP configuration is fine for UDP, and TCP is not even an option yet anyway.

Where to get modules?

https://www.banggood.com/custlink/KvGGhGF4wG

- Sat Sep 10, 2016 10:50 am #54819 I have been wrestling with is for several days.
Setting up UDP on a dedicated esp8266 network has simplicity as a feature. An esp8266 can broad cast on xxx.xxx.xxx.255 and the other networked esp8266's can gain knowledge of its presence.
Packets never go outside the local lan.
Simple messages like switch on or off can be sent peer to peer.
A windows PC interface is nice if it would work since it could easily provide gui access to the states of the esp's.
Now if a WIN10 pro PC is linked to the esp8266 network things run into Microsoft's OS. Net BIOS firewalls and who knows what else.
It is almost 100% true to say Microsoft frowns on UDP even though a malicious entity would need to be close to the esp network know the SSID password and be able to guess the command structure that the esp's respond to. If I'm correct Microsoft provides little support for UDP data grams.
If MQTT is used and a local device ( ex rasppi as a broker on a local lan is used) the PC can receive sub and pub messages. I have this working but it has the downside of needing the broker 24/7 in the loop.
A free web based broker also works but it brings in some security and privacy concerns as well as will it always be free and what if the service goes belly up.

FYI
An Andriod device will work fully with MQTT but with UDP I have not been able to have it receive xxx.xxx.xxx.255 UDP broadcasts.
I don't know if espnow is viable yet or if a Windows PC could join the mix.
The web indicates Unix is the OS that gives the owner more control of his/her PC.

- Sat Sep 10, 2016 3:10 pm #54826 I know what you mean about Microsoft... I recently went for a weekend into the mountains with friends, taking my ESP-Basic dev module and a netbook with a new install of Win10 in case it rained. No other wifi signals around, and Win10 could clearly see the ESP device, but refused to connect to it. After reverting back to Win7 everything worked properly again.
I'm fed up being dictated to by MS, and have already wasted far too much of my life on them already to have much patience left to keep jumping through their hoops. So I'll be sticking with Win7 for the foreseeable future - and I'd still be running XP if they hadn't forced that upgrade on me.

I'm not sure what you've been wrestling with regarding udp though, cos we know it already works, and the udp nodes can be controlled several ways from a Windows pc on the same subnet.

I have a separate wifi router with dhcp server to provide a subnet reserved just for my ESPs. In my case I prefer isolation (I could bridge a specific node to the internet if ever necessary), but in your case you'd probably want your default gateway to point to an internet-connected router.

The only other device on my ESP subnet is my Win7 dev pc, which has wifi connection to the ESPs, plus a second wired subnet connection to internet and the rest of my intranet. Obviously the windows browser can be used to connect to an ESP in server (AP) mode. But for subnet-wide comms I originally used a windows UDP Processing script to broadcast and receive udp messages with the ESP nodes. Then cicciocb kindly made his UDP debugger utility available, which offered quicker and more convenient communications with the nodes.
But the important point is... the UDP Processing script still remains a useful alternative if ever something more specific needs to be done, because Processing offers an interface into both the windows hardware and software if required.

All the nodes I've done so far have been based on the original 'EasyNet' concept which I was developing using V2 until V3 was released. I've tried converting from V2 to V3 a couple of times, but the browser screen never worked properly again. That is not actually much of a problem for my purposes any more, because for future-proofing I now prefer the independence of non-browser contact with the ESPs. I can send any debug info I want from the ESP to the windows udp debugger utility. And I can send udp messages from the debugger utility to any named network node to trigger any appropriate tasks (commands+parameters) that they've been programmed to locally recognise and respond to.

Eg: In the case of a Sonoff Relay node called Lamp1, sending "Lamp1 Toggle" (or On or Off) from the debugger utility would cause the named node to toggle it's relay.
The node can send a udpreply acknowledgement specifically back to the sender.
In this case the sender is the debugger utility, but that's just for test and dev purposes of course, so the intention is for a remote sensing (eg: PIR or LDR) node to send the appropriate trigger command, or eventually perhaps from a mobile's AppInventor control screen.

All nodes recognise and respond to some common commands, such as BlinkIP, instructing them to blink out their IP address on their local LED.

I expect the final implementation of EasyNet to include a comms optimising facility, whereby nodes that are expected to be sending instructions to other nodes would initially broadcast a "who's there?" enquiry, and store all responding nodes IP addresses against any corresponding node names that it was specifically interested in communicating with. This would allow targeted addressing instead of network-wide broadcasting for any subsequent communications with those nodes.

It wouldn't actually take much to convert EasyNet from V2 to V3 if I don't bother trying to get the browser to display correctly like it does in V2, but it would take longer to do an effective hand-shaking mechanism for making udp comms sufficently robust and reliable. I don't think it should be hugely difficult, it's a matter of remembering each transmitted broadcast until receiving an acknowledgement, and having ability to periodically re-transmit un-acknowledged broadcasts up to a specified number of retries if necessary. Where I can see complications is in remembering multiple sent msgs to different nodes, which I think is going to need a flexible array 'holding' buffer and the ability to match up incoming acknowledgements to the array entries (bearing in mind that an incoming ack may be intended for a different node which sent the msg).
The problem is, I haven't found a satisfactory way of linking the array handling to hardware event triggers such as an incoming udp responses yet (I still haven't cracked it for a voice chip 'busy' signal to control a FIFO buffer of queued audio files).

Anyway, assuming you are using some convention like EasyNet for the ESP nodes (so that they are all sending and receiving similar 'known' format ascii msgs, eg: "Name Command [Parameters]"), you should in theory be able to use any other platform that is capable of sending and receiving ascii msgs over udp, and I know for sure it can be done with a windows machine running an appropriate script in 'Processing'.

Where to get modules?

https://www.banggood.com/custlink/KvGGhGF4wG

- Sat Sep 10, 2016 5:56 pm #54831 I am very surprised to hear that windows 10 is not wroking properly for you. For the better part of 6 months I have been using windows 10 to develop and test esp basic with out any problems.

Serial terminal in the chrome browser see https://serialTerminal.com

http://esp8266basic.com
A BASIC interpreter for your ESP

Working now on Autodrop3d. A 3d printer with automatic part ejection system. https://autodrop3d.com