Trying to get m5 ir module to work with m5 atom and esphome - is it dodgy?

Where did you get pin 36 from? (I cannot find the specs, but found some sample code which put it on GPIO32) https://github.com/esikora/ESP32App_Led_IR/blob/4b0d68e58b5a9edd74a22101bfd32ee2b2bcce0e/ESP32App_Led_IR.ino#L37

Also

Seems to show the grove pins are 26 and 32.

This is the “docs” page referenced from the ir module product page

https://docs.m5stack.com/en/unit/ir

it mentions GPIO36 - Receiver pin. I’ve also seen a few blogs that indicate GPIO 36… one guy actually talked about GPIO32 in the text of his blog, but in the code he had GPIO36…

however I have tried GPIO 32 - it’s been a few days, will just try again.

Oh… so frustrating. So it works. I changed to GPIO32, and on boot I get the following warning, however it works:

[11:21:10][W][remote_receiver.esp32:058]: Remote Receiver Signal starts with a HIGH value. Usually this means you have to invert the signal using 'inverted: True' in the pin schema!

well thanks for your help @nickrout - apologies for wasting your time, but thanks for resolving the issue

and inverted it gives even more meaningful remote codes (not just pronto)… always the way.

1 Like

I get more confused the more I read from M5. Looks like there is more than one type of Grove port specified Grove a vs grove b | M5Stack Community

Looks like an A Port has GPIO 32 and 33

Looks like the port on an Atom Lite has GPIO 26 and 32

Or I could just be getting confused. I think the moral is that not all M5 boards use the same pins on the grove port.

Yes, the controller devices from M5Stack come in several different “families”. I haven’t worked with M5Stack’s “Stick”, “Core”, or “Stamp” families, so I don’t know how they use Grove connectors on those units. --from pic above, it looks like Core series uses “Port A” conventions (for I2C devices).

I do have several different models of the M5Stack “Atom” series (Atom Lite, AtomU, Atom Echo, Atom Speaker). I’ve found all of the Atom series use the same pinouts, in what would be considered “Type B” (generic IO).

As noted in the above link, M5Stack designates “Port A” usage for I2C, “Port B” for generic GPIO digital or analog IO, and “Port C” for UART usage. It really just depends on how you’ve programmed GPIO pin “X” --and whether pin “X” is supported by ESP32 for desired usage.

I’ve had success with routing different GPIO signals into the two Grove signal pins, using Grove-to-Dupont cables, just being careful to honor the ESP32 usages of those 2 pins. Or of course just connect directly to Dupont connectors on the Atom.

Good reference on Grove connector system is at:
Grove System - Seeed Wiki
They describe the different types of usage, but not with same “Port x” labels that M5Stack uses (as mentioned in the above link).

I really like the M5Stack devices, because they provide enclosed cases that can just be plugged together. I could really see it for educational purposes, for people to do programming without getting caught up in hardware issues. Or for those of us not mechanically inclined, to avoid soldering and case building and such. It’s just unfortunate that they’ve broken some of the simplicity with this Type A/B/C stuff on the connectors. Oh well.

1 Like

I use exactly the same hardware setup: @farnsy Did it work out in the end for you?

I have some issues regarding reliability reported here - maybe you can advise?

Tbh @Tobster77 I got it working after the advice above, but haven’t come back to actually implementing it. For my main use I bought a broadlink, but wanted to use this for a kitchen TV off/On, but the pain hasn’t got to the point of motivating me to implement it.

Will let you know if I come back to it and have success, cos I’d probably be after 3m range or similar.

@farnsy: If you could send me the RX/TX pins you used, I would be very grateful, see my question here. Thanks!

Looking at the other thread, and comparing to my config that I last had working, they are identical.

That’s weird. The definition printed on the IR unit is vice versa. Or am I wrong?

Yes, I believe that’s what I established with some help a bit further up this thread.

Thanks. Note, I only get extremely low working distances (something like 10cm to 1m) to get reliable IR transmissions. Don’t know why the transmit power of the M5 IR sender is so extremely weak…

I finally dug it out again from the pile of stuff on my desk, checked the configuration, and remembered I had it configured to turn on an LED strip I have in my study. I plugged it in, put the IR transmitter as far from the led strip remote receiver as I could, and could turn it on. This was a distance of around 3.2 metres.

The built-in IR port in the Atom also works to approx 3.5 meters too?

To work out what PINs you need to map on the Atom Lite, you just need to look at them on the back (Reference picture that @nickrout posted works too) , and trace them (color wise) to the unit. It’s always going to be G26 or G32 for the Atom Lite.
The IR Remote then has In on the white cable and Out on the yellow.

So In (to the IR) is G32
Out (from the IR) is G26

Hope that helps :slight_smile:

@Chilling_Silence: Fully agreed! This is what logically makes sense. However, I had no chance to get the device working with this approach: I had to flip the role of the pins. This is the code that works ( with extremely low range):

remote_receiver:
  pin:
    number: 32
    inverted: true
  dump: raw

remote_transmitter:
  pin: 26 
  carrier_duty_percent: 50%

I am a bit lost.

The built-in IR transmitter (I think on pin 12) works for only 50cm, but this has already been discussed on the web.

esphome:
  name: "espatom-ir-blaster-1"

esp32:
  board: m5stack-core-esp32
  framework:
    type: arduino

# Enable logging
logger:

# Enable Home Assistant API
api:

ota:


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

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Esphome-Web-Bfae70"
    password: "Kl4VccLdUcAF"

captive_portal:

remote_receiver:
  pin:
    number: GPIO32
    inverted: true
  dump: all


remote_transmitter:
  pin: GPIO26
  carrier_duty_percent: 50%

climate:
  - platform: heatpumpir       # adjust to match your AC unit!
    protocol: panasonic_dke
    name: "Bedroom AC"
    horizontal_default: mleft
    vertical_default: up
    max_temperature: 25
    min_temperature: 16

It wont “dump” stuff unless you shoot an IR remote at it to collect the data.

This works with the m5atom lite and the ir module. It puts a templated AC device into HA. The only thing that sucks/i havent figured out is how to add an external temp/humidity sensor to the AC template.

1 Like

And you were correct. I use the Atom Lite with the Tail485 to control my pool chlorinator via RS485+Modbus. At first I was a bit lost with the tx/rx pinout, then I checked the Tail485 docs: m5-docs

You can see that on the top colored row, they show the pinout of the Atom to which you plug the Tail485, and the yellow pin (G26) is TX. The white (G32) is RX.

If you scroll the doc page, you’ll also find the Pin map, that confirms the interpretation:

I use it with Tasmota, and have the GPIO pins configured like this:

image

This is the Atom coupled with the Tail485:

Hope it helps.

I’ve been trying to get the internal IR TX working on various M5 Atoms (Lite, Echo, S3, S3-Lite, Matrix).

To collect codes I purchased some Everlight IRM-3638T receivers and wired them as per the schematic on m5-docs using one of the underside GPIO pins on a breadboard.

As discussed, the receiver has to be inverted in the YAML.

However, while I can do raw dumps from the receiver and then see them again when used with the transmitter at close range, I’ve not yet got any of my TV/hifi equipment to respond which is annoying.

Note that according to the Atom Lite schematic at m5-docs, the IR LED is driven directly by the GPIO pin through a 22Ω resistor whereas with the Grove-connected IR module, the LED is driven via a 150Ω resistor from the 5V VCC, switched by an NPN transistor.

All things being equal, this means the module puts about 5V/150Ω = 33mA through the LED and the Atom Lite would be able to put 3.3V/22Ω = 150mA through. However, the drive capability of the ESP32 GPIOs is much lower than this and defaults to 20mA.

If you have managed to get it working at short range, you could try upping the drive strength to see if that improves the range above 50cm.

remote_transmitter:
  carrier_duty_percent: 50%
  pin:
    number: 12
    ignore_strapping_warning: true
    drive_strength: 40mA
    mode:
      output: true

(This won’t make any difference if using the Grove-attached module of course as all you’re doing is switching the transistor on and off with the GPIO and the current is determined by the 150Ω resistor alone.)