Daikin BRC52B63 remote for 17 series

[vena]

Thanks for this awesome library. I have a few Daikin 17 series single-zone heat pumps which use a BRC52B63 remote, which I believe Daikin introduced last year. No existing IR library I've found works with it, and IRrecvDumpV2 reports encoding is unknown.

I've recorded raw data for everything but the timer functions, but I don't know what to do with it from there to add support for this remote to the library. I've confirmed the data is recognized correctly by the 17 series units with sendRaw() at 38hz, although auto_analyse_raw_data.py reports "DANGER: Unexpected and unused mark timings!" No expectation for anyone to do the work here for me, but I figured the data might be useful/interesting.

https://docs.google.com/spreadsheets/d/1-YJnHyzy6bId5QmjTEZuw8_wSufESoIl-L_VEF-o8lM/edit?usp=sharing

Thanks again!

[crankyoldgit]

I agree, this is a protocol we don't support (yet).

I'll add something quick to support the basic send/receive functionality. (i.e. recognise it and convert to/from a uint8_t state[] form. Once we have that, you'll need to capture a sequence of temp values starting from the lowest possible, to the highest. That will then help us work out if the bit order (LSB first or MSB first) for the internal structure.

Once we've updated for that, you'll need to go through and recapture everything recording the state[] output, Then you can try to work out what bits have changed/control what functions etc etc.

P.S. Is there a way to switch the remote/aircon unit to Celsius at all? Most of the library uses celsius natively, and it will make life easier. We can add native Fahrenheit during the process later.

[vena]

Oh great, I'll take any recordings needed. Temp scale change is no problem (undocumented, but temp +/- pressed at once switches it on the remote). I've added a celsius scale sheet of raw data to the above spreadsheet for reference, and I'll keep it at celsius going forward.

[crankyoldgit]

Ta. But as I said, wait till I've added the basic support for it. We'll need to work out the bit ordering before we proceed.

Any chance you can include the exact model number for the A/C unit(s)?

[vena]

indoor units i have are models FTXB12AXVJU and FTXB09AXVJU. remotes are the same BRC52B63 and the units respond to any of them.

[crankyoldgit]

Thanks. Noted.

I've added the basic support. Now, to try to work out the bit ordering based on this. Only do the temps. And typically, aim for settings that give zeros. e.g. Auto mode, auto fan etc. No swing, nothing special. It helps makes working out the temp bits/bytes easier.

Using the linear sequence of temp values helps work out if we have the bit ordering correct or not. 50/50 chance. We may need to swap it, and that will invalidate all the data collected, so don't go crazy yet.

There will probably be two checksum bytes that also change. If it is the same as other daikin's it they will be in state[7] and state[15].

Please download and try the code in: https://github.com/crankyoldgit/IRremoteESP8266/tree/Daikin128 and report back how it goes.

[vena]

Here you go. two bytes change, but looks like they're state[6] and state[7]:

https://docs.google.com/spreadsheets/d/1dQgfz6qBgeoiF-S5-7zzX1Y4cvkFTVPY2SGnS9KT-No/edit?usp=sharing

[crankyoldgit]

Looks like we got the bit ordering right. So go forth and decode/analyse all the things.

On Sat., 20 Jul. 2019, 11:15 pm Daniel Vena, notifications@github.com wrote:

Here you go. two bytes change, but looks like they're state[6] and state[7]:

https://docs.google.com/spreadsheets/d/1dQgfz6qBgeoiF-S5-7zzX1Y4cvkFTVPY2SGnS9KT-No/edit?usp=sharing

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/crankyoldgit/IRremoteESP8266/issues/827?email_source=notifications&email_token=ADBCODH7ZN524FEWBCFURRLQAMFWLA5CNFSM4IFNHBQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2NOCLI#issuecomment-513466669, or mute the thread https://github.com/notifications/unsubscribe-auth/ADBCODC25M57FQRUGPLNBRTQAMFWLANCNFSM4IFNHBQA .

[vena]

Do you just need the state array for all that, or do you need the full output?

[crankyoldgit]

Just state arrays.

Hmmmm. The temp values are v.odd. i.e 19c is 0x19, and 20c is 0x20, instead of 0x19 + 1 = 0x1A.

On Sat., 20 Jul. 2019, 11:21 pm Daniel Vena, notifications@github.com wrote:

Do you just need the state array for all that, or do you need the full output?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/crankyoldgit/IRremoteESP8266/issues/827?email_source=notifications&email_token=ADBCODHQNC6SOSEJVR545LTQAMGL7A5CNFSM4IFNHBQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2NOF7A#issuecomment-513467132, or mute the thread https://github.com/notifications/unsubscribe-auth/ADBCODDRXUW4NZ6DWIJSDMTQAMGL7ANCNFSM4IFNHBQA .

[vena]

Here's all but timers: https://docs.google.com/spreadsheets/d/1dQgfz6qBgeoiF-S5-7zzX1Y4cvkFTVPY2SGnS9KT-No/edit?usp=sharing

Note "powerful," "quiet," and "econo" functions don't apply or send data in auto mode, so I set the initial state to cool mode for capturing those.

I can add the on/off timer functions, but I'm not sure how to go about capturing that. I could capture several attempts to change both by minutes and hours, noting exact times set, if that works?

[vena]

i confirmed the temp values, that's definitely what it's sending. the remote manual is a bit funny on the temperature scale, it says: "The temperature setting range is from 60.8F (16C) to 86.0F (30C) (Optional setting 68.0F (20C) to 86.0F (30C))," but it's unclear how the two ranges apply, why one is optional, or why it would have a different lower bound.

[crankyoldgit]

Now we've confirmed the bit order, and you've captured most of the data etc, you can capture a temp range in degF so we can work out how to handle that natively too. Here is probably a bit somewhere which records if it is in C or F.

Next, you need to work out what columns/bytes of state[] change for each setting. I suggest highlighting those columns.

It looks like as I said. state[7] is the checksum for state[0] to state[6] and state[15] is the checksum for state[8] to state[14]. We'll need to work out what algorithm it is using to calculate it.

Then (or in parallel to the checksum stuff) you need to understand/decode what individual bits of each state[] mean what. e.g. state[1] seems to contain the operating mode AND fan speed AND powerful + quiet setting etc.

Basically, when a bit changes, you need to be able confident as to why.

e.g. state[9]: Bit 0 (lsb) is LED on for all units. e.g. 0b00000001 Bit 3 is LED on just for wall units. 0b00001000 + above Bit 2 is on/off for Econo mode. 0b00000100

Also, can you confirm if the power message is only a single code. i.e. Is it always the same? Does it include the mode/temp etc? Is there a difference between it being pressed back to back? (ie. Does the code change at all when doing that?

When you've worked out all of that. Let me know and I can code it up.

[vena]

Hmm... if state[7] is a checksum for the first 6 bits, then are we missing something here? checksum is the only change for sleep, swing, and power from any other presses that enter the same state.

also confirming, power sends the same codes on multiple presses.

Fahrenheit is funny. it follows the celsius state except it skips degrees. however, state[7] is different from celsius at the same state[6] as if there's something missing, so not sure if it's faking the fahrenheit scale or there's some additional information not recorded.

i can at least confirm the current time is relayed by state[2] (minute) and state[3] (hour). like the celsius scale it's literal, so 20 (8pm) is 0x20.

[crankyoldgit]

I'm fairly confident that the checksum is only a 4-bit checksum, not the entire 8 bits. Just the upper half. e.g. state[7] >> 4 is the checksum. swing & sleep are probably stored in the lower half of state[7]

Several different A/Cs have used 4-bit verification. So it is not uncommon. e.g. Kelivinator uses a sum only half of the preceding bytes and Sharp A/C

Based on the similarities of Kelvinator, I'd look there first.

Looking at the temp data, it's pretty clear it's an "addition" based calculation, rather than an xor.

[crankyoldgit]

If your A/C head unit doesn't display the desired temp on it, then my guess is it's using Celsius natively (see, that's why I suggested using it first ;-) and the remote is doing the conversion before sending. e.g. 5/9ths is close to 0.5 so 2F for every 1C. It's not like people are using these devices as a scientific device. ;-) Humans are not going to notice a 0.5 degC difference and I doubt even more users would notice the very fractional temp conversion inaccuracies. Welcome to your remote giving you a placebo 50% of the time you increase/decrease the temp by 1F. ;-) You're being lied too! ;-)

Come the Dark Side(tm), give up on Imperial Measures. Forget how many fathoms per foot pound by furlong squared things are. All of you Base-10 are belong to us! Come join us in the Metric Wonder Land!!!!one! We have cake[*]!

[* The cake may be a lie.]

[vena]

haha, yes, the stock unit gives no feedback about the temperature setting it's operating under. there are wired controllers available for these, but without one i can't say if it would accurately reflect what the IR remote sends in fahrenheit.

the social programming is quite strong in the US, man! we will swear until death we can tell it's not giving us those 2 degrees, dammit.

went through and highlighted the changes on the previous sheet.

then i dove into state[1]. now that i've broken that down and put all the functions that change it all together, it actually seems to make sense. i was thrown off at first because i didn't realize system mode fan automatically switched the fan speed to low (which i suppose makes sense because fan mode isn't a temperature control mode?). powerful and quiet are a cute combination of fan speed settings, the manual even makes it clear they're simply special fan speeds. so as you can see, the first half of state[1] controls the fan, the second controls the system mode.

[crankyoldgit]

Looking good! Keep at it.

[vena]

the checksum is still utterly mysterious to me, but i guess the second half of state[7] plays a factor in it somehow. i did a test of temp 30C and temp 30C + sleep at the same hour and minute so state[0] through state[6] were all the same for the two readings... and the first half of the state[7] differs.

30C:
00010110 00011010 01000110 00100001 00000000 01100011 00110000 11110100

30C+Sleep:
00010110 00011010 01000110 00100001 00000000 01100011 00110000 00010110

[crankyoldgit]

Have you tried summing all the nibbles/octets/4-bit blocks together, including the other half of state[7]?

[vena]

i think i've got it. confirmation.

for left side of the burst, it's the sum of all preceding 4-bit segments plus the last part of state[7], then ditch the overflow. for the right side, state[15] looks to be a full 8-bit checksum summing 4-bit chunks of state[8] to state[14]. there's only two functions that touch 8-14 so confirmation is limited, but it covers those functions.

i kept thinking it was summing only the left or right half of each byte for some reason, and then i went down a dark path of looking at other daikin IR checksums that reverse bytes and made life more difficult for myself.

so anyway, with that, i think i've mapped everything exposed by this remote, including the scheduler...

https://docs.google.com/spreadsheets/d/1y34UQ1pMr9jU-STCydHa5B_sdOG9Y7nYshcntw7aQwk/edit?usp=sharing

[crankyoldgit]

That's excellent news! I'll start looking at coding it up real soon.

[crankyoldgit]

@vena [Q] regarding state[1], is the fan always locked in auto mode for non-fan modes? Or can that be set? e.g. Cool mode + fan low etc. It's unclear from the spreadsheet.

[vena]

that was just me isolating the functions to the least change possible per recording. i've added fan speed changes for each mode where it's allowed to another tab on this sheet:

https://docs.google.com/spreadsheets/d/1dQgfz6qBgeoiF-S5-7zzX1Y4cvkFTVPY2SGnS9KT-No/edit?usp=sharing

"Fan speed per mode"

That brings up restricted functions in modes! Here are all the restrictions I've found:

Dry mode: no fan speed adjustments at all (including the "special" ones, quiet and powerful), no sleep, no econo. Fan mode: no auto fan speed, no quiet, no powerful, no sleep, no econo. Auto mode: No quiet, no powerful, no econo.

[vena]

And to be clear, modes cool and heat allow all functions.

edit: also, no temperature changes in fan mode. it still seems to remember and send the temperature last set in another mode, though.

[crankyoldgit]

(Not looked at the sheet yet) In Dry mode, does no fan adjustments mean it's locked to "auto fan speed" or to what ever the last fan speed was?

[vena]

Good question. I did some captures, fan speed previously set to medium in another mode, changing the temperature in dry mode. Looks like it just sends the previous fan speed. state[1] stays at x41, which is fan speed medium and dry mode.

0x16    0x41    0x11    0x22    0x07    0x22    0x30    0x44    0xA1    0x00    0x00    0x00    0x00    0x00    0x00
0x16    0x41    0x11    0x22    0x07    0x22    0x29    0xC4    0xA1    0x00    0x00    0x00    0x00    0x00    0x00
0x16    0x41    0x11    0x22    0x07    0x22    0x28    0xB4    0xA1    0x00    0x00    0x00    0x00    0x00    0x00
0x16    0x41    0x11    0x22    0x07    0x22    0x27    0xA4    0xA1    0x00    0x00    0x00    0x00    0x00    0x00

[vena]

sorry, typed too quickly - fan speed was set to medium previously in the post above, not auto. edited to correct, but want to be clear in case you saw that.

[crankyoldgit]

Just checking I understand. When in dry mode, fan is always "medium", but is restored to prev setting when no longer in dry mode. correct?

[vena]

it sends its memory of whatever fan speed was last set to in a mode that supports it. probably just a convenience for when you change back to a mode that supports fan speeds.

previous set to fan speed auto in another mode, changing temp in dry mode

0x16    0x11    0x22    0x22    0x07    0x22    0x29    0xB4    0xA1    0x00    0x00    0x00    0x00    0x00    0x00
0x16    0x11    0x22    0x22    0x07    0x22    0x28    0xA4    0xA1    0x00    0x00    0x00    0x00    0x00    0x00
0x16    0x11    0x22    0x22    0x07    0x22    0x27    0x94    0xA1    0x00    0x00    0x00    0x00    0x00    0x00

previously set to fan speed high, changing temp in dry mode...

0x16    0x21    0x24    0x22    0x07    0x22    0x28    0xD4    0xA1    0x00    0x00    0x00    0x00    0x00    0x00
0x16    0x21    0x24    0x22    0x07    0x22    0x29    0xE4    0xA1    0x00    0x00    0x00    0x00    0x00    0x00

[vena]

seems the unit itself decides the fan speed for dehumidifying (possibly has a humidity sensor) regardless of what the remote sends as the fan speed in dry mode. for example, i set fan speed to high in cool mode, it's noticeably loud. then changed to dry. i can see the remote is still sending the code for fan speed high (0x21), but the fan is various amounts of barely audible.

[crankyoldgit]

"Fan speed per mode"

I've decided not to emulate that aspect of the remote. It'd be too confusing to a user using the class operators/methods.

[vena]

no complaints here, i figure you’re emulating a signal, not the remote UI.

might also want to give me a day to test those other restrictions. if the remote still sends those bits set in another mode when switching to an unsupported mode, there may be no harm in not bothering...

[crankyoldgit]

That's the part I want to emulate. i.e. So it can't produce a signal that isn't accepted by the A/C.

[vena]

i highly suspect that the remote has very basic memory and is sending things like econo set in cool mode when switching to dry since the remote remembers it when switching back to cool.

but it’s late here and i’ve been told to stop making the AC beep :)

[crankyoldgit]

Pro Tip: You don't need to point the remote at the A/C to read it with the ESP. Or even be in the same room. :)

[vena]

and no wall units in the basement to catch a stray reflection! honestly, who designs a system that lets you turn off the LED, but not the buzzer?

some bad news. testing mode-restricted functions, set initially in cool, then switching to other modes:

Sleep: sent in all modes. Quiet: not sent in dry, fan, or auto modes. Powerful: not sent in dry, fan, or auto. Econo: not sent in dry, fan, or auto.

remote's smarter than i gave it credit! really would have thought it'd keep sending econo at least since there's no collision. quiet/powerful makes sense i guess since fan mode doesn't support them, allows fan speed changes, and they use the same bits.

[crankyoldgit]

In case it wasn't clear, you can download/follow along/test the code via the Daikin128Detailed branch: https://github.com/crankyoldgit/IRremoteESP8266/tree/Daikin128Detailed

It's starting to take shape. I believe IRrecvDumpV2 should now display some detailed feedback about the messages after those last commits.

[crankyoldgit]

Okay, PR #832 is out for review. I think I've covered everything in your spreadsheet. It's able to fully construct a message from scratch to replicate the state[] of one of your messages.

Please download and test. Feedback welcome. Fingers crossed it should just work.

If you rebuild IRMQTTServer against this branch, it should support it out of the box.

[vena]

receiving looks good all over. for sending, while i can't get true feedback from the units since they have no display of their own, commands are accepted by the wall units and from the outside appear correct. mode changes work, fan speed changes are noticeable, timers work, swing works, lightToggle works... everything just works!

and my LEDs have far better range than the remote's, so that'll be a nice bonus for controlling the system this way.

thank you for all your help getting these units supported! i hope daikin didn't do anything too silly and this scheme can support the whole BRC52 remote and 17 series range.

[crankyoldgit]

\o/ Excellent. It went pretty smoothly, mostly because of all the good work you did in documenting it and decoding it. It (#832) should get merged inside of a week from now. I'll probably push a new release of the library around then too.

[crankyoldgit]

FYI, the code changes thus far have been included in the v2.6.4 release of the library.

[qcarver]

Gents, sad to inform you that the Daikin128 protocol doesn't work with my new 17 Series FTXB24AXVJU, and in a scary way. The protocol is so close that I get the acknowledgement beep. The only feedback I have from the unit is the blue/red/violet LED. So far what I can observe visually... Where Daikin128 -> FTXB24

• Mode Heat -> Mode Cool,
• Mode Cool -> OFF
• VerticalSwing* -> Cool

can't seem to mash any button which puts it in Heat mode.

*(btw, there is no H swing)

[crankyoldgit]

Gents, sad to inform you that the Daikin128 protocol doesn't work with my new 17 Series FTXB24AXVJU, and in a scary way. The protocol is so close that I get the acknowledgement beep. The only feedback I have from the unit is the blue/red/violet LED. So far what I can observe visually... Where Daikin128 -> FTXB24

• Mode Heat -> Mode Cool,
• Mode Cool -> OFF
• VerticalSwing* -> Cool

can't seem to mash any button which puts it in Heat mode.

*(btw, there is no H swing)

Thanks for the info. Good to know. Can you please also supply us with the exact model number of the remote?

If you want to get it supported, please create a new issue and follow: https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-AC-protocol#a-note-on-collecting-data

Then we can see what we can do for you.

[qcarver]

Hello/thx, The remote came with the unit (or at any rate was given to me by the contractor that installed it). There is no blatant marking on the remote exhibitting a model number per se. However, if I flip over the remote I see a dime sized QR code that equates to "3P605270-1". If i look under the batteries in the top well I see the die embossed ">PS<2" (polystyrene) recycle code. In the bottom well I see the black printed numbers "TL701".

[crankyoldgit]

Thanks for trying. None of those seem to be a Daikin remote model code, they tend to start with ARCxxxxxxx

[qcarver]

Yep, likewise thx for the feedback. I started the issue as per... You probably saw it already, jic: https://github.com/crankyoldgit/IRremoteESP8266/issues/1754

[crankyoldgit]

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