Integrate RCSwitch

[sh0rez]

Hey!

I would like to integrate the RCSwitch library into esphomeyaml, to use its TriState functionality for 433mhz based wall plugs.

I HAVE seen the built in functionality for 433mhz of esphomeyaml but it wasnt able to satisfy me, as the RAW type of the data is quite hard to handle compared to basic TriState encoding. And the RCSwitch lib is working like a charm for over two years now and the wheel shouldn't need to be reinvented.

So I just thought I should be able to reimplement the RemoteTransmitterSwitch using it, but this seems to be harder than thought due to a total lack of documentation. I was unable to find anything about custom output components or at least a reference implementation of an output component.

I imagine the result as follows:

#File: home.yaml

#[...]

switch:
  - platform: rc_switch
    name: "bedroom_lamp"
    on_tristate: "F0FF00FFFF0F" #example TriState value to turn on
    off_tristate: "F0FF00FFFFF0" #example TriState value to turn on

rc_switch:
  pin: D7
  protocol: 1 #optional: RCSwitch.setProtocol()
  pulse_length: 305 #optional: RCSwitch.setPulseLength()
  

So what would be the right way of doing this?

[OttoWinter]

So I don't think this should be it's own component. The remote_transmitter is already quite advanced with its filtering + on the ESP32 it uses the internal remote peripheral which makes it extremely accurate on that device.

But for the tristate support: I'm 💯 for it :) The only reason I haven't integrated it yet into esphomelib is because I have nothing to test it. The remote_transmitter/receiver components already have these things called "protocols" (like NEC or panasonic).

Protocols are things that encode/decode remote signals, like for example IR signals but also RF signals. You would pretty much just have to add a new protocol in the esphomelib source (see panasonic.h and panasonic.cpp) and implement the tristate encoding/decoding there.

In the end, I think making a dedicated protocol would a) be easier to implement (since integrating RC Switch could end up being a bit more complicated as one might think) and b) would be more user friendly as it can take advantage of the existing remote core code. For setup, it would even enable the use of the dump: option in the remote_receiver base.

[sh0rez]

Hey!
Sounds great to me, looks like I underestimated the ability of these protocols.

How can I help? I should have enough hardware (several types of remote wall plugs, transmitter/receiver boards, several ESP8266 and ESP32), but I'm not a C/C++ developer. I have a deeper understanding of Java though, so I understand a lot of the Arduino code as well, but at the moment I'm out when it comes to anything C/C++ specific, but this is just a matter of time and experience to get there.

Something else, I already tried so dump RAW signals from my remote using these boards, leading into a crash of the whole ESP8266, printing a stack trace after 2-3 seconds. I'll try to investigate this a little further and open a seperate issue for this.

~shorez

[NiklasKroeger]

I am interested in having a more convenient way of using RF signals as well. I will take a look at the linked protocol implementations but thought the following links might be helpful since they seem to already contain some info on the RF protocol:

https://github.com/DominikPalo/esp32-rf-receiver
and the project that one is forked from:
https://github.com/sui77/rc-switch

[bthome]

@sh0rez @Niklatz Anything new on this front? I'm looking to integrate several LED strips that are controlled via RF remotes. Looking to clone them and use HA to control them via esphomelib. I have everything working with a custom sketch with rcswitch, but trying to give the new remote protocol\switch a try.

[sh0rez]

@bthome Not so far, @OttoWinter seems to be quite inactive right now and I lack good knowledge of C/C++ so i cannot really help but would love to see progress on this topic!

[NiklasKroeger]

@bthome too many different side projects. I did not try anything yet.

But looking at the other linked projects it looks like the manufacturers of these 433MHz devices cant decide on a common way to define High and Low levels. The timings differ between devices. So I think that would definitely be something that would have to be considered in the parser function. Something like they do in rc-switch would probably work and be flexible to allow new device protocols to be added. Those timings could perhaps be part of the yaml configuration file with an overview of examples for different devices in the documentation instead of hardcoding them in the .cpp files of esphomelib.

[TheJulianJES]

Uh, I'm also trying to integrate a simple on/off switch for an RF outlet. Previously I used my own sketch with RC-Switch but I thought that the function was kinda already integrated. https://esphomelib.com/esphomeyaml/components/switch/remote_transmitter.html#finding-remote-codes describes how to send the RF codes but is it currently possible to send "one rf code" when turning on the switch and another rf code when the switch should be turned off? Or is this what is requested in the "issue" here?

[OttoWinter]

@TheJulianJES The remote transmitter switches are only meant to transmit something when they are turned on. So they're not really switches per se, but more like "do this action once". They way to have an IR switch with a turn on/off action is like this:

switch:
  - platform: template
    name: "Living Room Light"
    optimistic: True
    turn_on_action:
      switch.turn_on: light_ir_code_on
    turn_off_action:
      switch.turn_on: light_ir_code_off

Like @NiklasKroeger said, each manufacturer has their own encoding format for these actions. And the projects like rc-switch do have these pre-implemented. Using the existing remote transmitter base in esphomelib it wouldn't be hard to implement these different types encodings, the problem is that I have no way to test the code for me and I still need to figure out a way of pushing alpha/beta/release versions.

[bthome]

@OttoWinter If you can lead the way I will try testing. I have had success with RCSwitch...captured the binary and 24bit codes. I can test a custom component until if gets merged into the library.

If you don't have the time right now any pseudo code and I can try to see if I can fill in the blanks.

Thanks.

[TheJulianJES]

@OttoWinter Yeah, I also figured that out meantime. It also kinda works although I have the same problem that @sh0rez has with capturing the raw codes.

[sh0rez]

@TheJulianJES if you mean this

Something else, I already tried so dump RAW signals from my remote using these boards, leading into a crash of the whole ESP8266, printing a stack trace after 2-3 seconds. I'll try to investigate this a little further and open a seperate issue for this.

then i can't provide a fix on the ESP8266 but for me it worked with the same config on an ESP32.
This still does not mean I had success, my ESP keeps mostly rubbish so I am not able to find the 433 Code im interested in.

The filter options don't seem to have some any impact. And I'm unsure if my receiver is even working (using this one)

So as this probably leads into nothing, I would suggest @OttoWinter to provide some help. So, as you made wrote the code and probably tested it, could you provide a schematic of an ESP8266/32 with a 433mhz receiver module connected to it along with a esphomeyaml config to capture the RF Codes of a regular wall plug (e.g. this one).

Would be a good place to start,
~shorez

[TheJulianJES]

@sh0rez Yep, I sadly don't own an ESP32 yet. I tried to switch from my lightning + RC Switch sketch to esphomeyaml // esphomelib as it's just perfect for modularity like that. I'll try to see if I can integrate RC Switch in the autogenerated c++ classes.

[sh0rez]

@TheJulianJES don't waste your time on integrating something new into the autogenerated code of esphomeyaml. This is not even a temporary solution as it violates the whole idea of esphomelib and esphomeyaml.

This is a feature and it needs to be integrated into the framework. I see @OttoWinter's point with the already existing rf code in the framework and it might work for our needs but we need to test it, which is only possible if somebody who knows how to do it (@OttoWinter 😉) gives us additional documentation and examples as I've already requested.

Another concern of me is whether it's needed to create the n-th rf-library-like-thing for arduino, while bigger projects like RCSwitch solved the problem already .. I think we do not really need to reinvent the wheel another time.

[TheJulianJES]

@sh0rez Well, it only would be a temporary solution, but I think that @OttoWinter is still on (a well deserved) vacation. I'll see if I can atleast make a copy-paste solution for the generated file.

[sh0rez]

@TheJulianJES Do what you need 😄. I would be interested in the result tho, if it works out, would you mind creating a gist?

~shorez

[TheJulianJES]

Yeah, sure. I'll try to do it tomorrow.

[OttoWinter]

Integrated now