New switch?: Cotech (from Clas Ohlson)
First post, so a shout out for the incredible work everybody has done with Pimatic!
I have run in to a switch branded Cotech sold by Clas Ohlson.
Before attempting to implement its protocol:
Regards,
Charles
@charles said:
First post, so a shout out for the incredible work everybody has done with Pimatic!
always nice to hear, thanks a lot!
welcome to the wonderful world of pimatic 
Is it a re-branded version of switch the protocol of which has already been implemented?
it’s a good question. do you already have it? if yes you could check at the debug messages of homeduino if there is a matching protocol.
pimatic v0.9 has been released!
Support Pimatic and get some free stickers
Like us on Facebook
make it so !
Thank you for your response!
I’ve got one and will check debug messages.
@charles said:
Is it a re-branded version of switch the protocol of which has already been implemented?
Possibly. So, please post debug messages here.
"It always takes longer than you expect, even when you take into account Hofstadter's Law.", Hofstadter's Law
Sorry to necro this old thread!
It seems as the Original poster never came back with the results.
I acquired some of these said Cotech devices (Clas ohlson had a really good sale of 9 eur/3pack).
On pimatic 0.9, the remote is being recognized as “rollingCode”. This is a new switch type for me, as my previous, Nexa switches are the Switch-1 type.
The remote has buttons A: Off/On,B Off/On,C Off/On,D Off/On. I’ve seen similar button naming with “SilverCrest” branded remotes.
Info on the remote:
Cotech
36-6010/18-1255
Type:50074
Frequency:433.92MHz
@mwittig , @developer could you help me figure out this? From what I gather, this might need a new protocol.
Here’s some debug (kept pressing the button so we get multiple rows)
A
---------
ON
rolling1: { code: '101101101011100100011100' }
received: [ 512, 1004, 2960, 7176 ] 10011010011010011001101010010110010101101010010123
data: "RF receive 1004 512 2960 7176 0 0 0 0 01100101100101100110010101101001101010010101101023"
rolling1: { code: '101110101111011001101100' }
received: [ 524, 992, 2956, 7184 ] 10011010100110011010101001101001011010011010010123
data: "RF receive 992 524 2956 7184 0 0 0 0 01100101011001100101010110010110100101100101101023"
rolling1: { code: '101111100010000110101100' }
received: [ 504, 1012, 2960, 7176 ] 10011010101010010101100101010110100110011010010123
data: "RF receive 1012 504 2960 7176 0 0 0 0 01100101010101101010011010101001011001100101101023"
rolling1: { code: '101111011000110101011100' }
received: [ 516, 1000, 2956, 7176 ] 10011010101001101001010110100110011001101010010123
data: "RF receive 1000 516 2956 7176 0 0 0 0 01100101010110010110101001011001100110010101101023"
received: [ 508, 988, 2940, 7164 ] 10011010011010011001101010010110010101101110010123
data: "RF receive 988 508 2940 7164 0 0 0 0 01100101100101100110010101101001101010010001101023"
OFF
rolling1: { code: '101101110101001101111100' }
received: [ 520, 996, 2960, 7172 ] 10011010011010100110011001011010011010101010010123
data: "RF receive 996 520 2960 7172 0 0 0 0 01100101100101011001100110100101100101010101101023"
rolling1: { code: '101100111010111110111100' }
received: [ 528, 988, 2964, 7156 ] 10011010010110101001100110101010100110101010010123
data: "RF receive 988 528 2964 7156 0 0 0 0 01100101101001010110011001010101011001010101101023"
rolling1: { code: '101100100001011110001100' }
received: [ 500, 1016, 2956, 7172 ] 10011010010110010101011001101010100101011010010123
data: "RF receive 1016 500 2956 7172 0 0 0 0 01100101101001101010100110010101011010100101101023"
rolling1: { code: '101101010011101000101100' }
received: [ 504, 1012, 2952, 7148 ] 10011010011001100101101010011001010110011010010123
data: "RF receive 1012 504 2952 7148 0 0 0 0 01100101100110011010010101100110101001100101101023"
B
---------
ON
received: [ 444, 916, 2936, 7192 ] 10011011110101011111011111010101010101010111011123
data: "RF receive 916 444 2936 7192 0 0 0 0 01100100001010100000100000101010101010101000100023"
received: [ 516, 984, 2948, 7176 ] 10011010010101100110101101100110101010010110011023
data: "RF receive 984 516 2948 7176 0 0 0 0 01100101101010011001010010011001010101101001100123"
rolling1: { code: '101111000000111011110101' }
received: [ 520, 996, 2952, 7184 ] 10011010101001010101010110101001101010100110011023
data: "RF receive 996 520 2952 7184 0 0 0 0 01100101010110101010101001010110010101011001100123"
received: [ 488, 968, 2944, 7176 ] 10011010100101101110010101010101010111100111011023
data: "RF receive 968 488 2944 7176 0 0 0 0 01100101011010010001101010101010101000011000100123"
rolling1: { code: '101110001101100000000101' }
received: [ 492, 1024, 2940, 7188 ] 10011010100101011010011010010101010101010110011023
data: "RF receive 1024 492 2940 7188 0 0 0 0 01100101011010100101100101101010101010101001100123"
received: [ 504, 940, 2952, 7172 ] 10011010010101100110101101100110111010010111011123
data: "RF receive 940 504 2952 7172 0 0 0 0 01100101101010011001010010011001000101101000100023"
OFF
rolling1: { code: '101100001110001011000101' }
received: [ 500, 1016, 2956, 7180 ] 10011010010101011010100101011001101001010110011023
data: "RF receive 1016 500 2956 7180 0 0 0 0 01100101101010100101011010100110010110101001100123"
rolling1: { code: '101111110110101101000101' }
received: [ 524, 992, 2960, 7188 ] 10011010101010100110100110011010011001010110011023
data: "RF receive 992 524 2960 7188 0 0 0 0 01100101010101011001011001100101100110101001100123"
rolling1: { code: '101110111001110011010101' }
received: [ 524, 992, 2956, 7176 ] 10011010100110101001011010100101101001100110011023
data: "RF receive 992 524 2956 7176 0 0 0 0 01100101011001010110100101011010010110011001100123"
rolling1: { code: '101101000100010010010101' }
received: [ 492, 1024, 2952, 7180 ] 10011010011001010110010101100101100101100110011023
data: "RF receive 1024 492 2952 7180 0 0 0 0 01100101100110101001101010011010011010011001100123"
received: [ 496, 1000, 2956, 7180 ] 10011010010101011010100101011001111001010110011023
data: "RF receive 1000 496 2956 7180 0 0 0 0 01100101101010100101011010100110000110101001100123"
C
--------
ON
received: [ 508, 896, 2948, 7192 ] 10011010011010100110011101011011011110111111110123
data: "RF receive 896 508 2948 7192 0 0 0 0 01100101100101011001100010100100100001000000001023"
received: [ 488, 848, 2944, 7188 ] 10011010010111111101110110101111110111111111110123
data: "RF receive 848 488 2944 7188 0 0 0 0 01100101101000000010001001010000001000000000001023"
received: [ 500, 996, 2948, 7188 ] 10011010010110010101011001101010110101011010100123
data: "RF receive 996 500 2948 7188 0 0 0 0 01100101101001101010100110010101001010100101011023"
received: [ 508, 988, 2948, 7188 ] 10011010011001100101101011011001010110011010100123
data: "RF receive 988 508 2948 7188 0 0 0 0 01100101100110011010010100100110101001100101011023"
received: [ 464, 844, 2948, 7184 ] 10011010011111110111011101011111011111111111110123
data: "RF receive 844 464 2948 7184 0 0 0 0 01100101100000001000100010100000100000000000001023"
OFF
received: [ 484, 924, 2944, 7188 ] 10011011111011010101100101010111110111011010100123
data: "RF receive 924 484 2944 7188 0 0 0 0 01100100000100101010011010101000001000100101011023"
received: [ 476, 876, 2940, 7192 ] 10011010111101111101010110110111011101111110110123
data: "RF receive 876 476 2940 7192 0 0 0 0 01100101000010000010101001001000100010000001001023"
received: [ 468, 880, 2948, 7184 ] 10011010011011011101111111010111010101111111110123
data: "RF receive 880 468 2948 7184 0 0 0 0 01100101100100100010000000101000101010000000001023"
received: [ 516, 916, 2948, 7184 ] 10011010100110011010111001101001011111011011110123
data: "RF receive 916 516 2948 7184 0 0 0 0 01100101011001100101000110010110100000100100001023"
D
--------
ON
received: [ 492, 880, 2944, 7180 ] 10011110110111111001011110110101111001100110111123
data: "RF receive 880 492 2944 7180 0 0 0 0 01100001001000000110100001001010000110011001000023"
received: [ 484, 972, 2952, 7192 ] 10011011011101010110010101100101110101100110101023
data: "RF receive 972 484 2952 7192 0 0 0 0 01100100100010101001101010011010001010011001010123"
received: [ 496, 980, 2964, 7172 ] 10011010010101011010110101011001101001010111101023
data: "RF receive 980 496 2964 7172 0 0 0 0 01100101101010100101001010100110010110101000010123"
received: [ 488, 872, 2928, 7196 ] 10011011111111110111110110011110011001010110111123
data: "RF receive 872 488 2928 7196 0 0 0 0 01100100000000001000001001100001100110101001000023"
received: [ 448, 580, 848, 2900, 7200 ] 22022220220222222202022022220202212202220222222234
data: "RF receive 848 448 580 2900 7200 0 0 0 00100001001000000010100100001010020010001000000034"
received: [ 480, 976, 2948, 7160 ] 10011010011001010110010101110101110101100110101123
data: "RF receive 976 480 2948 7160 0 0 0 0 01100101100110101001101010001010001010011001010023"
received: [ 476, 928, 2928, 7192 ] 10011111010101011010110101011001101101010111101123
data: "RF receive 928 476 2928 7192 0 0 0 0 01100000101010100101001010100110010010101000010023"
OFF
received: [ 420, 836, 2936, 7192 ] 11011111010101110111111101110111111111010111111123
data: "RF receive 836 420 2936 7192 0 0 0 0 00100000101010001000000010001000000000101000000023"
received: [ 416, 836, 2932, 7208 ] 11011111111101010101010111111101111111110111111123
data: "RF receive 836 416 2932 7208 0 0 0 0 00100000000010101010101000000010000000001000000023"
received: [ 496, 980, 2936, 7184 ] 10011010100101101010010101010101010110100110111123
data: "RF receive 980 496 2936 7184 0 0 0 0 01100101011010010101101010101010101001011001000023"
received: [ 484, 972, 2940, 7188 ] 10011010110101011010011010010101010101010110111123
data: "RF receive 972 484 2940 7188 0 0 0 0 01100101001010100101100101101010101010101001000023"
received: [ 484, 884, 2940, 7184 ] 10011010010101110111101001100111111111010111111123
data: "RF receive 884 484 2940 7184 0 0 0 0 01100101101010001000010110011000000000101000000023"
received: [ 488, 892, 2940, 7188 ] 10011011101101010101010110111101101011110111101123
data: "RF receive 892 488 2940 7188 0 0 0 0 01100100010010101010101001000010010100001000010023"
I did find this: http://www.instructables.com/id/Control-CoTech-Remote-Switch-With-Arduino-433Mhz/?ALLSTEPS
However this is a bit older version. Receivers look the same though.
The exact device I have is http://www.clasohlson.com/fi/Kaukokytkin-3-kpl,-Cotech-Smart-Home/36-6010
Edit
I’m starting to understand this “rolling code” thing. So heres a dump of my remote’s rolling codes. There are 4 codes for each button.
A ON
101101101011100100011100
101110101111011001101100
101111011000110101011100
101111100010000110101100
A OFF
101101110101001101111100
101101010011101000101100
101100100001011110001100
101100111010111110111100
B ON
101100010111010111100101
101110011100000000110101
101111000000111011110101
101110001101100000000101
B OFF
101110111001110011010101
101100001110001011000101
101101000100010010010101
101111110110101101000101
C ON
101101010011101000101110
101101110101001101111110
101100111010111110111110
101100100001011110001110
C OFF
101110101111011001101110
101111100010000110101110
101101101011100100011110
101111011000110101011110
D ON
101101000100010010010111
101100001110001011000111
101110111001110011010111
101111110110101101000111
D OFF
101110001101100000000111
101110011100000000110111
101100010111010111100111
101111000000111011110111
I made a pimatic device with rollingcode1 protocol, with the rolling codes in ON/OFF states. Pimatic picks up the changes in state (if i press until a rolling code appears, it doesnt appear always instantly). Unfortunately it does not work on sending, yet. So I think this is atleast somehow different than rollingcode1, could it even be that this isn’t rolling code at all? . 
Edit 2
I found this post, which has the exact same device mentioned:
https://www.domoticz.com/forum/viewtopic.php?f=17&t=15306&p=112883&hilit=cotech#p112883
I found out something new!
It seems like that TellDus (Tellstick) and RFXCom have support for this protocol, and they have added it quite recently.
Apparently the original name for this is “KANGTAI”
Telldus’s Github has a python file describing the protocol.
Unfortunately I don’t make much out of this file, but I am pretty sure one of the @developer s have a hunch on this
Here’s the Github Link for their repo (https://github.com/telldus/tellstick-server/blob/master/rf433/src/rf433/ProtocolKangtai.py)
According to Domoticz forum user, the device working with RFXCom outputs this kind of details:
#ID of the device stays constant on remote
ID = 22F6 decimal:8950
#Units are 1-4
Unit = 1
#Command On/Off
Command = On
Btw @mwittig I just realized that this probably should be on the Developing section of forum… sorry.
Edit
So if I followed the protocol mapping page correctly, these should be somewhat accurate. binary 1/0 definition still missing.
# mapping for decoding
pulsesToBinaryMapping = {
'10': '' #header
##'0100': '1' #binary 1
##'0001': '0' #binary 0
'23': '' #footer
}
# same for send
binaryToPulse = {
##'1': '0100'
##'0': '0001'
}
brands: ["Cotech", "Kangtai"]
pulseLengths: [504, 1012, 2960, 7176]
pulseCount: 50
This protocol does not have “All off” button, as far as I know. Which protocol should I use as a template for testing?
why not use the rollingcode protocol as switch like that?
try the below device, i already put in your above switch a codes
{
"id": "testswitch_a",
"name": "Test A",
"class": "HomeduinoRFSwitch",
"protocols": [
{
"name": "rolling1",
"options": {
"codeOn": [
"101101101011100100011100",
"101110101111011001101100",
"101111011000110101011100",
"101111100010000110101100"
],
"codeOff": [
"101101110101001101111100",
"101101010011101000101100",
"101100100001011110001100",
"101100111010111110111100"
]
}
}
]
}
but i see, you have created a new protocol for it, right?
so why not integrate into homeduino
actually we’re at shutter30, so you could go ahead with shutter31 i suppose
https://github.com/pimatic/rfcontroljs/tree/master/lib/protocols
pimatic v0.9 has been released!
Support Pimatic and get some free stickers
Like us on Facebook
make it so !
Thanks for the response!
That’s what I did last night, and it is recognized on receive. However I think this is not really a rolling code (I might be wrong because I am trying to learn this protocol development still).
The reason I say that is, I need to press the button sometimes 1 second, sometimes 15 seconds until pimatic recognizes the pattern as rolling code. I think this is just a falsely recognized protocol. On top of that, sending does not work at all.
I’m trying to create a protocol, true! I’m still making baby-steps with that though!
If you see the Domoticz clip I posted on earlier post, doesn’t it seem more like a switch1 type than something else?
I will make a double check on the rolling code today after work, though.
Investigation continues, I found a github documentation with a bit of clarification! This is getting interesting!
Especially that this github file has documented the very layout of the protocol! See below!
/*
* Kangtai Switches (Commonly used in Cotech devices from Clas Ohlson)
*
* Copyright (c) 2016, Mark Olsson <mark.olsson@telldus.se>
*
* Devices tested:
* - Cotech 4 channel remote control 36-6361
* - Messages from TellStick Net sending this protocol
*
* Protocol:
* Start bit = 375us high, 2250us low
* followed by 24 bits of data
* One = 1125us high, 375us low
* Zero = 375us high, 1125us low
*
* Data layout:
* 16 bit address of transmitter
* 2 bit rolling code (00, 01, 10, 11)
* 1 bit device command (1 = On, 2 = Off)
* 5 bit unit address (00000 = group, 11111 = factory use only)
* Data is 'decrypted' with a lookup table
*
*/
#include "rtl_433.h"
#include "util.h"
static int kangtai_callback(bitbuffer_t *bitbuffer) {
uint8_t *bytes = bitbuffer->bb[0];
data_t *data;
uint8_t a0, a1, a2, a3, a4, a5;
uint8_t b0, b1, b2, b3, b4, b5;
uint16_t address;
// Get the current time
char time_str[LOCAL_TIME_BUFLEN];
local_time_str(0, time_str);
/* Decryption lookup table */
char table1[] = { 1, 8, 4, 14, 2, 7, 13, 6, 15, 12, 0, 10, 3, 11, 5, 9 };
char table2[] = { 15, 6, 0, 11, 5, 2, 10, 4, 12, 13, 14, 8, 1, 9, 3, 7 };
/* Check for 24 bits of data, then invert each bit */
if (24 != bitbuffer->bits_per_row[0]) return 0;
bitbuffer_invert(bitbuffer);
/* Decrypt data */
/* Split data into 4 bit groups */
a5 = (bytes[0] >> 4) & 0x0F;
a4 = bytes[0] & 0x0F;
a3 = (bytes[1] >> 4) & 0x0F;
a2 = bytes[1] & 0x0F;
a1 = (bytes[2] >> 4) & 0x0F;
a0 = bytes[2] & 0x0F;
/* If bit 21 = 0, use lookup table 1, else table 2 */
if ((a5 & 2) == 0) {
b5 = a5 ^ 9;
b4 = table1[a4] ^ a3;
b3 = table1[a3] ^ a2;
b2 = table1[a2] ^ a1;
b1 = table1[a1] ^ a0;
b0 = table1[a0];
} else {
b5 = a5 ^ 9;
b4 = table2[a4] ^ a3;
b3 = table2[a3] ^ a2;
b2 = table2[a2] ^ a1;
b1 = table2[a1] ^ a0;
b0 = table2[a0];
}
/* Assign decrypted data back to byte array */
bytes[0] = (b5 << 4) | b4;
bytes[1] = (b3 << 4) | b2;
bytes[2] = (b1 << 4) | b0;
// Assign first 16 bits to the device address
address = (bytes[0] << 8) | bytes[1];
data = data_make(
"time", "Time", DATA_STRING, time_str,
"model", "Model", DATA_STRING, "Kangtai",
"address", "Address", DATA_FORMAT, "%x", DATA_INT, ((bytes[0] << 8) | bytes[1]),
"loop", "Loop", DATA_FORMAT, "%d", DATA_INT, ((bytes[2] >> 6) & 3),
"command", "Command", DATA_STRING, ((bytes[2] >> 5) & 0x01) ? "on" : "off",
"unit", "Unit", DATA_FORMAT, "%d", DATA_INT, (bytes[2] & 0x1F),
NULL
);
data_acquired_handler(data);
return 1;
}
static char *output_fields[] = {
"time",
"model",
"address",
"loop",
"command",
"unit",
NULL
};
r_device kangtai = {
.name = "Kangtai",
.modulation = OOK_PULSE_PWM_RAW,
.short_limit = 700,
.long_limit = 1400,
.reset_limit = 1400,
.json_callback = &kangtai_callback,
.disabled = 0,
.demod_arg = 0,
.fields = output_fields
};
Looks very promising.
So what you need to do first is decrypt the above 24 bit code using the lookup table. After that you can get the following from the resulting code:
@rrooggiieerr
Yep! It could be that I could actually use a rollingcode switch for this, but there could be something off with the timings of “rolling1” protocol, because it is not recognized on more than 1/10th of presses.
Though it would be cool if we could create a protocol that can “decrypt” that table and handle the switches with their Units and IDs straight away.
Truth be told, I kind of hoped that my first try on making a protocol wouldn’t include this kind of magical things like rolling codes and lookup tables.
edit
Tested with rollingcode1 protocol again, nothing there. Tried also with rawswitch, nothing there either.
So what this means, is that one of those telldus solutions should probably be converted into coffeescript. This might be a pickle …
I gave it a try to implement the C code in Coffee Script
# The 4 different codes for A on
bytes = 11974940 # A on 1
#bytes = 12252780 # A on 2
#bytes = 12422492 # A on 3
#bytes = 12460460 # A on 4
# Decryption lookup table
table1 = [ 1, 8, 4, 14, 2, 7, 13, 6, 15, 12, 0, 10, 3, 11, 5, 9 ]
table2 = [ 15, 6, 0, 11, 5, 2, 10, 4, 12, 13, 14, 8, 1, 9, 3, 7 ]
# Decrypt data
# Split data into 4 bit groups
a5 = (bytes >> 20) & 0x0F
a4 = (bytes >> 16) & 0x0F
a3 = (bytes >> 12) & 0x0F
a2 = (bytes >> 8) & 0x0F
a1 = (bytes >> 4) & 0x0F
a0 = bytes & 0x0F
# If bit 21 = 0, use lookup table 1, else table 2
if ((bytes & 0x100000) == 0)
b5 = a5 ^ 9
b4 = table1[a4] ^ a3
b3 = table1[a3] ^ a2
b2 = table1[a2] ^ a1
b1 = table1[a1] ^ a0
b0 = table1[a0]
else
b5 = a5 ^ 9
b4 = table2[a4] ^ a3
b3 = table2[a3] ^ a2
b2 = table2[a2] ^ a1
b1 = table2[a1] ^ a0
b0 = table2[a0]
# Assign decrypted data back to byte array
bytes = b5 << 20
bytes += b4 << 16
bytes += b3 << 12
bytes += b2 << 8
bytes += b1 << 4
bytes += b0
# Data layout:
# 16 bit address of transmitter
# 2 bit rolling code (00, 01, 10, 11)
# 1 bit device command (1 = On, 2 = Off)
# 5 bit unit address (00000 = group, 11111 = factory use only)
address = (bytes >> 8) & 0xFFFF
rollingCode = (bytes >> 6) & 0x03
command = ((bytes >> 5) & 0x01) == 1
unit = bytes & 0x1F
There were some typos in my code, I modified above code and now it successfully decrypts the code
@rrooggiieerr Holy smokes batman, thats awesome!
@rrooggiieerr nice work! What about a pull request 😀
pimatic v0.9 has been released!
Support Pimatic and get some free stickers
Like us on Facebook
make it so !
@leader21 My above code only handles the decoding, it’s not yet a full protocol implementation. Also there is no documentation on the encoding.
On a side note, the C code @kitsunen refered to and on which I based my decoding implementation is part of https://github.com/merbanan/rtl_433 which seems to contain a lot of implementations of various protocols. Defenetly a good source for reference implementations. Only encoding though since they use an RTL 433 dongle which is only a receiver, and no transmitter. I think having RTL 433 support in pimatic for receiving different kinds of signals would be an interesting approach.
Might have found something on the encoding, this, however is a year old, which might mean it being for some older switch version. Might be valid, though. Looks a bit plain though.
https://github.com/skagmo/multitrx/blob/master/firmware/1.3/kangthai.c
@kitsunen That code doesn’t realy make sense to me. I would expect some kind of a lookup table like in the decoding is used
@rrooggiieerr Yeah, I agree with you .
Though, there might be a case with the receivers not being “pure” rolling code.
What I mean, is that the same rolling code might work every time. Could this remove the need of a lookup table with sending?
Thanks!
@rrooggiieerr sorry, I misunderstood!
pimatic v0.9 has been released!
Support Pimatic and get some free stickers
Like us on Facebook
make it so !