Closed ptoffy closed 2 months ago
Does the AC not respond to these commands? It is quite common that the library don't decode every message, it is quite restrictive in what it accepts because it tries to decode many protocols, but actual units does decoding differently.
Note that you do need a transistor to drive the LED, I assume this is included in your driver board, but if it isn't I wouldn't expect that you get any working signal.
Does the AC not respond to these commands?
No it does not, although I am somewhat far away from the AC, so the next thing I would have tried after getting the decoding to work would have been to get closer (the AC remote works though)
It is quite common that the library don't decode every message
Not even the ones sent by it?
Actually I don't have a transistor, but since the data gets sent and sometimes decoded correctly I assumed I was fine. I've also been using it for a while now and nothing's happened (not even overheating) so I should be fine? I might add one just in case
Actually, I've just tried and by moving closer it does work! I'm not sure why it would turn it off when using ac.on()
, and on when using ac.off()
but that's probably an error in my code so I'll figure it out. Thanks for looking into this
Yes, you will need the transistor!
Does the AC not respond to these commands?
No it does not, although I am somewhat far away from the AC, so the next thing I would have tried after getting the decoding to work would have been to get closer (the AC remote works though)
It is quite common that the library don't decode every message
Not even the ones sent by it?
Actually I don't have a transistor, but since the data gets sent and sometimes decoded correctly I assumed I was fine. I've also been using it for a while now and nothing's happened (not even overheating) so I should be fine? I might add one just in case
This isn't an issue of overheating. First of the IR LED won't get enough power to being registered in most cases. And then there is the issue of burning up the gate related to that pin, something that happens over time. But is the LED connected directly, or is it on a board, you mention data pin, if there is no transistor on that board, the vcc pin is probably not connected to anything at all.
Don't expect the same device to get correct readings while sending, timings will just be quite of.
@NiKiZe Sorry I misread you for a resistor (if you couldn't tell, I'm quite new at this!). But no I don't have a transistor. I'm using a KY-005 module if that helps, of which the VCC is pinned to the 5V of the board and the data pin to a GPIO(14) port (all through a breadboard). Although it seems to be working fine now, do you think I still might need a transistor?
So, yes, as I have seen it, vcc on that board isn't connected to anything. I'm surprised you get any reaction at all, but shure, short distance and perfect conditions might work, at least for a while until it suddenly doesn't.
The KY-005 probably has a transistor on it, but I can't tell for sure. As it has three inputs (VCC, GND, & [S]ignal) When driving the IR LED via just the GPIO pin, there is not enough current to power the IR LED properly. Hence why a transistor needs to be "switched" on/off a much higher current supply than the GPIO can deliver. i.e. Connecting it directly to VCC & GND. If you're getting a signal to work at more than 1 metre, then it will be using a transistor.
In short, see https://github.com/crankyoldgit/IRremoteESP8266/wiki#ir-sending
Vcc is not connected to anything, unless you can verify there is a transistor on the board. (I can not find a picture showing that anywhere)
https://www.electrothinks.com/2023/02/ky-005-infrared-transmitter-module.html?m=1#google_vignette
You're actually right, removing the VCC connection doesn't change anything. So is getting a transistor on the signal pin enough?
As already mentioned , see https://github.com/crankyoldgit/IRremoteESP8266/wiki#ir-sending We can't really say more than we already have, as we focus on the software side, and not the electronics, there is better places for that (and more qualified), hope you understand.
Yes thank you!
Version/revision of the library used
2.8.6
Describe the bug
IRMitsubishiHeavy152Ac
sends inconsistent signalsTo Reproduce
It probably doesn't matter but, for context, I have an
AsyncWebServer
(from theESPAsyncWebServer
lib) running which listens for requests to send commands to the AC. For sending signals to the (Mitsubishi SRK25ZS) AC I:IRMitsubishiHeavy152Ac
instance connected to my IR led;UKNOWN
instead ofMITSUBISHI_HEAVY_152
. I tried sending commands from the AC's remote and they're fine every time so my guess is the decoding is fine, the sending isn't. I've also tried with a couple different IR LEDs but nothing changesExample code used
Most of the important stuff is above. I also used
to narrow down the messages
Expected behaviour
The messages are correct (and therefore get decoded correctly) each time, instead of just sporadically. I'd also love for the AC to actually do something when the messages are correct but that's another beast to tame
Output of raw data from [IRrecvDumpV2.ino]
Example of a correctly decoded/sent message:
and right after:
What brand/model IR demodulator are you using?
CHQ1838 (I guess it's quite similar to the VS1838B so it might cause problems too?)
Circuit diagram and hardware used (if applicable)
You can't see it here because Wokwi doesn't have IR transmitters, but GPIO13 is connected to the data pin of the IR led
Thanks for the great work on the library!