Calling all ESP experts

I am trying to conect 2 esp8266 devices together through a router. What i want to do is have a reed switch on a door so an open closed signal is sent when the door is opened or closed, through the magical system of WIFI through my router to another esp8266 where the signal will operate a servo with a pointer on it. Door open, servo points to open etc.
I am also wanting to conect a dht22 so i can get the outside temp/humidity buts thats an add on.

The question is how do you send the signal from the reed switch to the other esp8266 i am at a loss at doing this. I don't want a broker or a MQTT just a simple indication of my door, (my door is attached to a shed in the garden)?

I have wriiten code that works perfectly on one esp8266 device but that is all conected together i just need to seperate the devices over WIFI.

Any help will be greatly recieved or guidance pointing me in the right direction.

use WiFiServer and WiFiClient and send with client to server what you want

the wificlient and server that you mention are the libaries that you include at the top of the code

Fathead:
the wificlient and server that you mention are the libaries that you include at the top of the code

They are also the names of example sketches.

Thank you for the respose I have seen them examples and i have succesfully connected to my home network on both esp's, i think im being dumb as i still can't figure how to send a reed output from one esp to the other!

The ESP can be a server or it can be a client. Servers can't push data. Clients can pull data. In the process, they can make a server aware of data.

So, the thing acquiring data that the other needs to know needs to be a client. The one with the need to know needs to be a server. The client makes a GET request, with the data that server needs to know.

not a GET request, please. nice plain telnet is good. start a server at port 2323 and connect to it from client and send what you want and process it on server and eventually send something back to client.

you can test the server with telnet client (telnet 2323)

Juraj:
not a GET request, please. nice plain telnet is good. start a server at port 2323 and connect to it from client and send what you want and process it on server and eventually send something back to client.

you can test the server with telnet client (telnet 2323)

Why tie up a connection, when the only information that needs to be exchanged involves the door being opened or being closed? How often is THAT going to happen?

PaulS:
Why tie up a connection, when the only information that needs to be exchanged involves the door being opened or being closed? How often is THAT going to happen?

nothing is tied up. the client can close the connection after the event. the server must listen all the time.

for this simple task RF communication would be better

nothing is tied up.

So, the ESP can support an unlimited number of connections. That's news to me.

PaulS:
So, the ESP can support an unlimited number of connections. That's news to me.

I do not understand. How does my recommendation imply unlimited connections?

Juraj:
I do not understand. How does my recommendation imply unlimited connections?

If there are a limited number of connections (like the Ethernet shield can only handle 4 simultaneous connections), and you use one of them for a telnet session, so that you can be told twice a day that the door opened or closed, then that connection is not available for any other use. Hence it is tied up.

nothing is tied up.

It that one connection is nothing, this implies, to me, at least, that it isn't 1 of 4. Rather, it is one of so many that one doesn't matter.

So, which is it? Are you tying up one of a limited number of connections, where it could matter, or one of so many that it doesn't matter?

PaulS:
If there are a limited number of connections (like the Ethernet shield can only handle 4 simultaneous connections), and you use one of them for a telnet session, so that you can be told twice a day that the door opened or closed, then that connection is not available for any other use. Hence it is tied up.
It that one connection is nothing, this implies, to me, at least, that it isn't 1 of 4. Rather, it is one of so many that one doesn't matter.
So, which is it? Are you tying up one of a limited number of connections, where it could matter, or one of so many that it doesn't matter?

I do nothing, I only recommend using the simplest way.

esp8266 can handle 5 sockets. This project needs one socket on the client esp8266. On the server one socket is the listening socket a second socket is the current client. server side sketch can refuse more clients by simple stopping the incoming connection.

the OP can decide if he lets the client connection alive or closes it after every event. if the client closes the connection, the server side closes it too. I would close the sockets after the event in this case.

I guess that at least the door switch part is to powered by battery.
Anyway, even if not, probably the best configuration is to have the ESP8266 which monitors the door switch configured as a web client. When the door switch changes state, it wakes up and posts (using HTTP POST or HTTP GET) the status update to the web server (another ESP8266). After that it goes back to sleep. The ESP8266 configured as a web server must run all the time, waiting for status change messages from the ESP8266 monitoring the door switch and act on them issuing alarm calls etc.

If you have an existing wifi network, then it is probably best to integrate the two ESP8266 devices in your existing wireless lan. If not, you can make the ESP8266 which is designates as the web server also into an Access Point (AP mode) which effectively creates its own private wlan.

The mechanism is simple. It is exactly analogous to using your web browser to post a message in this thread. Your browser is the web client and at forum.arduino.cc there is a web server running which accepts your post.

6v6gt:
I guess that at least the door switch part is to powered by battery.
Anyway, even if not, probably the best configuration is to have the ESP8266 which monitors the door switch configured as a web client. When the door switch changes state, it wakes up and posts (using HTTP POST or HTTP GET) the status update to the web server (another ESP8266). After that it goes back to sleep. The ESP8266 configured as a web server must run all the time, waiting for status change messages from the ESP8266 monitoring the door switch and act on them issuing alarm calls etc.

If you have an existing wifi network, then it is probably best to integrate the two ESP8266 devices in your existing wireless lan. If not, you can make the ESP8266 which is designates as the web server also into an Access Point (AP mode) which effectively creates its own private wlan.

The mechanism is simple. It is exactly analogous to using your web browser to post a message in this thread. Your browser is the web client and at forum.arduino.cc there is a web server running which accepts your post.

why web? why HTTP? plain socket communication will do it

why web? why HTTP?

Because the process is well understand, easy to implement, and there are examples out the wazoo.

PaulS:
If there are a limited number of connections (like the Ethernet shield can only handle 4 simultaneous connections), and you use one of them for a telnet session, so that you can be told twice a day that the door opened or closed, then that connection is not available for any other use. Hence it is tied up.
It that one connection is nothing, this implies, to me, at least, that it isn't 1 of 4. Rather, it is one of so many that one doesn't matter.

So, which is it? Are you tying up one of a limited number of connections, where it could matter, or one of so many that it doesn't matter?

Do you not understand how a basic telnet connection works? It is nothing more than a simple TPC socket connection. It is trivial to establish the connection, send/receive data, then close the connection, leaving the sockets on both client and server "busy" for only as long as it takes to service a single client (which should be VERY quick). Having a telnet server standing by, ready to service a client at any time, consumes only ONE of the 5 available sockets, leaving the other 4 free for other uses. Such a setup can handle dozens, hundreds, even thousands of clients with a single socket, as long as they all understand they may sometimes have to wait a bit for service. And, in this case, it sounds like there would only ever BE a single client.
Regards,
Ray L.

And, in this case, it sounds like there would only ever BE a single client.

So, what is the benefit, when the door is likely to be opened only a few times a day? The standard client/server process is well understood, easy to implement, and there are examples out the wazoo.

Can you say the same for telnet clients?

PaulS:
Because the process is well understand, easy to implement, and there are examples out the wazoo.

that is sad

see the WiFiTelnetToSerial example of ESP8266WiFi.

here is a telnet server in my project, logging data to client

the telnet client is the same like for http only you do not need the headers.

PaulS:
So, what is the benefit, when the door is likely to be opened only a few times a day? The standard client/server process is well understood, easy to implement, and there are examples out the wazoo.

Can you say the same for telnet clients?

How do you think http works?? It uses EXACTLY the same underlying transport mechanism - TCP sockets - and uses it in EXACTLY the same way! There is NO difference in performance, reliability, resource consumption, or anything else.

Regards,
Ray L.