SharpAc: Allow position control of SwingV

[crankyoldgit]

• Add the ability to set swingV positions via setSwingV()
  • e.g. Coanda setting.
  • Several other undocumented positions discovered via experimentation.
  • May not work on all models.
• Update & add unit tests accordingly.

Fixes #1590

[menexttoday]

Forgive the layout below this is the first time I reply. Still trying to figure it all out.

For some reason when invoking ac.setSwingV(kSharpAcSwingVCoanda); the signal sent is 0b100 to the AC instead of 0b110.

In ir_Sharp.cpp line 558 may be changing the value. The OEM remote just sends out 0x0E or 0b110. The AC responds accordingly depending to the mode. I don't think this code is required.
// Only allowed in Heat mode. if (getMode() != kSharpAcHeat) { setSwingV(kSharpAcSwingVLow); // Use the next lowest setting. return; } // FALLTHRU

I removed the above lines and the code behaves as the original remote. I tried pushing the change I am not sure if it was sent properly.

[crankyoldgit]

For some reason when invoking ac.setSwingV(kSharpAcSwingVCoanda); the signal sent is 0b100 to the AC instead of 0b110.

I decided to implement it as kSharpAcSwingVCoanda = kSharpAcSwingVLowest and only available in Heat mode, and use the "feature" that kSharpAcSwingVHigh (0b001 [0b1001]) has the same effect as Cool's Coanda.
This is because there are interfaces to the library (via the IRac class) which don't have the concept of a "Coanda" mode. e.g. they choose a fixed-ish position, like highest, high, middle, low, lowest etc. It's unintuitive for someone to set vanes to the lowest position to get the high/highest one, if you catch my drift.

In short, in Cool mode, if you desire the Highest (aka Coanda) fan position, you should specify: ac.setSwingV(kSharpAcSwingVHigh);

Yes, it won't generate the exact same code as the remote, but in theory it should allow us to have a true high setting for all modes, and avoid people having to know to set "lowest" for "highest" in Sharp.

I can/could change the code as you described to allow creating the exact same state[] code but I fear it's going to lead to feedback/questions/issues saying "I found a bug, when setting my sharp a/c to Lowest pos, it went to the Highest. Please fix!"

An alternative is to add an optional extra parameter to setSwingV() that allows someone to force the setting, so the lib can create the exact same state[] code. Hmmm.

I tried pushing the change I am not sure if it was sent properly.

It didn't come through that I can see, but thanks for trying. ;-)

[crankyoldgit]

In the latest commit to the branch, I've added the ability to force Coanda mode in cool, via:

ac.setSwingV(kSharpAcSwingVCoanda, true);  // Force Coanda setting regardless of operating mode.

[menexttoday]

In general I agree with the setting you describe but someone who has the remote may be confused since it is set as a separate feature on the remote. The way I see it is; 0x09 (0b001) = high 0x0B (0b011) = Mid 0x0C (0b100) = low 0x0E (0b110) = Lowest only available in heating. This is a separate button on the remote which activates COANDA. In cooling it’s the same as 0x09 Not sure what Sharp was thinking with 0x0A and 0x0D. I find it confusing. I know that this is how the heat pump interprets the codes since I see that they are transmitted properly. Actually the remote only has 2 buttons for Swing. One to toggle SwingV and the other that toggles COANDA. That’s probably why it feels messy. I created a web remote in HTML and tried it out. The only way it feels right to the user is to label 0x0E Coanda and not give it a position. Just have 3 positions, High(0x09), Mid(0x0B) and Low(0x0C). With 2 toggles, SwingV and CONADA (to mimic the remote for people who own the remote). It sounds as if we can implement this solution either way so whatever you decide. It will be confusing to someone. Either interface developers or IRremote maintainers. If you leave the code as is I just have to add a condition to check the mode when 0x0E is invoked. I can’t present it to the user as lowest. Too confusing. I need to get familiar with Git and Github.

…

On Sep 2, 2021, at 7:49 PM, David Conran ***@***.***> wrote: For some reason when invoking ac.setSwingV(kSharpAcSwingVCoanda); the signal sent is 0b100 to the AC instead of 0b110. I decided to implement it as kSharpAcSwingVCoanda = kSharpAcSwingVLowest and only available in Heat mode, and use the "feature" that kSharpAcSwingVHigh (0b001 [0b1001]) has the same effect as Cool's Coanda. This is because there are interfaces to the library (via the IRac class) which don't have the concept of a "Coanda" mode. e.g. they choose a fixed-ish position, like highest, high, middle, low, lowest etc. It's unintuitive for someone to set vanes to the lowest position to get the high/highest one, if you catch my drift. In short, in Cool mode, if you desire the Highest (aka Coanda) fan position, you should specify: ac.setSwingV(kSharpAcSwingVHigh); Yes, it won't generate the exact same code as the remote, but in theory it should allow us to have a true high setting for all modes, and avoid people having to know to set "lowest" for "highest" in Sharp. I can/could change the code as you described to allow creating the exact same state[] code but I fear it's going to lead to feedback/questions/issues saying "I found a bug, when setting my sharp a/c to Lowest pos, it went to the Highest. Please fix!" An alternative is to add an optional extra parameter to setSwingV() that allows someone to force the setting, so the lib can create the exact same state[] code. Hmmm. I tried pushing the change I am not sure if it was sent properly. It didn't come through that I can see, but thanks for trying. ;-) — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[crankyoldgit]

Not sure what Sharp was thinking

Alas, I don't think they think about people a) reverse engineering their protocols, and b) Trying to control them in a universal manor. ;-P We do the best we can do.

Accessing things directly via the IRSharpAc class methods etc as you are doing gives you the greatest control and functionality. Also, it something you can "program around" if/as you need to.

I'm going to leave the "normal"/default behaviour the way it is to allow it to work with/for people who are using the generic IRac class methods (e.g. IRMQTTServer, Tasmota, EasyESP, etc) and it does as "expected" from that perspective.

[Q] What happens if you send two Auto/0b111/0b1111 messages back to back (after a suitable gap of course). Is it really a "Toggle" or is it a "make the device swing the vane back and forth" message?
i.e. Does sending it twice result in it starting to swing, then stopping. Or will it continue to swing after the second message?
TL;DR: Is it really a "Start swinging" message, or a "If you were swinging, stop. If you were stopped, swing"?

I ask because the "generic" IRac class will keep sending the Auto swing bits in each message. Do I need to tell it to send Off after the initial Auto code?

[menexttoday]

The 0b111/0b1111 toggles/starts/stops the swing. The unit starts in the OFF (No swing). Sending 0b111 starts it swinging. Next 0b111 stops the swing (The baffle stops where it is). Next 0b111 starts the swing again. It toggles on - off - on - off … With each press it changes from On to Off or Vice versa. The behaviour is more like this with different key presses represented on the left; Unit is turned on (No swing) Last known toggle swing OFF position with 0b111 0b111 - Unit starts swinging from current position 0b111 - Unit stops swinging (sets position memory, “First") 0b111 - Unit starts swinging from current position 0b111 - Unit stops swinging (sets position memory, “Second") 0b001 - Unit flips baffle and points air to highest position (swing is OFF) (kSharpAcSwingVHigh) 0b111 - Unit flips baffle, Unit starts swinging 0b111 - Unit stops swinging (sets position memory, “Third") 0b011 - Unit moves baffle to Mid (kSharpAcSwingVMid) Stops swing 0b111 - Unit starts swinging 0b100 - Unit moves baffle to Low (kSharpAcSwingVLow) Stops swing 0b010 - Unit moves baffle to last memory “Third” position. (0b101 does the same as 0b010) 0b111 - Unit starts swinging 0b111 - Unit stops swinging (sets position memory, “Forth") 0b100 - Unit moves baffle to Low (kSharpAcSwingVLow) Stops swing 0b010 - Unit moves baffle to last memory “Forth” position. (0b101 does the same as 0b010) 0b111 - Unit starts swinging If the baffle is moving 0b111 stops it and remembers the position on power ON or 0b010/0b101. If the baffle is stationary 0b111 starts the swing. I wonder how confusing it would be to users if I set a button on the remote named "last known stop position" and use 0b010 or 0b101 to bring the flap back to this position. It remembers this even after the unit is turned off. The unit starts at this position. It took some time to figure this out. Then users will have the following options; High Mid Low Coanda Swing / Stop swing (save position) Last swing saved postion I’m glad you set kSharpAcSwingVOff1 and kSharpAcSwingVOff2. It gives me a chance to see what is different between the 2. Maybe we can label them with a more descriptive term.

…

On Sep 3, 2021, at 12:10 AM, David Conran ***@***.***> wrote: Not sure what Sharp was thinking Alas, I don't think they think about people a) reverse engineering their protocols, and b) Trying to control them in a universal manor. ;-P We do the best we can do. Accessing things directly via the IRSharpAc class methods etc as you are doing gives you the greatest control and functionality. Also, it something you can "program around" if/as you need to. I'm going to leave the "normal"/default behaviour the way it is to allow it to work with/for people who are using the generic IRac class methods (e.g. IRMQTTServer, Tasmota, EasyESP, etc) and it does as "expected" from that perspective. [Q] What happens if you send two Auto/0b111/0b1111 messages back to back (after a suitable gap of course). Is it really a "Toggle" or is it a "make the device swing the vane back and forth" message? i.e. Does sending it twice result in it starting to swing, then stopping. Or will it continue to swing after the second message? TL;DR: Is it really a "Start swinging" message, or a "If you were swinging, stop. If you were stopped, swing"? I ask because the "generic" IRac class will keep sending the Auto swing bits in each message. Do I need to tell it to send Off after the initial Auto code? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[crankyoldgit]

@menexttoday Please take another look/test etc of the branch. Hopefully this version is better.

[menexttoday]

It took me longer to figure out Gihub and how to get the code in my system in the right folder than to make the changes to my code and run the tests. It seems to work great. I ran through all the codes in dry, cooI and heat. Will run more tests tomorrow when I have more time in case I missed one in one of the settings.

…

On Sep 3, 2021, at 10:08 PM, David Conran ***@***.***> wrote: @menexttoday Please take another look/test etc of the branch. Hopefully this version is better. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[crankyoldgit]

It took me longer to figure out Gihub and how to get the code in my system in the right folder than to make the changes to my code and run the tests. It seems to work great. I ran through all the codes in dry, cooI and heat. Will run more tests tomorrow when I have more time in case I missed one in one of the settings.
…
On Sep 3, 2021, at 10:08 PM, David Conran @.***> wrote: @menexttoday Please take another look/test etc of the branch. Hopefully this version is better. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

Okay. I'll await your response in a day or so.

[crankyoldgit]

@NiKiZe Can you please cast another eye over this. It's changed a bit since your previous review.

[crankyoldgit]

FYI, the changes mentioned above have now been included in the new v2.8.0 release of the library.