HomeEasy support about rc-switch HOT 4 CLOSED

Well, this library is mostly about supporting switches, not more complicated stuff... but I see no fundamental reason why not to add support for that, if it fits in sensible.

But to write such code, one needs a HomeEasy device in order to test and debug it. So I certainly won't do it.

But if somebody (perhaps you?) sends a patch or tells us otherwise what changes to make, we will definitetly consider it. In that case, please submit a pull request, or if that is beyond your tech skills, an issue with the code.

Note: on a quick glance, it seems that the low level encoding matches our protocol 1 ("pulses are expected to be either 375us or 1125us" is close enough to 1_350us and 3_350 = 1050us). Perhaps one of the existing switchOn() / switchOff() or send() method can already be used?

from rc-switch.

I have a Homeeasy. Sending worked after setting pulse width to 325
with mySwitch.setPulseLength(325);
and send with mySwitch.switchOn('d',2);

Hope this helps

from rc-switch.

The comment above appears to be using the HomeEasy 200 system, which sends a 'house code'(A to P) and a unit number.
I'm looking into this as someone with the newer HomeEasy switches (HRR3). This uses a 26bit 'id' code, a 'group' bit, an 'on/off' bit and a four bit button id (controlling up to 16 sockets with one remote).
The RCSwitch receive code doesn't pick up anything from the remote, but using another library I've managed to determine the relevant codes.

So, the principle appears to be to send a latch code, a 32bit code as manchester pairs, then a second latch code.
The final gotcha is that the sockets don't seem to respond reliably unless you send the code twice.

Hope this is helpful. I'm afraid I don't know enough about how RCSwitch works to convert that into useful code, but am happy to test if someone else can!

Edit: Should I open a new issue for this?

from rc-switch.

Duplicate of #124?

from rc-switch.