I picked this rather obscure USB device up from Banggood for only £6.69, it can receive and transmit codes for PT2262, PT2260, PT2264, PT2240, EV1527, HS2303-PT and the many compatible devices which means it will work with a huge number of cheap 433MHz devices such as the older OOK Energenie mains sockets and many low cost Chinese alarm sensors.
There is no English information available on these USB sticks that I could find other than the poor details on Banggood’s page and even the Chinese info is just a couple of vague screenshots so here is what I managed to figure out to make use of it. I now have this plugged into my Debian home automation server and I am using it with Node-RED to make use of some of the compatible devices I had in my collection.
If you are not familiar with the PT2262 it is a very basic, low security encoding chip for RF or IR transmission, usually paired with a PT2272 decoder on the receive end and is often used in very cheap Chinese security devices and older alarms and garage door controllers. There are lots of clones and compatible devices around too, some allowing more address space. Low range is a very common problem reported with these devices but this isn’t a fault of the encoder/decoder chips themselves, it’s just that they are usually only used in the most bargain basement of devices these days and thus paired with terrible RF components.
When plugged in this appears as a USB serial adapter and communication is fixed at 9600 8N1, there are no commands as such, it just outputs the codes received and transmits the ones sent provided they are in the correct format.
The original PT2262 has a maximum of 531,441 possible codes (12 tri-state address pins, ie. 12^3) but in most implementations I have seen only 8 are used (the rest being used as data pins) giving only 6,561 possible combinations. The decoder in this device, presumably a PT2272 only gives us the first 8 regardless of what is sent so even for the likes of the EV1527 which has a random fixed 20 bit address we will only ever see the first 8 bits here.
Inside there isn’t much to see, the bottom of the board is completely bare and on the top we can only see the CH340 USB-TTL chip and the rest is hidden under the two daughter boards. Under the black wire coil antenna there was a silk screen label YS-UTR2 but this didn’t turn up anything interesting.
Received codes are output as a hex byte representation of the binary bits that make up the code with a start and end marker, eg:
fd 51 35 d5 70 df
which breaks down as follows:
|Address byte 1||Address byte 2||Data||Pulse width||End marker
The start and end markers are always the same.
The address bytes taken together should be unique to each device (eg. remote control) and the data unique to each button or trigger on that device.
If we take those hex bytes for the address and data and convert to binary we get:
01010001 00110101 11010101
The address is tri-state, in the case of the original PT2262 this is set with jumpers that can be either Open (floating), Low or High represented in binary as:
Open (O) = 01
Low (L) = 00
High (H) = 11
Each tri-state byte relates to one of the address pins (A0 to A7 in most implementations) and then the data pins (D0 to D3). The data bits are read backwards, ie the least significant bit is on the right.
So our binary sequence of 01010001 00110101 11010101 translates as:
Or in hardware:
To transmit we need to send as hex but the start and end markers are always 99 and we have an optional transmission time and pulse width.
(optional, default 03)
|Address byte 1||Address byte 2||Data||Pulse width
(optional, default 60)
eg. to retransmit the received code shown above (fd 51 35 d5 70 df) we can send: 99 51 35 d5 70 99 or we can optionally set the transmission time eg. 99 03 51 35 d5 70 99
The pulse width relates to the oscillator resistor connected to pins 15 and 16 on the PT2262, sometimes this can be set by a jumper on the device.
From some tests it appears:
1.5M resistor = 23
3.3M resistor = 4D
4.7M resistor = 70
There are loads of compatible devices out there but most don’t shout about the fact they are using the PT2262 type chips, here are just a few I’ve come across.
Older Energenie devices such as the ENER002 plug in sockets or the ENER010 power strip are compatible and the included remote controls use the HS2303-PT encoder, I couldn’t find much on this chip but it seems to be a PT2262 compatible encoder but with fixed random address. They work brilliantly with this adapter.
There are a lot of variations on these large, ugly magnetic door/window contacts around which use the PT2264 encoder and have a bank of jumpers to set the address and key value. As they are designed as “security” devices they only trigger on opening so not terribly useful in home automation but it would be easy to connect another switching device such as a button in place of the reed switch to use for other purposes. I did look to see if if would be possibly to make it send on both open and close but it is not really feasible.
These magnetic door/window contacts with a button are much nicer, better made and much smaller, they use the HS2303-PT encoder so no jumpers to set in this one. Again it sends only on opening but does have a button built into it as well so it can be utilised without the magnet as a push button or even a door bell.
These huge, ugly, power hungry PIR movement sensors use the PT2264 encoder with jumpers to set the address and key value. I wouldn’t recommend them.
These smoke alarms use a Semic CS5211DGO which seems to be just a straightforward PT2262 clone, the address and key value are set by a bank of jumpers. They seem to work OK.
I haven’t tried them myself but the Kerui branded devices such as this button are PT2262 compatible and you can pick up a variety of fairly cheap no name transmitter boards on ebay.
Personally I am using it with one of the small HS2303-PT contacts (just using the push button), a couple of the smoke alarms and an Energenie ENER010 power strip with the included Energenie remote re-purposed to control other things via Node-RED instead of controlling the sockets directly.
Well there is none, these chips were developed in the early days of RF security devices and are susceptible to replay attacks and jamming, while the data sheets recommend them for security systems, garage doors etc. I really wouldn’t advise it for anything remotely critical.
Use with Node-RED
In my Node-RED implementation I have a serial in and out node connected to the USB port the device is on with it set to deliver binary buffers.
The input node will then give me a payload of [, , , , , ] which is a decimal representation of our orginal hex fd 51 35 d5 70 df (confused yet?). I just use a function node to concatenate the two parts of the address with the data (all in decimal) eg. 8153213 and use that as the unique code to identify the device.
msg.payload = msg.payload.toString() + msg.payload.toString() + msg.payload.toString(); return msg;
For transmission just create a buffer with the hex required and send it to the serial out node.
msg.payload = new Buffer([0x99, 0x03, 0x51, 0x35, 0xd5, 0x70, 0x99]);