Strange IR signals received from Fujitsu AC ASTG18K and ASTG09K

[mattpurnell]

Hey all - I am seriously out of my depth with these two fujitsu models, it seems..! If anyone can help me with this, you will be doing a massive favour to my sanity.

The FUJITSU_AC library included with IRremoteESP8266 recognises the FUJITSU_AC protocol and commands from my remotes.. but only the 'Turn Off' command works. It is the same if I send back the commands I capture via the IR-enabled tasmota firmware on my Wemos D1 mini - only 'Turn Off' commands work, the rest get zero response from the Aircons.

Some weirdness I am hoping someone can help me understand:

• The rawdata values captured by the ir receiver look different to everyone else’s that I have seen - instead of a regular array of short values, I get some obscenely varied values (see the json snippet below)
• When sending a 'Turn Off' command, I observe Model=1. Turning it on, the Model = 6.
• The 'Data' values - while they are 100% consistent with the 'Turn Off' command, they seem to vary between the "Turn On' commands; rising in value over time.. maybe there is a time component to the codes?

'Data' values in the 'Turn On' Commands, over the space of about 100 seconds:

• 0x1463001010FE09315D01000602062043
• 0x1463001010FE09315D01000602062043
• 0x1463001010FE09315D01000602072042
• 0x1463001010FE09315D01000602082041
• 0x1463001010FE09315D01000602082041
• 0x1463001010FE09315D01000602082041
• 0x1463001010FE09315D01000602092040
• 0x1463001010FE09315D01000602092040
• 0x1463001010FE09315D01000602092040
• 0x1463001010FE09315D01000602102039

Here is a typical payload I get from capturing a device; the rawdata appears to be unique over time:

{"IrReceived": 
 {"Protocol":"FUJITSU_AC","Bits":128,"Data":"0x1463001010FE09315D01000502182032","Repeat":0,
 "IRHVAC": {"Vendor":"FUJITSU_AC", "Model":6,"Mode":"Cool","Power":"On","Celsius":"On",
"Temp":19.5,"FanSpeed":"Auto","SwingV":"Off","SwingH":"Off","Quiet":"Off","Turbo":"Off",
"Econo":"Off","Light":"Off","Filter":"Off","Clean":"Off","Beep":"Off","Sleep":-1},
"RawData":"+3280-1640+415-410CcD-1230CcCeCdCdCdCeCeCdCdCdCeCeCdCdCdCcCdCdCdCdCdCcDdCdCdCeCdCdCdCdDcCdCdCeCdCcCdCcCeCeC-1235De+420eCeCeCeCdCcCeCdCdCdDdCeCdDdCdCeCeCdCdCeCdCeCeCeCdCeCdCeCdCdCdCdCdDcCdCdCdCdCcCdCdCdCdDeCdCeCcCdCcDcCdCdCeCdCdCdCdDc+440-385CcCdCdCeCeCdCdCdCdCcCdCdCdCeGdCdCdC-1225CdCdCeCeDdCdC",
"RawDataInfo":[259,259,0]}}

[mattpurnell]

Ah - regarding the odd-looking rawdata, I found a Tasmota doc on the format - it is just compression for large payloads, with a link to a handy tool for decompression.

All my other issues stand, though, of course!

[crankyoldgit]

• they seem to vary between the "Turn On' commands; rising in value over time.. maybe there is a time component to the codes?

'Data' values in the 'Turn On' Commands, over the space of about 100 seconds:

The bits that are changing are a time value. As far as we've reverse engineered and has been reported, the bits that are changing are the on timer time value. Try disabling the timers on the remote, and see if the code value keeps changing.

• When sending a 'Turn Off' command, I observe Model=1. Turning it on, the Model = 6.

The off command is a fixed special command common to almost all models of Fujitsu ACs.
To control the device, you should be using model "6" if that is what you're seeing with "non-off" commands.

IRremoteESP8266/src/IRsend.h

Line 130 in 082bf30

ARREW4E, ///< (6) Similar to ARRAH2E, but with different temp config.

It is the same if I send back the commands I capture via the IR-enabled tasmota firmware on my Wemos D1 mini

It is incredibly hard for us to take reports from 3rd party software and try and workout what is going on. i.e. There is a whole other layer of interfaces, software, and data formats we are not responsible for, or familiar with.

You need to report Tasmota problems with Tasmota, even if it is using part of there software which uses this library.

If you think it is a problem with our library, we need to have data collected using our tools e.g. IRrecvDumpV2 or V3 and using the library directly for sending. e.g. IRsendDemo & TurnOnFujitsuAC
That way we can be sure we know what is going on.

[mattpurnell]

Fantastic, obviously we all really appreciate the work you guys have done, and to get assistance like this is awesome.

As far as I am aware, there are no timers active - and yet the 'code' keeps incrementing.

I uploaded the IRrecvDumpV3 to my Wemos D1 mini, and the data I get from the 'on' button is pasted below, in case anyone finds that interesting.

The really good news - I uploaded the 'TurnOnFujitsuAC' sketch, with the model set to 'ARREW4E' - and it turned on - massive relief!

Now I just need to figure out how to replace the cutomisations in Tasmota to use the codes you have for ARREW4E - a number of my home automation integrations are geared around the Tasmota MQTT sensors/commands, so I am pretty keen to stick with that platform.

One more thing - how do I make a donation to your efforts?

Many thanks - Matt

Timestamp : 002659.505
Library   : v2.8.0

Protocol  : FUJITSU_AC
Code      : 0x1463001010FE09315D0100000413203A (128 Bits)
Mesg Desc.: Model: 6 (ARREW4E), Id: 0, Power: On, Mode: 1 (Cool), Temp: 19.5C, Fan: 0 (Auto), 10C Heat: Off, Swing: 0 (Off), Command: N/A, Outside Quiet: Off, Timer: Off
uint16_t rawData[259] = {3306, 1610,  418, 410,  418, 408,  418, 1228,  420, 408,  418, 1230,  418, 408,  418, 408,  418, 408,  418, 1228,  418, 1228,  418, 410,  416, 410,  418, 408,  418, 1230,  418, 1228,  418, 408,  418, 408,  416, 410,  416, 410,  418, 408,  418, 408,  416, 408,  418, 408,  418, 408,  418, 410,  416, 408,  418, 408,  418, 408,  418, 1230,  418, 410,  418, 408,  418, 408,  418, 408,  418, 408,  418, 408,  418, 408,  418, 1228,  420, 408,  418, 408,  418, 408,  416, 410,  420, 1226,  420, 1228,  418, 1230,  418, 1230,  418, 1228,  418, 1228,  418, 1232,  416, 1230,  418, 408,  418, 408,  420, 1228,  418, 408,  418, 408,  420, 406,  418, 408,  418, 1230,  418, 408,  418, 408,  418, 408,  418, 1228,  418, 1230,  418, 408,  418, 408,  420, 1228,  418, 408,  418, 1228,  418, 1230,  418, 1228,  418, 408,  418, 1230,  416, 408,  418, 1232,  416, 410,  416, 408,  418, 408,  418, 408,  418, 408,  418, 408,  418, 408,  418, 408,  416, 410,  416, 410,  418, 410,  418, 406,  418, 410,  416, 410,  418, 406,  418, 408,  418, 408,  418, 408,  418, 408,  418, 408,  418, 408,  420, 408,  418, 410,  418, 408,  418, 408,  418, 1230,  418, 408,  418, 408,  418, 408,  418, 408,  418, 408,  418, 1228,  418, 1230,  418, 408,  418, 408,  418, 1228,  418, 408,  418, 408,  418, 408,  416, 408,  420, 406,  418, 408,  420, 408,  418, 408,  418, 1230,  418, 408,  418, 408,  418, 408,  418, 1228,  418, 408,  418, 1228,  418, 1230,  418, 1230,  418, 408,  418, 408,  418};  // FUJITSU_AC
uint8_t state[16] = {0x14, 0x63, 0x00, 0x10, 0x10, 0xFE, 0x09, 0x31, 0x5D, 0x01, 0x00, 0x00, 0x04, 0x13, 0x20, 0x3A};

[crankyoldgit]

One more thing - how do I make a donation to your efforts?

No financial donations required. If you want to donate; code, documentation, & brainpower (analysis) is always in short supply. ;-)

As far as I am aware, there are no timers active - and yet the 'code' keeps incrementing.

Well, it could be a clock function. Dunno. You could do some analysis to work out if that is true, and if so, how it is stored/works etc.

The really good news - I uploaded the 'TurnOnFujitsuAC' sketch, with the model set to 'ARREW4E' - and it turned on - massive relief!

Excellent, that confirms that it isn't a problem with the Library's side of the code.

Now I just need to figure out how to replace the cutomisations in Tasmota to use the codes you have for ARREW4E - a number of my home automation integrations are geared around the Tasmota MQTT sensors/commands, so I am pretty keen to stick with that platform.

You may need to take that up with the Tasmota folk.
I believe you probably need to specify the Model in your JSON MQTT messages.
See: https://tasmota.github.io/docs/Tasmota-IR/#:~:text=%22Model%22%3A%20Some%20HVAC%20have%20variants%20in%20protocols%2C%20this%20field%20allows%20to%20specify%20the%20variant%2C%20see%20detailed%20list.

Now that we know it works for your A/Cs, I see you've supplied the A/C model numbers, I'll add them to the list of supported devices. Can you also supply the model numbers of the remotes for those devices?

[crankyoldgit]

If there is a documented method for deducing the codes into a known format or something I am happy to have a go?

Yes, see: https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-AC-protocol

[mattpurnell]

Thanks again,

Yeah I am fairly certain Tasmota's methods don't yet work for my model, the 'model'/variant is def. specified in the payloads I am sending (model: 6) but it simply doesn't work. I might need to work on getting my variant added as a different protocol in their methods. I will compare the codes out of your tool and slowly figure out where it differs.

One thing I do worry about a bit - I only got as far as your 'TurnOnFujitsuAC' sketch, I should really test all the buttons, and will let you know whether full support is achieved.

I am def. interested in developing extra support if need be - I work in code but I have little experience with Arduino yet, so I think it might be slow going while I play catch-up, so if the timecode is important I should eventually find out and let you know.

My remote (it didn't occur to me that it would be relevant TBH) is AR-REW1E

[crankyoldgit]

Yeah I am fairly certain Tasmota's methods don't yet work for my model, the 'model'/variant is def. specified in the payloads I am sending (model: 6) but it simply doesn't work.

That's odd, as we added support for this device 8 months ago. Tasmota typically is quite up to date.
You really need to raise this with them. i.e. Log an issue with Tasmota.

I might need to work on getting my variant added as a different protocol in their methods. I will compare the codes out of your tool and slowly figure out where it differs.

One thing I do worry about a bit - I only got as far as your 'TurnOnFujitsuAC' sketch, I should really test all the buttons, and will let you know whether full support is achieved.

Full/Maximum control of the device is only available via the IRFujitsuAC class. A more limited set of common controls is available via the IRac class which Tasmota & our own IRMQTTServer use.

I am def. interested in developing extra support if need be - I work in code but I have little experience with Arduino yet, so I think it might be slow going while I play catch-up, so if the timecode is important I should eventually find out and let you know.

It probably isn't needed or required, but we won't say no to add it. ;-)

My remote (it didn't occur to me that it would be relevant TBH) is AR-REW1E

Thanks, that will be added in PR #1702 so future users know which model to use for their devices.

[mattpurnell]

I have raised a ticket with Tasmota, I will update here if that turns up anything interesting.

This is probably of no interest to anyone :) but I will stick it here anyway:

Found 259 timing entries.
Potential Mark Candidates:
[3306, 498]
Potential Space Candidates:
[1610, 1228, 412]

Guessing encoding type:
Looks like it uses space encoding. Yay!

Guessing key value:
kHdrMark   = 3306
kHdrSpace  = 1610
kBitMark   = 418
kOneSpace  = 1224
kZeroSpace = 407

Decoding protocol based on analysis so far:

kHdrMark+kHdrSpace+00101000110001100000000000001000000010000111111110010000100011001011101010000000000000001010000011000000000000000000010010010010
  Bits: 128
  Hex:  0x28C60008087F908CBA8000A0C0000492 (MSB first)
        0x492000030500015D3109FE1010006314 (LSB first)
  Dec:  54197195245841927175134285414474450066 (MSB first)
        97199797431003892239437945859479724820 (LSB first)
  Bin:  0b00101000110001100000000000001000000010000111111110010000100011001011101010000000000000001010000011000000000000000000010010010010 (MSB first)
        0b01001001001000000000000000000011000001010000000000000001010111010011000100001001111111100001000000010000000000000110001100010100 (LSB first)

Total Nr. of suspected bits: 128

[crankyoldgit]

This is probably of no interest to anyone :) but I will stick it here anyway:

Correct, it's not needed as the library is already decoding it. Those steps of adding a new protocol are long long done.

[mattpurnell]

Yeah I suspected as much, unless there was something unusual about those results.

FYI the Tasmota guys have confirmed it isn't supported yet, by them... so I am going to do my best at modifying their code.

[crankyoldgit]

Thanks for confirming that.

In the meantime, if you can't adapt Tasmota, can I suggest using IRMQTTServer located in the examples, it is always up-to-date, and is supported by us/me.
ESPEasy is another option, it's fairly up-to-date as well.

[crankyoldgit]

X-Ref: arendst/Tasmota#14081

[mattpurnell]

Thanks - I am investigating all options, reading code furiously and slowly geting some understanding. I am trying to discover how I can force Tasmota to use the ARREW4E variant from your library - I have tested various variables in 'TurnOnFujitsuAC' and it works perfectly.

I will probably end up using your IRMQTTServer - the main thing I am reluctant to give up, is the humidity/temperature sensor that Tasmota would regularly send updates from via MQTT, which would make the one device per room into all I need to fully automate the climate with Home Assistant :) .. though it might be easier to add support for that to IRMQTTServer than bend Tasmota to my will.

Thanks again for your support, really appreciate it!

[crankyoldgit]

For tasmota, try changing one of the other supported "Models" from say 2 to 6 in it's code, and use that model temporarily?

Sorry, I'm not about to hack Tasmota's code for you, so you'll have to find it on your own.

[mattpurnell]

I never thought you were going to help, that would be next-level assistance :) I was just saying what I am planning to do, apologies if it seemed there was any expectation on my part - you have been extremely helpful already.

That approach you suggest sounds like a good one, replace one of their options with your implementation of ARREW4E. If I find anything that might be of interest I will report back.

[crankyoldgit]

apologies if it seemed there was any expectation on my part - you have been extremely helpful already.

No worries. Wasn't implying anything, nor did I think you were either. Just making it clear. I should have used better language. I can see now re-reading it it came out badly.

[mattpurnell]

Happy new year etc - sorry to bring annoying news, but the IRMQTTServer build fails to turn my AC on either. My remote was detected as a model 6, but setting that model in the Aircon section doesn't work with it. I tried the other numbers as a Hail Mary but nothing there either.

Given that the ARREW1E model worked in the 'TurnOnFujitsuAC' sketch, is there a way to force that model/those codes into your IRMQTTServer build?

Cheers
Matt

[crankyoldgit]

What are the settings you are using on the "/aircon" page of IRMQTTServer (so I can reproduce what it is constructing) and what is the modified code you're using in TurnOnFujitsuAC sketch, again, so I can calculate/reproduce what it would be sending?

[mattpurnell]

Awesome thank you! The only mod to TurnOnFujitsuAC was to set the model as ARREW4E, on line 32 - e.g.:

ac.setModel(ARREW4E);

I think it is worth noting - I did try changing a few other settings temporarily within TurnOnFujitsuAC such as fan speed,mode and temperature - and they all worked fine. I have mainly used ARREW4E (& Model=6) based on the response from some IR receive code - though I can't remember which, happy to capture some more from a tool of your choosing if that is useful.

I tried various settings within /aircon, but typically used those below. I did cycle through all 6 models. Power: Off with Mode: Off successfully turned the AC off.

Protocol: FUJITSU_AC
Model: 6
Power: On
Mode: Cool
Temp: 20 C
Fan: Medium
Swing(V): Lowest
Swing(H): Right
Quiet: Off
Turbo: Off
Econo: Off
Light: Off
Filter: Off
Clean: Off
Beep: Off
Force resend: Off

[crankyoldgit]

IR Lib Version: _IRREMOTEESP8266_VERSION_MAJOR._IRREMOTEESP8266_VERSION_MINOR._IRREMOTEESP8266_VERSION_PATCH

Well, that's a (different) bug in itself.

[crankyoldgit]

So I simulated:

  ac.begin();
  ac.setModel(ARREW4E);
  ac.setSwing(kFujitsuAcSwingOff);
  ac.setMode(kFujitsuAcModeCool);
  ac.setFanSpeed(kFujitsuAcFanHigh);
  ac.setTemp(24);  // 24C
  ac.setCmd(kFujitsuAcCmdTurnOn);
  ac.send();

which generates a valid Fujitsu A/C message of:

"Model: 6 (ARREW4E), Id: 0, Power: On, Mode: 1 (Cool), Temp: 24C, Fan: 1 (High), 10C Heat: Off, Swing: 0 (Off), Command: N/A, Outside Quiet: Off, Timer: Off"
uint8_t state[16] = {0x14, 0x63, 0x00, 0x10, 0x10, 0xFE, 0x09, 0x31, 0x81, 0x01, 0x01, 0x00, 0x00, 0x00, 0x00, 0x4C};

If I set IRac (aka IRMQTTServer) to:
(Note: Slightly different to your settings in IRMQTTServer, notably no swing settings)

Protocol: FUJITSU_AC
Model: 6
Power: On
Mode: Cool
Temp: 24 C
Fan: High
Swing(V): Off
Swing(H): Off
Quiet: Off
Turbo: Off
Econo: Off
Light: Off
Filter: Off
Clean: Off
Beep: Off
Force resend: Off

It also produces a valid Fujitsu A/C message of:

"Model: 6 (ARREW4E), Id: 0, Power: On, Mode: 1 (Cool), Temp: 24C, Fan: 1 (High), 10C Heat: Off, Swing: 0 (Off), Command: N/A, Outside Quiet: Off, Timer: Off"
uint8_t state[16] = {0x14, 0x63, 0x00, 0x10, 0x10, 0xFE, 0x09, 0x31, 0x81, 0x01, 0x01, 0x00, 0x00, 0x00, 0x00, 0x4C};

i.e. Exactly the same.

Code/Proof in 934336f

[mattpurnell]

This is right over my head - but I can confirm I am able to control the AC using Model: 5 with IRMQTTServer, but not Model: 6.. weird that ARREW4E and Model: 6 should be synonymous. Probably related to the version thing..

I don't know what might have caused the version bug you highlighted, I pulled the IRRemoteESP8266 libraries (and the three dependency libs listed in IRMQTTServer) today from within Arduino, while using the IRMQTTServer code from a git pull also from today.

Do you want me to do any further tests, or gather more info?

[crankyoldgit]

Nope. I know what the "version" bug is. I wrote code and didn't actually test it. It's very minor.

[crankyoldgit]

IR Lib Version: _IRREMOTEESP8266_VERSION_MAJOR._IRREMOTEESP8266_VERSION_MINOR._IRREMOTEESP8266_VERSION_PATCH

Well, that's a (different) bug in itself.

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

[crankyoldgit]

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

[mattpurnell]

Thanks for all your support - I've been loving the AC control.