Serial relay module

Jeremy Harris

Senior Member
Whilst looking for something unrelated, I came across these cheap serial addressable relay modules: http://www.banggood.com/One-Channel-Relay-Module-Intelligent-Custom-Command-Control-Serial-Control-Multi-Mode-Level-Trigger-p-1077655.html

From what I have been able to decode from the information on that link, these modules can be commanded with five serial bytes, can be programmed with a unique address and can be queried to determine what state they are in, all via a TTL level serial link.

I can see a fair few uses for these with Picaxe projects, as it means you could potentially have a multi-drop serial link that allows just two Picaxe pins to control and interrogate a number of these intelligent relays. Each only responds to its own set address, so setting different addresses to different relay modules should allow a multi-drop system to work.

There's also the potential to connect these relay modules to a serial radio transceiver, like the HC-12 modules, and then have a Picaxe send commands to a single HC-12 and that could then both command and interrogate many separate remote, wireless connected, relay modules. As the modules can also be used conventionally, with a trigger input, it may even be possible to trigger a relay module with a sensor and then interrogate it via the serial link to determine what state the relay is in. It's unclear from the limited documentation whether this would work, but it seems as if it might

There are programmable timing functions too, so if a pulsed output was required, a Picaxe could send a serial command to a specific relay module and have that pulse on, then off again, after a programmable time.

I'm inclined to buy some to play with, as they are less than £2 each.
 

Jeremy Harris

Senior Member
After a fairly long delay, these serial relay modules arrived in the post yesterday, so I've been playing with one today.

They seem fairly easy to use, but the documentation isn't 100% clear. I'm in the process of re-writing it to try and make it easier to understand. As delivered, the modules are all set to 9600 baud with the address $FF (255). I used this bit of code to programme a new address to a module (the new address is retained over a power down):

Code:
;Programme to set address of serial relay module
 
;The default relay module settings are address = 255 ($FF) and baud rate = T9600

;Change relay address command:

;$AF		$XX		          $EC 		$EC		$DF
;Start	new address	           change address      command	       Stop

#picaxe 08M2
#terminal 19200

symbol serial_out = C.1		;pin C.1 used as serial output for data to relay module
symbol serial_in = C.2		;pin C.2 used as serial input for data from relay module

symbol relay_address = 125	;change this to desired relay address from 0 to 255

init:
	setfreq M16			;frequency needs to be increased to allow reliable 9600 baud operation with software serial ports


main:
	;Note: relay address is given in decimal here for convenience (range is 0 to 255), it could just as easily be sent as hex
	
	setfreq M16			;frequency needs to be increased to allow 9600 baud operation with software serial ports
	pause 100			;pause to allow frequency to stabilise (probably not really needed)
	
	
	;change relay address
	serout serial_out, T9600_16, ($AF, relay_address, $EC, $EC, $DF)
	
	
END
This worked OK, so I then wrote a short bit of code to turn the relay on for 2 seconds, read back both the command confirmation byte and then query the relay status, for confirmation of its state) and that seems to work OK too:

Code:
;Test programme for serial relay module

;Default baud rate is T9600 baud, 1 start, 1 stop, no parity, no flow control (can be changed)

;Default operating mode is to remember last relay state at power off and power on in the same state

;Module has 256 possible programmable addresses, from $00 to $FF (0 to 255 decimal)

;First byte is always $AF in normal (not custom) command mode as a precursor for normal commands

;Next byte is the module address, between $00 and $FF

;Next two bytes are the required relay action

;Last byte is the end of command, $DF, always sent to end any instruction in normal mode

;When a command has been successfully received the relay module returns the byte $01 as confirmation

;Normal command codes (hex):

;$AF		$00			$01       $01		$DF
;Start	address		close			        Stop

;$AF		$00			$02       $02		$DF
;Start	address		open			       Stop

;$AF		$00			$03       $03		$DF
;Start	address		toggle state	       Stop



;Command codes for pulsed relay operation (hex):

;$AF		$00		$04 		$08		        $DF
;Start	address	close		800ms		Stop			Pulse time in this example = $08 = 800ms (100ms steps)

;$AF		$00		$05 		$08		        $DF
;Start	address	close		8s		        Stop			Pulse time in this example = $08 = 8s (1s steps)

;$AF		$00		$06 		$08		        $DF
;Start	address	open		8s		        Stop			Pulse time in this example = $08 = 8s (1s steps)

;$AF		$00		$07 		$08		        $DF
;Start	address	timing for	8s		        Stop			Pulse time in this example = $08 = 8s (1s steps)

;$AF		$00		$08 		$08		        $DF
;Start	address	open		8m		        Stop			Pulse time in this example = $08 = 8m (1m steps)


;Command to query relay status:

;AF		$00		$09 		$09		$DF
;Start	address	query status		Stop			
;(returns $00 for relay closed, $01 for relay open)


;Change relay address from default of 255 ($FF):

;$AF		$03		        $EC 		$EC		$DF
;Start	new address	change address		Stop


;Query relay address:

;$AF		XX		$EB 		$EB		        $DF
;Start	don’t care	query address command	Stop

;(returns hex address of module as a single byte)


#picaxe 08M2
#terminal 19200

symbol serial_out = C.1		;pin C.1 used as serial output for data to relay module
symbol serial_in = C.2		;pin C.2 used as serial input for data from relay module

symbol relay_address = 125	;change this to pre-programmed relay address from 0 to 255


init:
	setfreq M16			;frequency needs to be increased to allow reliable 9600 baud operation with software serial ports


main:
	;Test code to switch relay on and off every 2 seconds, with confirmation sent back to the terminal
	
	;Note:
	;relay address is given in decimal here for convenience (range is 0 to 255), it could just as easily be sent as hex
	;all commands could be sent as decimal, so $AF = 175, $DF = 223, $01 = 1, $02 = 2 etc, etc

	;turn relay ON
	serout serial_out, T9600_16, ($AF, relay_address, $01, $01, $DF)
	;receive confirmation byte
	serin serial_in, T9600_16, b0
	
	;query relay status
	serout serial_out, T9600_16, ($AF, relay_address, $09, $09, $DF)
	;receive relay status (0 = open, 1 = closed)
	serin serial_in, T9600_16, b1
	;send relay status to terminal
	sertxd ("command confirmation = ", #b0, CR, LF, "relay status = ",#b1, CR, LF, CR, LF)
	;pause for 2 seconds
	pause 8000
	
	;turn relay OFF
	serout serial_out, T9600_16, ($AF, relay_address, $02, $02, $DF)
	;receive confirmation byte
	serin serial_in, T9600_16, b0
	
	;query relay status
	serout serial_out, T9600_16, ($AF, relay_address, $09, $09, $DF)
	;receive relay status (0 = open, 1 = closed)
	serin serial_in, T9600_16, b1
	;send relay status to terminal
	sertxd ("command confirmation = ", #b0, CR, LF, "relay status = ",#b1, CR, LF, CR, LF)
	;pause for 2 seconds	
	pause 8000
	
	goto main
	
END
This works OK too, so the next step is to just connect one of these relay modules to an HC-12 transceiver and then see if I can remotely control the relay from a Picaxe driving another HC-12 on the same channel. If I can get this working OK, then the intention is to build a unit to replace the myriad of time switches in the house, with a central control and command unit, that uses a Picaxe, an RTC, a MSF time code receiver and a display, to set the on and off times of a number of remote switches. With luck, I should be able to do away with having to go around the house twice a year resetting time switches. I will also be able to see at a glance which remote units are on and which are off. I think the hardest part may be getting a decent interface to set the on and off times of each remote unit. I'm tempted to use a multiple Picaxe approach, with a separate display for each, so that I can programme each separately and have a display showing the on and off times for each. These separate modules could then send their programmed on/off times to a central Picaxe that runs the RTC and sends and receives commands to the HC-12.
 

Jeremy Harris

Senior Member
Sadly I've found some bugs in the way these modules report back data, or it may be me not understanding the Chinese instructions well enough.

I've put together a first stab at a datasheet for them, that highlights the bugs and what I've found so far. In theory, they should work OK with several modules on the same serial output, but testing shows this to be a bit flaky, which may be noise or maybe software serial baud rate related. I need to test them using a hardware serial port, which is something I'll get on to before long, as I want to get a net of them working via radio data link first.

One very useful feature is that you can add custom programming to each module via the serial port, which means you can then control individual relays using short text strings sent from a serial output. I've tested this with a couple of the relay modules and it works very well. I currently have two modules custom programmed so that one turns on when sent "R1ON" and off when sent "R1OFF" and the other turns on with "R2ON" and off with "R2OFF". Custom commands can have up to 8 characters or bytes, so individual relays can be given "meaningful" text names, which should make the code easier to read.

Attached is the first draft of my attempt at writing a data sheet. There are probably some errors and omissions in it; I'll tidy it up and re-issue it as I find out more about the way these things work.

View attachment Serial controlled relay datasheet.pdf
 

Jeremy Harris

Senior Member
Be prepared for a fair shipping delay! I ordered 5 modules around the date of the first post in this thread, a month ago, and they only arrived yesterday. The odd thing is that instead of coming from China, as I expected, the package appeared to have been sent from Vanautu, which is a tiny island in the South Pacific!
 

erco

Senior Member
Thanks, delays don't phase me, it will be a while before I even have time to play. I have a pile of other must-have gadgets I haven't tried yet, all queued up. :)
 

Jeremy Harris

Senior Member
Sadly the Chinese data is full of difficult to interpret "Chinglish". I still haven't worked out what they mean by "crawl", as in "....then it automatically turn to the crawl mode".

They've mixed up some application information with the real data about the way the device operates, which doesn't really help. Anyone know what a "Dupont Line" is? (as in "...through the Dupont Line to connect to Bluetooth.....").
 

Jeremy Harris

Senior Member
Might that be a loopback issue, where the response is read as the next incoming command as infinitum?
It doesn't seem to be. It happens semi-randomly, both when I've tried to use a Picaxe to read the address or used a terminal emulator (Termite) and an FTDI module. Sometimes you can send the "query module address" command and just get a single response, with the module address. Most of the time the single command triggers the module to just send the address continuously. I've tried disconnecting the serial input to the module, in case there was some sort of interference, but the only thing that stops it is to disconnect the power.

It's not really a major bug, just a bit of a nuisance when initially programming modules and verifying that they are set correctly. The other features seem to work OK, although the modules do seem sensitive to baudrate and aren't 100% happy with the big errors in timing that exist when a Picaxe software port is used at 9600 baud with an 8MHz clock frequency. They aren't alone in that respect, though, so it makes sense to just increase the Picaxe clock frequency to 16 MHz if you want to use 9600 baud. This is a common issue, and one I've seen on several devices now.
 
Top