-
Notifications
You must be signed in to change notification settings - Fork 146
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IVT and Sharp may actually have the same "power on" nibble #149
Comments
Hi André
I'm sorry not being able to help you. The update to the IVT that was made,
for power button that was a different byte compared to Sharp. have been
working flawless for me for my IVT.
I don't any longer live in the house that has the IVT installed, so I don't
use this anymore
BR
Brian
…On Wed, May 17, 2023 at 1:04 AM André Brandão ***@***.***> wrote:
I have an old Sharp AC unit, which uses the controller CRMC-A528JBEZ. This
unit, beeps twice when turned on, and once when doing any other operation,
such as changing temperature, swing, and turning it off - I swear this is
relevant for the issue.
While trying to use this library to control my unit, I quickly found out,
that similarly to the issue #26
<#26>, my unit would
only turn on when byte 5 was 0x11. Changing the class to IVTHeatpumpIR
meant I was now able to turn my AC, however, now my AC beeps twice when
changing any setting through the Arduino. Normally when changing the
temperature through the original controller, I only get one beep. This
prompted me to "read" what my controller was sending.
The following output is the result of turning on the AC at 18ºC,
increasing it to 32ºC and turning it off.
00: 0xAA 0x5A 0xCF 0x10 0x01 0x11 0x22 0x00 0x08 0x80 0x00 0xF0 0x21
01: Decode failed
02: 0xAA 0x5A 0xCF 0x10 0x03 0x31 0x22 0x00 0x08 0x80 0x00 0xF0 0x21
03: 0xAA 0x5A 0xCF 0x10 0x04 0x31 0x22 0x00 0x08 0x80 0x00 0xF0 0x51
04: 0xAA 0x5A 0xCF 0x10 0x05 0x31 0x22 0x00 0x08 0x80 0x00 0xF0 0x41
05: 0xAA 0x5A 0xCF 0x10 0x06 0x31 0x22 0x00 0x08 0x80 0x00 0xF0 0x71
06: 0xAA 0x5A 0xCF 0x10 0x07 0x31 0x22 0x00 0x08 0x80 0x00 0xF0 0x61
07: 0xAA 0x5A 0xCF 0x10 0x08 0x31 0x22 0x00 0x08 0x80 0x00 0xF0 0x91
08: 0xAA 0x5A 0xCF 0x10 0x09 0x31 0x22 0x00 0x08 0x80 0x00 0xF0 0x81
09: 0xAA 0x5A 0xCF 0x10 0x0A 0x31 0x22 0x00 0x08 0x80 0x00 0xF0 0xB1
10: 0xAA 0x5A 0xCF 0x10 0x0B 0x31 0x22 0x00 0x08 0x80 0x00 0xF0 0xA1
11: 0xAA 0x5A 0xCF 0x10 0x0C 0x31 0x22 0x00 0x08 0x80 0x00 0xF0 0xD1
12: 0xAA 0x5A 0xCF 0x10 0x0D 0x31 0x22 0x00 0x08 0x80 0x00 0xF0 0xC1
13: 0xAA 0x5A 0xCF 0x10 0x0E 0x31 0x22 0x00 0x08 0x80 0x00 0xF0 0xF1
14: 0xAA 0x5A 0xCF 0x10 0x0F 0x31 0x22 0x00 0x08 0x80 0x00 0xF0 0xE1
15: 0xAA 0x5A 0xCF 0x10 0x0F 0x31 0x22 0x00 0x08 0x80 0x00 0xF0 0xE1
16: 0xAA 0x5A 0xCF 0x10 0x0F 0x21 0x22 0x00 0x08 0x80 0x00 0xF0 0xF1
As we can see the 5th byte, responsible for powering on the device is 0x11
on the first packet, and on the following 0x31.
I have also figured out that pressing the "FULL POWER" button on the
controller changes bytes 05 and 10.
34: 0xAA 0x5A 0xCF 0x10 0x01 0x11 0x22 0x00 0x08 0x80 0x00 0xF0 0x21
// Turn on full power
35: 0xAA 0x5A 0xCF 0x10 0x01 0x61 0x22 0x00 0x08 0x80 0x01 0xF0 0x41
// Turn off full power
36: 0xAA 0x5A 0xCF 0x10 0x01 0x71 0x22 0x00 0x08 0x80 0x01 0xF0 0x51
// Lower temperature (from 18 to 18)
37: 0xAA 0x5A 0xCF 0x10 0x01 0x31 0x22 0x00 0x08 0x80 0x00 0xF0 0x01
39: 0xAA 0x5A 0xCF 0x10 0x02 0x31 0x22 0x00 0x08 0x80 0x00 0xF0 0x31
40: 0xAA 0x5A 0xCF 0x10 0x03 0x31 0x22 0x00 0x08 0x80 0x00 0xF0 0x21
// Power off
41: 0xAA 0x5A 0xCF 0x10 0x03 0x21 0x22 0x00 0x08 0x80 0x00 0xF0 0x31
Additionally, I can control swing by setting byte 8 to 0x0F, however it
doesn't appear to have a setting to indicate on/off, as repeatedly pressing
the button sends the same packet:
19: 0xAA 0x5A 0xCF 0x10 0x05 0x31 0x22 0x00 0x0F 0x80 0x00 0xF0 0x31
20: 0xAA 0x5A 0xCF 0x10 0x05 0x31 0x22 0x00 0x0F 0x80 0x00 0xF0 0x31
21: 0xAA 0x5A 0xCF 0x10 0x05 0x31 0x22 0x00 0x0F 0x80 0x00 0xF0 0x31
22: 0xAA 0x5A 0xCF 0x10 0x05 0x31 0x22 0x00 0x0F 0x80 0x00 0xF0 0x31
Have you ever verified this behaviour on your unit? I could make a PR to
reflect this behaviour, however I am afraid of breaking the existing
implementations in case there are units that only respond to "0x31".
CC @bjacobse <https://github.com/bjacobse> since he was the one that
first noticed the difference between 0x31 and 0x11
—
Reply to this email directly, view it on GitHub
<#149>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA6T4IU3H4YXJWXL2FXXY5LXGQBYVANCNFSM6AAAAAAYEJHXMA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have an old Sharp AC unit, which uses the controller CRMC-A528JBEZ. This unit, beeps twice when turned on, and once when doing any other operation, such as changing temperature, swing, and turning it off - I swear this is relevant for the issue.
While trying to use this library to control my unit, I quickly found out, that similarly to the issue #26, my unit would only turn on when byte 5 was 0x11. Changing the class to
IVTHeatpumpIR
meant I was now able to turn my AC, however, now my AC beeps twice when changing any setting through the Arduino. Normally when changing the temperature through the original controller, I only get one beep. This prompted me to "read" what my controller was sending.The following output is the result of turning on the AC at 18ºC, increasing it to 32ºC and turning it off.
As we can see the 5th byte, responsible for powering on the device is 0x11 on the first packet, and on the following 0x31.
I have also figured out that pressing the "FULL POWER" button on the controller changes bytes 05 and 10.
Additionally, I can control swing by setting byte 8 to 0x0F, however it doesn't appear to have a setting to indicate on/off, as repeatedly pressing the button sends the same packet:
Have you ever verified this behaviour on your unit? I could make a PR to reflect this behaviour, however I am afraid of breaking the existing implementations in case there are units that only respond to "0x31".
CC @bjacobse since he was the one that first noticed the difference between 0x31 and 0x11
The text was updated successfully, but these errors were encountered: