I cannot find anything suspicious in your code.
What puzzles me is that there is no log entry whatsoever of the transmit commands.
My next step would be to add logging commands immediately before and after the transmit commands to see whether these make their way into the log.
Not sure if I understand your question and the quote from the specs correctly. But your transmitter contains a driver transistor so the current that is draws from the GPIO is definitely small. GPIO can handle it.
And again: The code has no way to detect, if something is connected to a GPIO output, or of it’s connected but broken, or of the GPIO itself is damaged. The log line for the transmission should appear in all these cases. That’s what puzzles me about your problem. Hence the proposal to add logging commands before and after, to see if the on_press triggers and runs through.
I have a rangehood that has an IR remote. I successfully copied all the buttons on the remote but wonder whether there are more commands the rangehood can respond to, for example, turn on or off instead of power toggle. Or a specific fan speed instead of using up and down. Is there any practical way to discover additional working codes?
This is an interesting question. The remote that I describe in the original guide also only has an on/off toggle. And I indeed tried to find dedicated on and off codes. But the number of possible combinations is to high and a web search also yielded no result. So I gave up.
@Jpsy I wonder whether it is possible, or rather easy, to cycle through all possible hex combination for the 4chr command. I need to figure out if esphome can do it… if it can, then I can watch the log while it does so to catch any undocumented commands.
IMHO the problem is not cycling through all commands. This could be easily done, i.e. in Node RED in HA. The difficult part is to automatically assess the outcome of each command. You could do this by attaching sensors to the controlled object that can detect some basic states. But the task becomes even more involved as some commands may change the results of following commands down the test chain. I.e. the power toggle command will ruin all following tests if it switches the target off. So you have to come up with a clever design of your command sequence and you might also have to feed back you sensor results into that sequence.
@Jpsy The rangehood vent only has 4 fan speeds, a light on/off and a power on/off. Other functions like clock are of no use. I am not sure how many commands would need to be sent, but I don’t expect there to be so many I can’t stand in front of the rangehood to see if it reacts. It also beeps very loudly when a command works.
Yes sure. With the .on_pronto event automation of the remote_receiver you can catch any incoming data and react to it. If you cannot tell the on / off state from the data itself, but only from one or two returns, then I would do something like this:
In your toggle on/off button action reset a global counter variable to zero, transmit the IR sequence, and then start a delay of 2 seconds.
In receiver’s on_pronto increment that counter variable
After the delay check whether counter is 1 or 2 and set a binary template sensor to off or on accordingly.
yes, I’m not able to distinguish the off action from the data returned. I think using the 2 returns are only option. Can you pls share an example how to increment the variable with on_pronto?
Here is my current code:
