That’s got it to compile OK
I might still be getting something basic wrong here though. Sorry to make you sharing something a pain.
I press the Learn Command button in HA, then press a button on a remote. The log shows Pronto data it’s received, but I see nothing happen in HA.
The Learned Command sensor’s there in HA, showing as Unknown and doesn’t change.
I noticed Pronto: Data = doesnt show anywhere in the log, so tried changing that to Pronto: data= (no space before =) that does…
Then I get this in the log:
Hmmm I think what’s going on here is that it’s too long for the text sensor and being rejected by HA…
So far I’ve been mostly using it with other protocols which are more compact, I’ll have a think how to handle that better unless you’ve got some ideas?
I don’t think this method I was using will work well for pronto data… If you’re using another protocol from the list which uses shorter data it will, but 9/10 you’re probably using pronto format
Looks like you’ll just have to use dump: all and follow the log output…
I was hoping to get your pronto approach working and then change things to use raw. Raw will probably end up even longer though.
Most/all of my remotes are detected as pronto, but then the data that’s logged seems pretty useless. At least I’ve not found how to use it.
Almost always ends up with Inconsistent data, not sending when I try to send it.
I haven’t been able to find why
After I capture a few (5-10) raw button presses, discard any obvious outliers, test sending any that are left and select the best responding, raw’s working spot on. Better than it was working while it was Tuya.
It’s a bit of a pain to do it for evey button, but the results are great so far.
This little thing’s got considrably better range/coverage than some of my original remotes.
I’ve got an aquarium light with a cheap IR remote that’s got to be close and pointed at the light just right for it to work. This little thing just has to be in the same room, can even be the opposite side of the fish tank with a load of wood cabinet in the way!
Looking at the raw, I found not having the inverted always made codes start with a minus. I gather that’s starting with a delay/off, so has to mean it should be inverted?
I can’t even get it to compile with inverted: true anywhere I can think to try it in either remote_transmitter or remote_transmitter.transmit_pronto
Maybe its only a thing for remote_transmitter.transmit_rc_switch_type_a?
If what I’m capturing doesnt start with -/minus, and then sends OK… That means I’ve got to have this the right way round (and there’s some other reason for my troubles with pronto codes) doesn’t it?
Yeah if what you’re receiving raw isn’t negative that you should already have it the right way round as you say. Have you tried playing with the tolerance when you’re decoding/sending pronto data? Looks like you’ve made it tighter than the default which is maybe affecting things?
I made it tighter hoping to improve how codes are recognised, but it didnt at all.
I tried setting it to a few petty random numbers but saw no difference
I’ve done some looking into the inconsistent data error and I think it happens when the pronto data you’re sending is too long and then gets truncated.
But this is kind of secondary to another thing that seems to be happening, which is that I think you’re getting a really long pronto code because the input signal is varying too much for the library to decode and separate the repeats from each other, which may be affected by that tolerance config option?
I’m thinking if you make the tolerance higher/wider, you might get shorter pronto codes
Edit: Reading tolerance docs and source I’m getting confused whether you want a higher or lower value in this case to be honest
Try moving the remote further away from your unit when you’re learning the codes, it might help to get less varied signals so the lib can see the repeats
This is with my Samsung TV remotes OK/Enter button
The pronto data doesn’t seem to change length at all, but I do get Samsung codes at 25%-100%.
The one I got with 25% and 50% (0xE0E016E9) works perfectly.
When I was recording button IR codes last night, I think I started with the remote from a cheap fan I’ve got, cranked down the tolerance and ended up setting it to capture raw so didn’t even look for ‘proper’ codes when I got to my TV remote.
Guess I’ll be doing a bunch of that again!
Thanks for sending me in the direction that lead to finding that
Great stuff, yeah it does look like 25% is best - you can see the signal is getting more false positives as the tolerance goes up and no perfect matches at 0. I understand that config too now at last
So if you wanna try the “learn” thing again, here’s it updated for samsung:
# Home Assistant controlled fake switch - to enable "learning mode"
switch:
- platform: template
name: Learn Command
id: remote_learn_switch
optimistic: true
# Home Assistant sensor to store remote command data
text_sensor:
- platform: template
name: Learned Command
id: learned_command
remote_receiver:
pin:
number: P7
inverted: true
mode:
# INPUT_PULLUP # Seems to do the same as seperate input & pullup
input: true
pullup: true
on_samsung:
- if:
condition:
lambda: 'return id(remote_learn_switch).state;'
then:
- lambda: |-
id(remote_learn_switch).publish_state(false);
std::string log_output = "Samsung: 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 all received pronto data
# on_pronto:
# - if:
# condition:
# # If Remote Learn switch is on
# lambda: 'return id(remote_learn_switch).state;'
# then:
# # - Turn learn switch off
# # - Build data string
# # - Publish data string to text sensor
# - 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());
# # Blink status LED
# - delay: 80ms
# - light.turn_on: ir_status_light
# - delay: 500ms
# - light.turn_off: ir_status_light
# # Using SONY protocol instead
# 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
With that, the shorter Samsung codes (like 0xE0E016E9) make it into HA:
They have a bunch of 0s added though
I guess it’d make sense to uncomment each block, and add more, for the common code standards. With the type of code ending up in HA, that should mean not having to go through the log…
- 
