Have say, 2 modules that are both connected to a network over ethernet (This must use ethernet, NOT wifi - this is important). I can flip a switch connected to one module, and this will activate a relay on the other module. OR, can activate the relay module from my computer.
This must be done strictly over LAN, not using internet in any way.
Any ideas?
If there is already a hobby-level* device that does this, I would be interested in that, but if not, please suggest how to build using Arduino or similar.
Would something like this accomplish what I need?
Amazon.com (I have no idea what this does, but appears maybe like it could be something I want for this)
*There are devices out there, but they are industrial level, have much more functionality, and are very expensive. There are cheap IoT devices for this, but all that I have seen use WIFI, not ethernet.
You can use ordinary Arduino, like Uno/Nano V3, and add Ethernet shields/modules to them.
Then write code to make one of them a Server to control the relay and the other a Client to read the switch and send any changes to the Server. Your computer can also act as a Client and send changes to the Server.
You can use HTTP protocol for the communications between them. You will need to get your Router to assign a fixed IP address to the Server.
There is a very brief manual, applications and source for VB/Delphi.
It appears the module supports TCP and UDP connections, and is controlled by a 2 character text string. This should be very simple to control via either a PC, or an Arduino with an ethernet shield.
As far as I can tell, it can operate in a standalone mode without requiring internet access.
Of course, you could roll your own without much difficulty, but as an off the shelf product it is quite neat.
@bobcousins Knowing the SR-201 designation is quite helpful. Searching SR-201 brings up a plethora of information. It looks quite promising for my application, I have ordered one to check it out.
Simplest communication protocol is called UDP, I've only used it over WiFi but it should be the same over ethernet. Get a couple of ethernet shields and try the UDP examples in the library.
Note UDP allows you send and receive data, what you use it for is for you to write code for.
Gotta be careful with UDP though. Its not guaranteed to get to the destination. I've run into network configurations where UDP packet loss was a serious problem.
Usually what happens is that the network prioritizes TCP because those packets must get through. If a switch or router needs to drop packets to maintain throughput then it will start by dropping UDP, especially broadcast or multicast.
A similar problem is that multicast (IIRC) UDP cant cross subnets so parts of the network might never see the packets at all.
I've seen this at enough locations to never use UDP for anything important.
I'm not sure there is really any reason to use UDP instead of TCP, in an end user application. UDP is connectionless, so perhaps it seems easier than dealing with a dropped TCP connection, but you then have to add all the features that TCP provides if you want a reliable transfer. It might seem like a simpler option, but not really.
Yep. UDP multicast works really well when you just want to blast out a stream of packets to any interested party but don't really care if your message makes it there. It works fairly well as a one-sender-to-multiple-listeners solution as long as you're aware of the drawbacks.
I once had to deal with a system that did software updates over UDP and it was a royal pain in the a**
VoIP utilises the human layer for detecting packet loss and requesting retransmission.
A : The problem is in the *bzzzt hisspopsilence
...
B : sorry, you dropped out, can you say that again?
So people do often consider there is a point to requesting lost data and that it is not too late; either way this method only really works if you have humans in the loop. If you are doing remote machine control, that does not apply.
Also, it appears that most vendors offer a download for Windows which include an .exe to control and configure the board, along with good documentation.
