Mini 2 relay

I spent a little time just now playing with the, so-called, cloud service. At around 1 second intervals, the relay board sends a POST request like

POST /SyncServiceImpl.svc/ReportStatus HTTP/1.1
User-Agent: SR-201W/M96Y
Content-Type: application/json
Host: connect.tutuuu.com
Content-Length: 30

"F44900AB0051CE12345600111111"

The data shown in bold is what we are interested in. The first 14 characters are the device serial number, the next six are the cloud password, and the last 8 are the relay states.

All of this is fine and potentially useful except for one big problem. The cloud_service is assumed to run on port 80. This is a privileged port and requires root access to listen to. Also, it is commonly used for other purposes. I tried setting the cloud_server IP address to contain a port number, but that causes an error.

Once last note, after setting the cloud_server and enabling the cloud_service, you must send a reset command for the changes to take effect. That is not necessary for the other config settings.

in a script you can do everything automatically:

Code: Select all

sudo ifconfig en1 192.168.1.5 netmask 255.255.255.0 up
./sr-201-relay.py 192.168.1.100 ip=192.168.5.47 gateway=192.168.5.1 dns=192.168.5.1
sudo sudo ifconfig en1 down
 

that will setup on en1 the ethernet 192.168.1.x
then do the config thing in the script
and then shutdown en1
likely you can also use en2, en3
use ifconfig to check which "enx" are available.

your MAC should normally run on en0

Karl

in a script you can do everything automatically...

Yes, you could do that. I am just wondering if it is worth scripting something that only gets done once. Especially given the (so far) low level of interest in this kit.

BTW, I figured out how to talk to the relay from the terminal. Telnet will not work, but you can use nc.

nc 192.168.1.100 6722
or port 5111 for configuration

You can then just enter the commands.
You don't need a CR, but you must end each command with Ctrl-D.

Get Relay Status  00 (UDP is not supported)
CH1 pull                  11
CH1 release           21
CH2 pull                  12
CH2 release           22

Note there is a 15 second idle timeout.

I have posted sr-201-relay.py to GitHub. This version contains a few minor bug fixes and also returns a single digit status code to be used in an Indigo Action group and saved to a variable.

Here is a follow-up. I have been running this device for a month and (fingers still crossed) it seems to be quite stable.

For the price, actually even 5 times the price, you can't go wrong with this one.

I finally have one of these devices to play with (it must've literally been on a slow boat from China). I found it on Amazon for under US$20. While mine looks generally like the one pictured in post 1 of this thread, it's a little different in the board's layout--but I'm convinced it's the same product. A couple of notes on mine::

• Although the board in the Amazon listing shows a micro-USB, mine came with a barrel connector for power. I was able to find an old 9v cordless phone power supply that worked just fine (the board is marked as accepting 5v-24v DC and, while I didn't see any markings for polarity, mine is (+)pin and (-)sleeve.)
• The board came with zero documentation or software.
• I was unable to use the sr-201-relay.py script to change the board's IP to my network's 10.x.x.x scheme, so I fired up an old Windows 10 laptop and used the board's software (as highlighted above can be found online by searching "sr-201 ethernet") which handled this operation just fine.
• The Windows configuration and controller software seems to work fairly well, but it is not very well documented.
• There is some kind of odd default setting on this board (or I have a defective one) as I turned on/off relay 1 no problem, turned on/off relay 2 no problem, but when I turned on relay 1 and then turned on relay 2, the board went into some kind of death-loop where I think it did this in rapid-fire succession: r1 on - r2 on - r1 off - r2 off - r1 on - r2 on.... I couldn't get it out of this loop so I had to factory reset the board and redo the IP setting again. It was like the board was triggering r1 to turn off when r2 turned on and vice versa.

Overall, I'm very impressed with the construction of the board itself. It looks well laid out and is quite hefty for its size.

I finally have one of these devices to play with (it must've literally been on a slow boat from China).... ...While mine looks generally like the one pictured in post 1 of this thread, it's a little different in the board's layout--but I'm convinced it's the same product. A couple of notes on mine::

...

• I was unable to use the sr-201-relay.py script to change the board's IP to my network's 10.x.x.x scheme, .

Overall, I'm very impressed with the construction of the board itself. It looks well laid out and is quite hefty for its size.

I suspect the board you received is not the same as the one pictured on Amazon (and the one I found on eBay). If you look carefully at the Amazon product photo you can see the 5v usb connector on the upper left side of the board. So, if your board does not have that, it is not the same. Also, if the sr-201-relay script did not work on your Mac it indicates a difference... or, perhaps, a bad board.

However, if you get it working, as you note, it is a really useful product.

I suspect the board you received is not the same as the one pictured on Amazon (and the one I found on eBay). If you look carefully at the Amazon product photo you can see the 5v usb connector on the upper left side of the board. So, if your board does not have that, it is not the same. Also, if the sr-201-relay script did not work on your Mac it indicates a difference... or, perhaps, a bad board.

I'm sure it's not the one pictured on the Amazon page I referenced (although that is the page for the device I ordered). I only spotted two differences between my board and the one pictured above. Otherwise, they appear nearly identical. If I remember, I'll post a picture of mine tonight.

To be clear, the sr-201-relay.py script was able to communicate with the board (open and close the relays); it just wasn't able to change the IP address of the board to the IP address I wanted. I didn't go into the code to figure out why--firing up the Windows laptop was the much easier approach. I have yet to look into what may be causing the odd behavior when both relays are set to on. I suspect--but don't know--that it's a setting in the default firmware. If it turns out to be a defective board, I'm not out that much money.