Irremoteesp8266: Able to turnOFF Fujitsu AC, but cannot TURN ON.

[neykovt]

Version/revison of the library used

2.1.1

Expected behavior

Turn on Fujitsu ASYG12LMCA .
Try to use TurnOnFujitsuAC from examples to turnOn my Fujitsu AC ( used remote is : ar-reb1e )
but it's don't work. Function for turnOFF work from first time.

I also try to use irsend.sendRaw() .. I describe my case here:
https://forum.arduino.cc/index.php?topic=488988.0

[crankyoldgit]

@jonnygraham As they are the ones who added the code.

[crankyoldgit]

FYI, in the example you link to, your code seems to be sending the commands (via raw) back-to-back without a gap/delay. That may be causing you a problem. Try adding a delay(1000) between them all.

[crankyoldgit]

Looking at your rawData captures as per that link, they seem incredibly short. I think you are not capturing correctly. If you haven't already, try increasing the RAWBUF value to something like 512.

[jonnygraham]

I'll have a look at this.

I agree that the codes in the link don't look right.
Here's an Excel file I generated from recording my signals in various states when I developed the code.
fujitsu_recordings2.xlsx

[neykovt]

Hi, thank you for fast response.
i have change RAWBUF to 512.
Now code is longer, but still no response from AC unit. I am stay just in front of it so distance is not a problem.
New codes are:
uint16_t onn[259] = {3350,1650, 450,450, 450,450, 450,1250, 450,450, 450,1250, 450,450, 450,450, 450,450, 450,1250, 450,1250, 450,450, 450,450, 450,450, 450,1250, 450,1250, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,1250, 450,450, 450,450, 450,450, 500,350, 450,450, 450,450, 450,450, 450,1250, 450,450, 450,450, 450,450, 450,450, 450,1250, 450,1250, 450,1250, 450,1250, 450,1250, 450,1250, 450,1250, 450,1250, 450,450, 450,450, 450,1250, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,1250, 450,1250, 450,450, 450,450, 450,1250, 450,450, 450,450, 450,450, 450,450, 450,1250, 450,450, 450,1250, 450,1250, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,1250, 450,450, 450,450, 450,450, 450,1250, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,450, 450,1250, 450,450, 450,1250, 450,1250, 450,450, 450,1250, 450,1250, 450,1250, 450,1250, 450,1250, 450,450, 450}; // UNKNOWN E1DFB6C4

And for OFF is short:
uint16_t off[115] = {3350,1650, 450,400, 450,450, 450,1250, 450,400, 450,1250, 450,400, 450,400, 450,400, 450,1250, 450,1250, 450,400, 450,400, 450,400, 450,1250, 450,1250, 450,400, 450,400, 450,400, 450,400, 450,400, 450,400, 450,400, 450,400, 450,400, 450,400, 450,400, 450,400, 450,400, 450,1250, 450,400, 450,400, 450,400, 450,400, 450,400, 450,400, 450,400, 450,1250, 450,400, 450,400, 450,400, 450,400, 450,1250, 450,400, 450,400, 450,400, 450,400, 450,400, 450,400, 450,1250, 450,400, 450,1250, 450,1250, 450,1250, 450,1250, 450,1250, 450,1250, 450}; // UNKNOWN B9A754C5

I try send this, then remove first one and short code length with one. Still not response. Remove and second value (1650) but still nothing.

Command used for send is :
irsend.sendRaw( onn , size in [] , 38);
delay(2000);
irsend.sendRaw(off, 115, 38);
delay(2000);

[crankyoldgit]

Well, at least the codes look complete/near expected this time.

[neykovt]

Should i remove first 2 values ?
and
if i use fujitsu.setCmd(FUJITSU_AC_CMD_TURN_FF); and send it , it's work fine.

[crankyoldgit]

I just manually compared your _off_ sequence with that of setCmd(FUJITSU_AC_CMD_TURN_OFF);
They are identical, data-content-wise.
i.e.

uint16_t off[115] = {3350,1650, 450,400, 450,450, 450,1250, 450,400, 450,1250, 450,400, 450,400, 450,400, 450,1250, 450,1250, 450,400, 450,400, 450,400, 450,1250, 450,1250, 450,400, 450,400, 450,400, 450,400, 450,400, 450,400, 450,400, 450,400, 450,400, 450,400, 450,400, 450,400, 450,400, 450,1250, 450,400, 450,400, 450,400, 450,400, 450,400, 450,400, 450,400, 450,1250, 450,400, 450,400, 450,400, 450,400, 450,1250, 450,400, 450,400, 450,400, 450,400, 450,400, 450,400, 450,1250, 450,400, 450,1250, 450,1250, 450,1250, 450,1250, 450,1250, 450,1250, 450}; // UNKNOWN B9A754C5
irsend.sendRaw(off, 115, 38);

is the same as:

fujitsuACSender.setCmd(FUJITSU_AC_CMD_TURN_OFF);
irsend.sendFujitsuAC(fujitsuACSender.getRaw(), FUJITSU_AC_STATE_LENGTH_SHORT);

The only difference are some subtle timings.

The easiest way to adjust your captures timings to match that of libraries, you could change the values of every even number (starting at the 4th number) to either 367 (for low values) or 1182 (for high values).

e.g.

uint16_t off[115] = {3350,1650, 450,367, 450,367, 450,1182, 450,367, 450,1182, 450,367, 450,1182, etc ...

I haven't compared the _on_ command you listed. As it is larger and more difficult.
If changing the even values works for you, I suggest you try the same for your raw capture for your on command.

Let me know how that goes.

[jonnygraham]

I compared the _on_ command. It looks like it's trying to set to 26C, Mode:Cool, Fan: High, Swing:  Vertically. BTW, if you paste the recorded values into the Excel I attached earlier, it decodes it to binary and Hex lower down.

The only difference I can is that the 15th byte is 0xA0 but in _all_ of my recordings I got 0x20. I assume it is something to do with the remote? The checksum looks like it's calculated including the 0xA0 so that's consistent.

The exact timings in the library of 448, 367 and 1182 microseconds are based on the averages of a set of measurements I took using an Arduino to capture, so I can't know how accurate they really are. And then when we replay them, there must be another margin of error.

[crankyoldgit]

@jonnygraham That is pretty typical of my experience with working out timings. The receiving devices allow for a margin of error. The best we can do is try to aim down the middle. The 15th byte thing has me scratching my head too. I really need to try this out on my Fujitsu unit. :-/

My guess is @neykovt 's capture timings are slightly skewed, as the raw captures _should_ work. I want to know from him if adjusting the values for his raw captures works for him before we proceed further.

[neykovt]

Ok, a manage to turn it on :)
Issue was that i use fujitsu.setSwing(FUJITSU_AC_SWING_BOTH) but my Unit d not have horizontal swing and it's make code wrong. Change it to FUJITSU_AC_SWING_VERT) and it work.
Also i found, that i have to send all options each time.
Can't send only fujitsu.setCmd(FUJITSU_AC_CMD_TURN_ON); It do not work.
I used:
fujitsu.setCmd(FUJITSU_AC_CMD_TURN_ON);
fujitsu.setSwing(FUJITSU_AC_SWING_VERT);
fujitsu.setMode(FUJITSU_AC_MODE_COOL);
fujitsu.setFanSpeed(FUJITSU_AC_FAN_HIGH);
fujitsu.setTemp(24);

Even that,i sill can't manage to send raw data. But thank you for support

[crankyoldgit]

Thanks for the feedback. Glad it is kind-of working for you now.
To help us improve it, can you tell us the _minimum_ set of commands you need for it to work? That may help us track down where/why _just_ the setCmd() on it's own doesn't work. Based on your feedback, I have a hunch you'd need the following (minimum) to get it to work:

fujitsu.setCmd(FUJITSU_AC_CMD_TURN_ON);
fujitsu.setSwing(FUJITSU_AC_SWING_VERT);

@jonnygraham I'm _just guessing_ but, I think the default values include the swing. We should probably default to values that don't have a swing, thus potentially solving future issues.

[jonnygraham]

Yes, I agree that we should change the swing default to be OFF. Cmd already defaults to TURN_ON.
The way that the remote works is that it sends all of the values - there's no way to say 'adjust the temperature to 26 but leave everything else as it is now' so you need to have everything set to some value. There are defaults so the set...() calls override the default for each thing.

[crankyoldgit]

@jonnygraham Acknowledged. That's the way the Kelvinator one works. i.e. It has a concept of a default 'known good' state, and all the set() modifiers just modify that.

[neykovt]

i can confirm.
fujitsu.setCmd(FUJITSU_AC_CMD_TURN_ON);
fujitsu.setSwing(FUJITSU_AC_SWING_VERT);
is only needed to turn AC on.

Any idea why sendRaw() do not work ?

[crankyoldgit]

See my earlier comments. I think your capture timings are on the slow side.
Try modifying the values as I said.

On Tue., 18 Jul. 2017, 4:37 am neykovt, [e-mail] wrote:

i can confirm.
fujitsu.setCmd(FUJITSU_AC_CMD_TURN_ON);
fujitsu.setSwing(FUJITSU_AC_SWING_VERT);
is only needed to turn AC on.

Any idea why sendRaw() do not work ?

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
https://github.com/markszabo/IRremoteESP8266/issues/275#issuecomment-315843217,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMInDESReof3ctEA6munUj1U-Euo5Rwrks5sO6n0gaJpZM4OWMaq
.

[neykovt]

hi,
sorry for my delay. I edit raw data - low -367, high - 1182 and now it's work. Thank you for advice.

[crankyoldgit]

Glad that fixed it for you. Some receivers have more of a delay than others. Looks like yours is one of those.

[darshkpatel]

@crankyoldgit can we add the label Hacktoberfest to this issue ?

[crankyoldgit]

@darshkpatel done.

[leobel96]

@neykovt I think now this issue can be closed

[crankyoldgit]

It probably can be. Marking this closed for now. However, if anyone feels it shouldn't please update/reopen this issue.