Implement Quadstate for some Intertechno (i.e. EIM-826) Devices

[voydz]

Hello guys,

first of all I want to thank you for your amazing work with this project. I really enjoy using it. :)

I tried to implement the switching of Intertechno outlets. The specific devices are "Unitec 4811" (rebranded Intertechno EIM-826). Those are quite common here in Germany. While I tried to decode the rf signals the output made no sense. For one button press on the remote I got 4-8 decode log outputs with different protocols (2-6).

I dug further into the topic and stumpled upon those Unitec devies using "quad-state" signals. While scanning the source code of rc-switch I noticed it only uses tri-state signals. To be honest I have no idea what the exact difference is, but I linked the resources I found to this issue. (Hopefully it is ok and it will help.)

Is it possible to include those quad-state pulse encoding and decoding mechanisms into this lib?

Some references

disucssion in FHEM forums (in german):

• https://forum.fhem.de/index.php?topic=20107.0

implementation in aculfw (custom CUL stick firmware used by FHEM):

• https://github.com/heliflieger/a-culfw/blob/master/culfw/clib/intertechno.c

best regards, Felix

[tilman]

Have you made any progress? I think i have a similar problem with my Intertechno v3 device. Preabmle: 1000000000 The zero is encoded like this: 1010 0000 and the one is encoded like this: 1000 0010 with a pulse length of 260us

This would need a protocol definition like the following, which is not possible right? { 260, { 1, 10 }, { 1, 1, 1, 5 }, { 1, 5, 1, 1 }, false },

[voydz]

Hey, I ended up ditching my Intertechno plugs for the Osram Smart Plug+ ones.

[shbatm]

Came here looking to see if this had been implemented yet. Looks like there was some work done in this repo for Raspberry Pi: https://github.com/bjwelker/Raspi-Rollo/blob/master/rcswitch-pi/sendv2.cpp

[tnn85]

I was able to switch my Unitec 48110 sockets with send(unsigned long code, unsigned int length) function of this library. The protocol however has to be set to protocol 4 (not 3 or 5 as listet by the getReceivedProtocol() function). The sender uses rolling codes (4 codes for one button) but the sockets accept only one code (implementation of rolling code is not necessary). All you have to do is to find out the 4 codes for each of the 8 buttons (button A to D ON and OFF) with the help of the getReceivedValue() function (e.g. use ReceiveDemo_Simple.ino) and send one of the codes for each action. The sockets are self-learning and accept the codes for the first button to be pressed after they are plugged in.

I hooked up my scope to find out the pulse lenght and all of them are multiples of 380µs
(e.g. "1" = 3 * 380µs "high" + 1* 380µs "low" ; "0" = 1* 380µs "high" + 3* 380µs "low" ; "sync period" for the 1st series of 4 repetitions = 1* 380µs "high" + 6380µs "low" ; "sync period" for the 2nd series of 4 repetitions = 8380µs "high" + 19*380µs "low").

The "sync period" is sent before the 24 bits are sent. However, the library works fine if the sync period is sent after. the longer sync period for the second 4 repetions doesnt seem to be necessary.

sendTriState(const char* sCodeWord) doesnt work because the protocol uses a fourth state ("bit pattern 10").

[clumsymon]

@tnn85 thanks for sharing your analysis, it works for me as well. I didn't even have to touch the sync period, all I had to do was change the protocol to 4. The real question might be why the library detected protocol 3 instead of 4 (maybe a bug?).