Open source ESPHome IR blaster?

ESPHome
21

I am able to get CB3S working with IR commands successfully. I am new to esphome and home assistant, I am learning a lot from this community. I have 5 x Tuya based IR blasters for controlling my Ceiling Fans which works with IR remotes (2 different models from 2 different vendors), LG TV and STB. I wanted to make the IR blasters cloud free, checking about any possible solution for long time but I could not do it since they are not using esp82xx. I was skeptical about chip replacement since I am still trying to master the skill of good soldering myself. Finally got to know about Libretiny and its integrations with esphome/home assistant. After knowing about it, I was able to flash the IR blasters successfully. Below given are my chip model and Firmware version before flashing. Sharing here which may be useful to someone else.
In those IR blasters 2 of them running with WE3S which required some soldering to connect the headers. This helped me to put the chips in flashing mode to push esphome in them. This chip model runs good with esp01_1m as the board post flashing.

Model: WB3S - SW Version 1.0.4 (No chip replacement or soldering required). We don’t even have to open the factory case that it comes with.

My YAML is as given below.

esphome:
  name: ir-blaster
  friendly_name: IR-Blaster

bk72xx:
  board: generic-bk7231n-qfn32-tuya #For wb3s

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
   key: "Update your Key here"
      
ota:
  password: "Update your Key here"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  manual_ip:
    static_ip: your.ip.address
    gateway: your.gateway.ip
    subnet: your.subnet.ip
    dns1: your.dns1.ip

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "your ssid"
    password: "your password"

captive_portal:

web_server:
  port: 80

status_led:
  pin: P8

remote_receiver:
- id: IR_RX  
  pin:
    number: P7
    inverted: true
    mode:
      input: true
      pullup: true
  dump: 
       - raw

remote_transmitter:
  - id: IR_TX  
    pin: P26
    carrier_duty_percent: 50%

sensor:
  - platform: wifi_signal
    name: "WiFi Signal"
    update_interval: 1h
    
  - platform: uptime
    name: "Uptime"
    update_interval: 1h

text_sensor:
  - platform: wifi_info
    ip_address:
      name: IP Address
    ssid:
      name: SSID
    mac_address:
      name: MAC
1 Like
22

Great to hear people are able to flash devices like this with ESPHome again using LibreTiny…just like the good old Tuya-convert days…

23

Thanks for sharing your code.

Can you help me getting how to get the codes for I’m different remotes?

Still haven’t figured out how to read them.

Thank you

24

@cikaybe Assuming your IR Blaster works and you flashed the YAML, I believe all you need to do is to start the log and then point your remote and press the button you want to replicate. The codes received will appear in the log. Without trying it again I can’t recall the exact details but I believe it gives you several different code options. If I recall correctly I picked NEC or Pronto, but I am not sure. I can look into it if you can’t figure it out.

1 Like
25

do you have a link to the exact product you purchased?

26

I’ve made my own custom ones :slight_smile:

Will make a thread when the cases are printed later on

2 Likes
27

I bought the tasmota ir controller from athom.tech, then flashed esphome onto it. Works pretty good for 15€

1 Like
28

That’s cool, I like that! I forget where I saw it or read it not long ago but, it was the same topic IR range and needing a clear line of sight and the shortcomings of IR. Now this probably wouldn’t be practical for everywhere but this person made a similar device as yours but instead of IR transmitters they used an RF transmitter. So, IR signals would come in and then they’d be converted, then transmitted long range, through walls, up/down different story’s of a house, etc. and then whichever RF receiver that code went to and triggered a sensor state change, it would then be converted back to the original IR code (from upstairs) and then transmitted via IR to the desired device in the house. I thought that was pretty clever. I get that you could do that through HA automations or other possibilities but, I like keeping automations on the esp’s whenever possible and therefore very reliable.

2 Likes
29

Thanks :slight_smile:

Here’s it sitting in the case finally ready: ESP32 IR Blaster (Transmitter/Receiver) - Long Range

Interesting about the RF relay, I was actually thinking about adding that to this unit but I already have a bunch of RF boards sitting around and just used those in the end.

Definitely easy for me to add in a future version though :wink:

1 Like
30

I dont know how to put this nicely but, if i was an IR remote, id hit it! I meant to ask about the case in my initial rambling post and forgot… Im curios though. It looks like its meant to sit flat like in the photos. Does pointing all the led’s vertical effect the range at all? As much as I do like it, I think if there were only minimal negative effects from the leds on the sides instead, i personally would like that more. Not that my opinion matters here, i’m just saying for the sake of feedback.

Something else im curious about. What kind of testing did you do when planning this? Did you find a meaningful difference between the final number of leds and say half as many? I guess im just wondering how you landed on that number.

1 Like
31

Why does one need RF if you have wifi from the esp33 already. Is it wall penetration and range that’s more important with RF?

1 Like
32

:joy:

I actually went for vertical because it’s the same way I had my RM4 mounted/pointing… But so far in testing I’ve pointed it in all directions without missing a signal.

I was initially planning to bend the LEDs over and point them at different angles until it didn’t seem necessary in the tests :slight_smile:

Planning is over-rated :wink: I picked 9 LEDs half at random and half based on current/voltage drop calculations

3 Likes
33

It still looks good though. I havnt spent much time looking into it, but why does it seem like the IR leds that come in something like an Arduino/esp transmitter/receiver kit are nowhere near as good as your common TV remotes?

1 Like
34

Having done a little bit of looking into it, they basically all use very cheap LEDs. Common TV remotes always have at least one (sometimes 2) decent IR LEDs as well as some sort of cone or lens to focus the signal more

35

Hi, These are generally Tuya variants. The one I bought is via Amazon India, the brand name is Teqooz that costed me 10$. You can find it here

36

Looks like LibreTiny is opening up ESPHome takeovers for some more Tuya devices again.

38

Just got this one working… Code’s there in case it might help at all.
Anyone got any good ideas for improving it?
Theres a button that I havent used, and the LEDs only showing status in case of error…

39

You want to flash the status light after each command you send probably:

        - light.turn_on: status_light
        - delay: 60ms
        - light.turn_off: status_light

Personally I use a lazy “on” tracker, this way:

globals:
  - id: last_action
    type: int

binary_sensor:
  - platform: template
    name: "TV Tracker Internal"
    id: tv_tracker_internal
    internal: true
    on_state:
      then:
        - lambda: |-
            id(last_action) = millis()/1000ULL;
        - light.turn_on: status_light
        - delay: 60ms
        - light.turn_off: status_light

Then after each TX command I run this:

- lambda: id(tv_tracker_internal).publish_state(true);

(or false if it’s a power off command)

40

Thanks.
Light’s flashing with each command sent now. Probably the best use there is for the LED tbh
Added a bunch more buttons and icons for them too.

I like the idea of tracking if the TVs on or off, but the TVs own remote is used as well. I guess that’d mean it’d often end up wrong?

I like the idea of using a multidimensional array to hold the button details and their remote codes, rather than a long list of mixed code/data, but I’m still getting that working. It’d mean adding more buttons/codes would just be adding them to a ‘table’ rather than copy/pasting and then changing chunks of code for each.
It might just be complicating it unneccessarily though.

Some way to automate capturing codes would be good, but I’m not sure how to start with that yet. At least for me, capturing them is still hit-and-miss enough that it might have to stay a manual process.
I’ve settled on capturing a buttons codes maybe 5-10 times, then creating buttons for each and trying them out multiple times. The one that performs most reliably and/or fastest is kept.
There might be a way to automate that, but it’s beyond me at the moment… Learning a lot right now though, so maybe
I haven’t been able to find any existing examples of doing something like that, anyone aware of anything similar pls?

41

I haven’t done this myself but it might work out well to use yaml anchors for duplicating command sections actually… My templates are quite long so I should play with that :slight_smile:

Here’s what I do as far as a better way to learn commands - needs more customisation for the various protocols though, I just use pronto and sony here.

You switch the learn command switch on, fire an IR command, then the switch will turn off and you get the data in the sensor.


switch:
  - platform: template
    name: Learn Command
    id: remote_learn_switch
    optimistic: true

text_sensor:
  - platform: template
    name: Learned Command
    id: learned_command

remote_receiver:
  pin: 
    number: GPIO25
    inverted: true
  dump: all
  # on_sony:
  #   - if:
  #       condition:
  #         lambda: 'return id(remote_learn_switch).state;'
  #       then:
  #         - lambda: |-
  #             id(remote_learn_switch).publish_state(false);
  #             std::string log_output = "Sony: Data = 0x" + esphome::format_hex(x.data) + ", nbits = " + esphome::to_string(x.nbits);
  #             id(learned_command).publish_state(log_output.c_str());
  #         - delay: 80ms
  #         - light.turn_on: ir_status_light
  #         - delay: 500ms
  #         - light.turn_off: ir_status_light
  on_pronto:
    - if:
        condition:
          lambda: 'return id(remote_learn_switch).state;'
        then:
          - lambda: |-
              id(remote_learn_switch).publish_state(false);
              std::string log_output = "Pronto: Data = " + esphome::to_string(x.data);
              id(learned_command).publish_state(log_output.c_str());
          - delay: 80ms
          - light.turn_on: ir_status_light
          - delay: 500ms
          - light.turn_off: ir_status_light
3 Likes