Support for Fujitsu Remotes AR-RAH2U and AR-REG1U

[PostLogical]

Version/revision of the library used

v2.8.2

Describe the bug

Please support the Fujitsu Remotes: AR-RAH2U and AR-REG1U.
Both remotes AR-RAH2U and AR-REG1U are supported in their basic 128 bit functions already (they are recognized as Model 1 - AR-RAH2E). The issues are just with 56 bit commands and the Min Heat function.
56 Bit commands work, but are not all part of Model 1 (I may be missing some aspects of how this should work, so please educate me as necessary), and they all have the effect of setting all other settings like Temp, Fan, etc to 16C, Auto, etc (for Off, this does not seem to matter, but the others are an issue). For instance, on the AR-REG1U there is a Powerful button, and when I use the Remote to hit Powerful, it is interpreted as a Model 3 command with default lowest settings (Model: 3 (ARREB1E), Id: 0, Power: On, Mode: 0 (Auto), Temp: 16C, Fan: 0 (Auto), Clean: Off, Filter: Off, Swing: 0 (Off), Command: Powerful, Outside Quiet: Off, Timer: Off). As a result, my Home Assistant thinks the heat pump is set to 16C, Auto, etc. rather than whatever it is actually set to.
Also, both these remotes have a Min Heat button that registers as a Model 5 command for Clean with the rest of the settings to whatever was already in there.

To Reproduce

I set up Tasmota_IR-flashed IR blasters (Uniplay IR Blaster made by Tuya and sold on Amazon so it is old stock that still has ESP8266) for my Fujistu heat pumps. Carefully testing all of the possible settings, the Tasmota recognized all the regular 128 bit commands as Model 1, and issuing those commands almost certainly works (there is no way of checking the heat pump for what it is doing, so used crude checks like setting the heat really low and then really high to see if it got warmer, which it did, and switching between modes to see if it started cooling instead of heating).

When entering 56 bit commands from the OEM remote, the results were mixed. So I set up a basic receiver circuit using a Wemos D1 Mini, an IR Receiver module from KOOBOOK (https://www.amazon.com/dp/B07S66T3WT?psc=1&ref=ppx_yo2_dt_b_product_details), and IRRecvDumpV2 from the codebase V2.8.2. I copied the pertinent results in a GSheet. I included the timer functions, but those are probably all working as designed for Model 1 (the output from Tasmota was not right or helpful, but that's not something you can fix for me I assume – I'll keep working to see if I'm doing something wrong there or how to fix it, but I welcome any tips as the Tasmota results currently don't change anything in the IRhvac results).

Here are photos of the remotes: https://imgur.com/a/c50W72l
The AR-REG1U remotes are controlling ASU9RLF1 indoor units connected to an AOU36RLXFZH outdoor unit.
One AR-RAH2U remote is controlling an ASU18RLF indoor unit connected to the same outdoor unit.
The other is controlling an ASU24RLF indoor unit connected to an AOU24RLXFWH outdoor unit.

Example code used

Used IRRecvDumpV2 to further analyze the differing commands after using Tasmota_IR to analyze the basic 128 bit commands.

Expected behaviour

The 56 bit commands should not reset any of the other settings that they aren't touching. The Min Heat command should set Min Heat instead of calling Model 5's Clean function. It should also probably show temp as 10C/50F instead of inheriting the last normal temp.

Output of raw data from IRrecvDumpV2.ino

Google Sheet FUJITSU_AC AR-RAH2U and AR-REG1U Remote Codes

I have followed the steps in the Troubleshooting Guide & read the FAQ

Yes

Other useful information

I appreciate any help you can offer, whether that is refiguring code, telling me what I'm doing wrong/how to do it right, or helping me to fix this myself. I can try to code this myself and submit a PR, but I don't yet understand how the Fujitsu differentiating code fully works. Happy to provide more details or do other work as is helpful.

[crankyoldgit]

The Min Heat command should set Min Heat instead of calling Model 5's Clean function.

Alas, it is the same thing from the actual messages point of view.
See:

IRremoteESP8266/src/ir_Fujitsu.h

Line 83 in 434582a

uint64_t Clean :1; // Also 10C Heat in ARREW4E.

IRremoteESP8266/src/ir_Fujitsu.h

Lines 217 to 218 in 434582a

	void set10CHeat(const bool on);
	bool get10CHeat(void) const;

IRremoteESP8266/src/ir_Fujitsu.cpp

Lines 570 to 597 in 434582a

	/// Set the 10C heat status of the A/C.
	/// @param[in] on true, the setting is on. false, the setting is off.
	void IRFujitsuAC::set10CHeat(const bool on) {
	switch (_model) {
	// Only selected models support this.
	case fujitsu_ac_remote_model_t::ARREW4E:
	setClean(on); // 10C Heat uses the same bit as Clean
	if (on) {
	_.Mode = kFujitsuAcModeFan;
	_.Power = true;
	_.Fan = kFujitsuAcFanAuto;
	_.Swing = kFujitsuAcSwingOff;
	}
	default:
	break;
	}
	}
	/// Get the 10C heat status of the A/C.
	/// @return true, the setting is on. false, the setting is off.
	bool IRFujitsuAC::get10CHeat(void) const {
	switch (_model) {
	case fujitsu_ac_remote_model_t::ARREW4E:
	return (_.Clean && _.Power && _.Mode == kFujitsuAcModeFan &&
	_.Fan == kFujitsuAcFanAuto && _.Swing == kFujitsuAcSwingOff);
	default: return false;
	}
	}

There is little I can do programmatically to tell which remote generated the message & what the destination device is, from just the discrete IR message. If you want to control the "Min Heat"/"10C Heat" option, via Tasmota (which uses the IRac interface, you will have to use it via the "Clean" tasmota option, and Model ARREW4E at present.

I'll try see if it is safe to add Clean/10C heat to the model you're using without it breaking other people's usage.

The 56 bit commands should not reset any of the other settings that they aren't touching.

I'll also look into if I can better use the previous state for any Fujitsu A/C messages when using the IRac (Tasmota) interface. However, if I do make improvements there, it doesn't mean they will be automatically reflected in Tasmota. I don't control how they use the IRac interface or if they do previous state tracking at all.

Unfortunately Fujitsu A/C support being one of the oldest supported by this library, and the {cough} fun way that Fujitsu implemented their protocol, it will take some time to work it out. i.e. Don't hold your breath. A minor change in that Protocol takes a LOT of work.

It should also probably show temp as 10C/50F instead of inheriting the last normal temp.

As indicated, this may not be easy or possible, given the mess of the protocol implementation. i.e. Not being able to tell a "clean" from a "10C Heat" message reliably.

Note: The "10C Heat", and other special functions like that are not supported via the IRac interface, as it is for "common across most A/C" functions. IRac gives a standard interface to provide generic control of any library supported A/C protocol. It is not meant for full detailed control. Hence, if you want the best control of the device, you need to us the protocol specific class (IRFujitsuAC).

Btw, thanks for the detailed "Issue report", it is really appreciated. :-)

[PostLogical]

Thanks for a great response. I appreciate all the hard work you've put into this project and helping people like me.

Given most or all of the issues I am having won't be able to be fixed in this codebase, I'm hacking something together on the other end (been using Tasmota-IRHVAC custom component for Home Assistant, so I'm rewriting parts of that code to handle my particular AC remotes). In that pursuit, could you help me with a couple basics?

1. How am I intended to use the remote model numbers? Obviously my remotes were almost all under Model 1, so using that gets me most of it, but then I would need to switch to Model 3 or Model 5 for a couple commands. Does Model 5 do everything the same as Models 1 and 3 so I could just use Model 5 for all my instructions? Or am I totally off base on how this should go? (Sidenote: I would have hoped there would be some way to set my particular remote as the model, even if it is just an alias for another model's code, but then ideally also have a way to set the Model for receiving code. I'm not sure how that would work, but if it were possible to set those, then I imagine it would overcome the current limitation of trying to deduce what remote is speaking to the codebase.)
2. How can I use IRsend with FUJITSU_AC? In order to get commands like Economy and Powerful into my Home Assistant interface, I'm trying to use Preset Modes, and then in the Tasmota-IRHVAC code I'm intercepting the commands for the codes I outlined in my Google Sheet. So I planned to use IRSend to send the hex code for those commands, but I can't get any of the Fujitsu codes to work that way. Even when I enter them directly into the Tasmota console such as irsend {"Protocol":"FUJITSU_AC","Bits":56,"Data":0x14630010106C93}, the console says {"IRSend":"Done"}, but no IR seems to be sent out (I've checked both by trying to send command to AC and by putting another Tasmota near the sending unit to try to receive the output). Can I not use the irsend command with the Fujitsu protocol? It does work with protocols like NEC using the method I just described. I imagine I could send raw IR, but I think there's some issue with the character limit for MQTT.

Any help you could provide on those two would be greatly appreciated, and I'll come back to post my work if I can get it functional. If none of it can work, then perhaps I'll try to switch to a Home Assistant component and something like ESPHome that can speak directly to your codebase instead of using MQTT.

[crankyoldgit]

First off, have patience. :-)
I've got, some if not most persistence of settings working visa the IRac interface for Fujitsu in a branch I have under development.
You'll see it soon.

1. How am I intended to use the remote model numbers?

See:

IRremoteESP8266/src/IRsend.h

Lines 119 to 131 in 434582a

	/// Fujitsu A/C model numbers
	enum fujitsu_ac_remote_model_t {
	ARRAH2E = 1, ///< (1) AR-RAH2E, AR-RAC1E, AR-RAE1E, AR-RCE1E (Default)
	///< Warning: Use on incorrect models can cause the A/C to lock
	///< up, requring the A/C to be physically powered off to fix.
	///< e.g. AR-RAH1U may lock up with a Swing command.
	ARDB1, ///< (2) AR-DB1, AR-DL10 (AR-DL10 swing doesn't work)
	ARREB1E, ///< (3) AR-REB1E, AR-RAH1U (Similar to ARRAH2E but no horiz
	///< control)
	ARJW2, ///< (4) AR-JW2 (Same as ARDB1 but with horiz control)
	ARRY4, ///< (5) AR-RY4 (Same as AR-RAH2E but with clean & filter)
	ARREW4E, ///< (6) Similar to ARRAH2E, but with different temp config.
	};

Also, patience. You may yet get your own model number.

In short, use the model number that works for your device, and has the feature set they matches closest.

IRrecvDump etc works on a single message, it has no memory/state of what it has seen previously.
Hence it can't determine what model you actually have, all it can say is "The message I just saw in the simplest case belongs to this model variant.". I.e. some models are a subset of other models. Some messages are common to all models or a group.

2. Even when I enter them directly into the Tasmota console such as irsend {"Protocol":"FUJITSU_AC","Bits":56,"Data":0x14630010106C93}, the console says {"IRSend":"Done"}, but no IR seems to be sent out

I can't speak for how Tasmota does things, you'll need to raise it with them.
If I was to guess, you are possibly calling it wrong.
Some protocols require/expect an integer, some require/expect an array. Fujitsu is the latter case. It looks like you're calling it with the former case.

[crankyoldgit]

Can you please download & try out branch https://github.com/crankyoldgit/IRremoteESP8266/tree/Issue1780 / PR #1784 and report back how it goes?

This doesn't address your "sending a 10C heat message" issue for your model yet, but it should address some of your issues. Well, as long as Tasmota is doing things correctly w.r.t previous states when using IRac.

[crankyoldgit]

FYI, looking at the model descriptions I listed earlier, I'd use ARRY4 / 5 as the Model for your remote emulation. clean should control the 10C heat operation.

[crankyoldgit]

@PostLogical Any luck?

[PostLogical]

Sorry for the delay. Little guy has been taking all my free time of late. I tested it out with the IRrecvdumpV2 code and with Tasmota. It looked like it was working great in IRRecvDumpV2, but it does not seem to work in Tasmota. The IRHvac command still appears and it has the default numbers like 16C.

I'll go ahead using Model 5 for my remote. And I'm happy to test any further changes to see how they work out.

For now, I've forked the Tasmota-IRhvac code for home assistant and modified it to my purposes: Tasmota-IRhvac for Fujitsu. I think I've got everything working well except perhaps the 10C mode which needs more attention. Since I only have the two remote types to worry about, I just hard coded some of the key elements. I also implemented preset_modes so there's a way to send the commands in the first place (Tasmota-IRhvac didn't have them yet except a weird away temp mode).

[crankyoldgit]

No worries.

Can you please provide the complete sequences of message (i.e. the state[]s) so I can reproduce/verify what is happening in IRac to make sure it still isn't our library's problem?

[crankyoldgit]

@PostLogical Been a week, just chasing up on the requested info.