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

ESPHome
#1

I have an m5 atom lite and an m5 infrared emitter & receiver (as below)

I’ve configured this using the details found in esphome doco, and setting the gpio pin as per the m5 docs.


remote_receiver:
  pin: 
    number: GPIO36
#    inverted: true
  dump: all

however nothing gets dumped.

I’ve tried:

  • using a different atom
  • using a different cable between the atom grove connector and the ir module
  • plugging a different sensor module into this atom to prove that the grove connector works
  • trying different GPIO settings, invert = true etc.
  • using multiple different remotes pointed at the receiver
  • configuring the i2c node for the grove bus to scan, however this caused errors to be logged

and haven’t been able to get anything reliably logged. At one stage, using a completely different GPIO (but something I saw on a forum) I got 1 or 2 IR received messages logged, but I assume given the nature of the codes, and the fact that it wasn’t actually configured correctly that these were just some kind of noise.

I’m wondering if I’m just missing something really simple, or whether I’ve got a dodgy IR emitter/receive unit and need to go back to m5/order another.

Any tips/advice welcome!

#2

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

#3

Also

image
image800×800 66.9 KB

Seems to show the grove pins are 26 and 32.

#4

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.

#5

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

#6

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

1 Like
#7

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

image
image800×800 107 KB

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.

#8

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.

#9

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?

#10

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.

#11

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

Wiring of M5Stack Mini Infrared Emitter & Receiver Unit and Atom Lite
#12

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

#13

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

#14

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

#15

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…

#16

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.

#17

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

image
image1276×988 80.4 KB

Hope that helps :slight_smile:

#18

@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.

#19 
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.