Reverse engineering a Fujitsu Air Conditioner Unit

Description

We have central, reverse cycle air conditioning that is controlled my a wired remote control unit. When I mentioned I was thinking about how to control it via my phone, my wife actually thought it was a good idea, so I made a start before she changed her mind. Building on my Garage Door opening project, I would like to use an ESP8266, talking MQTT to homeassistant.io. Everything will be over TLSv1.2, and I'll continue work on the web configuration interface. Update: My new job is building platform that needs to talk to air-conditioners, so they bought me an intesis device that does what this project was going to do, so I'm marking this as scrapped.

Details

Since this remote control unit (a UTB-YUB/GUB/TUB) doesn't have infrared, I couldn't just point an IR blaster at it. After some googling, I found a number of installation manuals and discovered the remote uses some sort of 1-wire (as in an actual single wire, not the protocol invented by Dallas Semiconductors) to do communication.

A few ebay searches later, and I found new remote control unit for $60 (from a supplier 20 km away), so I have a test unit that I can play with.

First step: Work out how this thing comminucates with the outside unit...

Files

sequences.xlsx

Excel spreadsheet showing different bitstreams depending on the settings of the outdoor unit

sheet - 35.45 kB - 02/25/2017 at 04:48

Download

Project Logs

Collapse

A hardware interface, maybe?
Myles Eftos • 08/12/2020 at 22:56 • 2 comments

[Eddi] made a great find! This is a discussion on EEVBlog on decoding the interface on an LG system. While I think the comms protocol is different, there is a suggested schematic for a Dual Comparator Serial Bus transceiver that looks like it is exactly what we need. I have ordered some LM393s - I'll build the circuit one they arrive. https://www.eevblog.com/forum/projects/where-to-start-trying-to-decode-a-data-stream/25/
In the mean time, I'll pull the second unit I have out and see if I can get it running in slave mode. That was I can listen to it's TX pin, and see if I can work out what it says.
Let's have another look.
Myles Eftos • 06/29/2020 at 12:23 • 3 comments
So, it's been awhile since I've look at this project. I've been busy working on temperature controller for fridges to help make beer and salami. Why is this relevant?
1. It's given me some time away to think, and reset my brain (three years is a legit amount of time)
2. I've been deep diving on other serial protocols like HLDC, and now I know a little bit more.
So I decided to have a look at my spreadsheet again, and look for some different patterns.

I was pretty happy that I had identified the meaning of two bytes, but the rest didn't seem to make sense. As a thought experiment (maybe a silly one - I already knew the answer), I tried to fit the pattern into something that looked like UART.

The first couple of bytes kind of matched:

This looks a bit like a 7-O-1 (7-bits, Odd parity, 1 end bit), but it fails when I hit the interesting data.

Reverting back to looking at a a high pulse to indicate a start, followed by 8-bits, a parity bit and a single low to indicate the end, it actually works...

The byte sequence looks like this:

0x00 0xA0 0x00 Byte0 Byte1 0xA0 0x01 0xA0

Now THAT is interesting.

So, new hypothesis: 0xA0 acts like some sort of frame boundary - and if you look closely at the data bytes, bit 7 is always low in the first byte, and bit 5 is always low in the second byte, meaning it is impossible for 0x0A to appear in either of those bytes.
UPDATE: Fun fact: 0x0A is traditionally a line-feed character. Not sure what to do with that information yet...

What of the other numbers? I'm not sure yet.

So, some questions to answer:
1. Who is the master here? Does the outdoor unit spit numbers at the controller, then yield the line waiting for a command? Or does the controller ask the outdoor unit for it settings?
2. How does a slave fit in to this?
If the controller is not plugged in, it displays an error code, so it feels like it is listening for a boundary byte, but what happens after that? Is there a call/response?

Maybe I'll pull out the oscilloscope again over the weekend...
The protocol from the outdoor unit
Myles Eftos • 02/25/2017 at 05:28 • 2 comments
So, I think I've worked out the meaning of the bitstream coming from the outdoor unit!
On my day off, I took the unit of the wall, got me some coffee and setup shop in the hallway, oscilloscope in hand.
I must admit, I'm still getting used to using the oscilloscope and I'm sure there is a far better way to do what I'm trying to do, but I found that if I probe the RX pin on the CPU, with the 'scope set to single trigger mode and keep hitting the start button, I'd eventually align the waveform at the start of the cycle. After that I used the onscreen rulers to work out the gaps between the pulses. I then wrote them down in to this spreadsheet. I'd change a setting, take a new set of readings, and repeat until I had covered enough states that I could get a complete picture of what was going on.
Looking at the data, I could start to see some patterns.
1. The shortest spacing was around 2ms (some longer; some shorter)
2. The RX pin is idle low, and there is always a high transition to represent the start bit
3. There seems to be a low transition to represent a stop bit
4. There is 9 bits between the start and stop bit (except for the last set)
It's starting to look like a straight up serial transmission, except the idle state, start and stop bits are inverted, so unfortunately the built in serial protocol decoder wouldn't read it.
Next I need to find the bits that change between each state.
The power bit was pretty obvious: there was only one bit that was different when the power was off - the 68th bit.
Looking at the rest of that byte, there was a pattern developing in the next 3 bits - they seemed to change when the settings changed. Taking LSB first, Fan only mode is represented by 0x01, Humidity mode (Yeah - I don't know what that is either) is 0x02, Cool mode is 0x03, Heat mode is 0x04 and Auto mode is 0x05. The next three bits represent the fan speed: Auto 0x00, Speed 2: 0x02, Speed 3: 0x03, Speed 4: 0x04. But was was the ninth bit?
Having a think about serial, it's could a parity bit. By summing the number of bits, it became pretty obvious it was odd parity. I checked this against the other bytes, and it checked out - now we are getting somewhere!
Looking at the next byte, it was clear it was changing with the temperature. I purposely looked at the lowest possible setting for the temperature (15deg) and the highest (30deg) and it was here I was lead down the garden path a little. Reading up on other people's efforts at reverse engineering air conditioner units, this is a fairly common range. Many of the IR transmitters represent this as a 4 bit number, where 0x0 is 15 and 0xF 30. Unfortunately, I couldn't for the life of me work out how that mapped to the numbers I was seeing.
It turns out, this system uses a 5 bit number - feasibly being able to represent 0 - 31 degrees. Bits 6 and 7 are always 0, and bit 8 is the "economy" settings.
There is four unknown bytes, and one block that seems to be make up of 5 bytes. My guess is one of the unknown bytes is reserved for errors, and one is a serial number of some sort. I have no clue what the other two could be for, and I'm quite confused by the last, short byte.
But this is definitely progress!
I did a final check the get some timing on what is transmitted, and there seems to be three windows of roughly 212ms each. The first from the outdoor unit, the second transmitted by the remote control, and I'm guessing the third is for a slave unit.
To build a test harness, I'll need to bit-bang the data for 212ms, then set the line to high impedance for 424ms. This will hopefully allow me to get the remote control to work on my bench. Once I can get the remote to work, I can analyse what it is doing. Next, I'll simulate that as well, then set the remote to slave mode and work out that part of the protocol. Once I have the three parts of the protocol nutted out, I can just simulate the outdoor unit, connect the spare remote controller as master, and the microcontroller will become the slave. Easy!
Baseline communication
Myles Eftos • 01/16/2017 at 22:03 • 0 comments

I took the remote unit off the wall again, and this time removed the signal wire fro the remote and attached it to my Oscilloscope.
And this is signal that comes from the outdoor unit.
I'm not sure if I stuffed up my reading the last time, but it looks like the pulse width is 2ms.
Really, I needed to replay this and see if I could get my test unit to initialise. I thought about using an Ardiuno, so I googled bit banging serial to see the best way to do it. One of the results that caught my eye was another Hackaday article entitled "Introduction to FTDI bitbang mode". I had literally just cleaned up my workbench and found a FTDI module. Perfect!
I knocked up a little circuit that drove a transistor from 0V to 12V, and adapted the code from the article to control the FTDI modules CTS line. I had to reduce the sleep time to 1.8ms to adjust for kernel context switches (I'm guessing) while talking to the adapter. I got it pretty close to 2ms though.
I wired it up to the controller, and got one step closer - now instead of timing out and flashing C0 12, it just sits flashing "9C" forever.
My guess? This communication protocol works on one-wire - I'm not releasing the line, so the remote never gets a chance to send a response. It looks like I'll need some sort of tri-state buffer, so I can set the line to high-impedance after I've sent the preamble.
I was curious to see if I could get any other clues to the protocol, so I started poking around the big chip on the PCB. One of the pins receives the same signal the signal line does, except it's inveted and 0-5V! I went and looked up the chip (it's a UPD78F0393 from NEC - I'm so glad the remote manufacture labelled all their chips nicely), and that pin (#75) is labelled RXD0. That sounds like a serial receive line to me!
Pin 76 is labelled TXD0, which I'm guessing is the transmit line. This should make decoding stuff way easier, because I'll be able to see what is actually being transmitted and received separately. Win!
I'm going to try and trace out the front-end to this - so far I see a NJM2904 (an op-amp) is on the path - my guess is that is the thing inverting the signal and driving it to 12V. Tracing this circuit out should allow me to build a compatible circuit from my microcontroller.
A test unit arrives
Myles Eftos • 01/16/2017 at 21:32 • 0 comments

So my test unit arrived!
I get it on my bench, and test out my theory - if I'm right, it should boot up and start sending commands when the buttons are pressed.
I was wrong.
The unit just sits there flashing "9C" for a couple of minutes, then failing over to a "C0 12" error. The Oscilloscope was no use either - I just saw a constant 12V on the signal wire.
Hmmm.
Looks like I'll have to pull off the real wall unit.
Using some wire and alligator clips, I extended the wires so I could reach them with the scope.
This time I got somewhere - I could see a signal!
The pulse width is around 1.04ms, going from 12V to 0V. Weird.
I go distracted for a while trying to decode the protocol - is there start bits and stop bits? What about a parity bit?
I knocked together a quick D3 script (I'm a web developer, remember - I use web technology for a lot of this stuff because that is what I'm used to) to display the wave form. First, I wrote a ruby script that created a CSV file of just the transitions. There are two entries for each transition - a 0V and 12V value - so the graph ends up looking like a binary stream.
I then wrote another script that aligned the stream so each pulse was exactly 1.04, and each pulse hight was 12V or 0v. Finally, I scaled everything so the pulse width was 1, as this made reading the graphs easier.
I ended up with some pretty graphs like this:
There was still a problem though - I didn't have a baseline for the communications.
I knew that the control unit didn't send any data unless it was connected to the outside unit. I also knew that changing the temperature changed some of the bits in the data stream, so clearly there was some half-duplex serial communication going on. I needed to find out what the outdoor unit sent to initialise the control unit...
How does this thing work?
Myles Eftos • 01/16/2017 at 21:08 • 0 comments

I've never done any reverse engineering before, but spurred on by this recent Hackaday article, and this article I found I thought I'd give is a crack.
The first issue: I had no idea what the model number was - it's not written on the unit, nor on the instruction manual. So I just googled for Fujitsu airconditioner remote, hit image results and looked for one that looked the same. Once I found it and clicked through to the source page, I found out that it is a UTB-YUB/GUB/TUB (There are three model numbers depending on where in the world you are).
I found a supplier on ebay (who was actually Melbourne based), who had a new remote unit for $60, which I bought as I wanted a test unit on my workbench - mainly because trying to test things using the unit on the wall would be really annoying.
While I waited for it to arrive, I continued googling to find as much info as I could about it. Thankfully, a number of airconditioning repair places have their installation manuals online. Reading though the them, it was clear there was a three wires that connect the remote to the outdoor unit - +12V, GND and a signal.
Bingo.
Now, I need to work out what this signal wire does.
My first hypothesis was the remote unit worked a lot like an IR remote - every button press sent the complete state to the outdoor unit. If this was the case, it should just be a matter of hooking up a DSO (I have the LabNation SmartScope), copying the signal and replaying it via a microcontroller.
While I could pull the one off the wall, I patiently waited for my test unit to arrive.

View all 6 project logs

Discussions

RG wrote 07/30/2021 at 14:21

I've managed to get @jaroslawprzybylowicz code working with the 1-wire protocol, and ported to an Arduino lib if anyone is interested - https://github.com/unreality/FujiHeatPump

The wired remotes just need a LIN transceiver to split the signal wire into RX/TX.

Are you sure? yes | no

ShaneCluning wrote 08/03/2021 at 11:57

Hey RG, i'm not really familiar with using a LIN transceiver, i've mocked up a very rough wiring diagram with an Arduino uno (https://imgur.com/k6mM6Wk). Most of the pins seem to be straight forward, I'm just not sure on the CS/LWAKE pin or the VREG pin. Are either of these required?

Are you sure? yes | no

RG wrote 09/02/2021 at 04:44

There is an example circuit here: https://github.com/unreality/FujiHK for connecting to an ESP32, or
https://github.com/unreality/FujiHeatPump/raw/master/fujiheatpump-example.png

Are you sure? yes | no

Chema wrote 3 days ago

Hello

First of all, thank you for this work, it is something that I have been looking for for a long time to be able to integrate one aircon in a home automation installation.

I have followed the steps to do it on an esp32, but I have found a problem that will surely be related to the connection of the slave.

Could you explain in detail how you have connected the system to the air conditioning?Following the instructions, the aircon shows an EE: 1C error (Outdoor unit computer communication error) and the main control is disconnected by turning off the aircon.

Is there a connection / power-up sequence for both the aircon and the esp32 so that it is detected as a slave without problems?

Thanks for the help

Are you sure? yes | no

aleksander wrote 04/12/2021 at 22:07

My heatpump does not have the communication kit for wired remote installed.
Looking at a manual that shows a diagram for several of the communication-pcb that is used for the wired remote, I think it would be possible to connect directly to the main board.
This would give rx/tx serial istead of the one wire remote-controller bus.
Link to manual page that shows one of the com-pcb variants.

https://www.manualslib.com/manual/940046/General-Aohg14lac2.html?page=22#manual

Are you sure? yes | no

jaroslawprzybylowicz wrote 09/27/2020 at 16:06

I've reverse engineered similar protocol for Fuji Electric AC Unit (RSGxxLUCA) using UTY-RNNXM wired controller, you can take a look at the source code at https://github.com/jaroslawprzybylowicz/fuji-iot and compare if goldens from the unit tests fit communication you captured.

Are you sure? yes | no

Eddi wrote 10/13/2020 at 20:09

I've connected to my unit a saleae clone and i've captured the traffic. What i captured at 476bit/s seems inverted however by negating it I can find what Myles dumped. and is simlar to your master frame. I've seen you configured in you code 500bps. GREAT WORK!

That wired remote supports a slave device...it could be interesting to make your device a slave one to make master and wifi to cohexists

From the manual:

6.2. Dual remote control

•Depending on the model, some indoor units cannot be
connected for dual remote controllers. (Option is not
available for U.S.A. wall mounted type indoor unit.)
•2 separate remote controllers can be used to operate the
indoor units.
•The timer and self-diagnosis functions cannot be used on the slave

dip switch 1 pos2 on =slave

It would be nice to port your work to arduino

Are you sure? yes | no

jaroslawprzybylowicz wrote 10/14/2020 at 09:51

I remember from observing oscilloscope traces that single communication cycle is actually long enough to fit 3 8-byte frames. In my case, only two 8-byte frames were used, but there was "silence" on the wires for at least one more frame. It's likely this is the space needed for the slave controller you are referring to.

Also, the manual says you only need to flip dip switch on the slave, likely suggesting other communication is not affected by this.

As for the arduino, I don't have one unfortunately, but the procotol itself should be easily portable, the only part of my code that is linux specific is "controller" folder where interfacing with TTY, gRPC and threads is being done.

Are you sure? yes | no

jaroslawprzybylowicz wrote 10/14/2020 at 19:33

It would be nice if someone could reliably capture a couple of frames. We can then write a test to see if my software produces correct responses. Everything one needs is here:

https://github.com/jaroslawprzybylowicz/fuji-iot/blob/master/protocol/fuji_ac_protocol_handler_test.cc

As for interfacing, I also needed to invert the signal, this is what T1/T2 is for in

https://github.com/jaroslawprzybylowicz/fuji-iot/blob/master/hardware/schematic.png

Unfortunately, this won't solve the 3-wire <-> UART conversion problem that both you and Myles ran into AFAIU. You will either need that Serial Bus trasceiver Myles mentioned in the last entry, or alternatively you can disassemble the AC unit and hook into the system before the conversion happens. In my case I ignored UTY-XCBXZ1/UTY-TWBXF (I didn't even have one) and hooked directly into Wired In/Wired out in CN301 per https://www.manualslib.com/manual/1239980/Fujitsu-Aoyg30lat4.html?page=36#manual

Are you sure? yes | no

albert.klausen wrote 08/18/2020 at 16:22

Hello,

Nice to see somebody else is looking into this as well.

don't know i you have seen the unit from KXN (intesis). it maybe you can find something useful from it. At least it is a big list for command in the bottom of the user manual pdf

https://intesis.com/products/ac-interfaces/fujitsu-gateways/fujitsu-knx-inputs-vrf-fj-rc-knx-1i

https://cdn.hms-networks.com/docs/librariesprovider11/manuals-design-guides/user-manuals/ac-interfaces/user-manual-inknxfgl001r000.pdf?sfvrsn=153750d7_14

Are you sure? yes | no

Eddi wrote 08/19/2020 at 19:12

These are command to the kind interface. We don't need it, sorry

Are you sure? yes | no

Janus Hansen wrote 08/16/2020 at 07:40

I'm not sure if this can be useful to you; but did you see this post:

https://stackoverflow.com/questions/48531654/fujitsu-ir-remote-checksum-calculation

Are you sure? yes | no

Eddi wrote 08/16/2020 at 19:16

Useful link but not sure the protocol is the same, yet.

Are you sure? yes | no

Sergio wrote 08/12/2020 at 22:00

Hi!

I just wanted to let you know there is an official accessory which is a gateway from the Fujitsu protocol to modbus, you can find it in the fujistu-general website, the partnumber is FJ-RC-MBS-1. Modbus is quite open and you have command line tools to communicate. I just installed that gateway in my home and works fine. Anyway, you should check the compatibility between your indoor unit and the gateway.

If you still want to reverse engineer the protocol, check out the manuals of the device, they provide the register information, not sure if it will be in the same order, but at least you will know which information is available on the bus.

Also note that based on the manuals it seems there are at least two different variants to the Fujitsu bus (they call them type A and type B).

https://www.fujitsu-general.com/g-eu/products/split/optionalparts.html

I was already using modbus for another device at home, but it seems they have other connectivity options

Are you sure? yes | no

Myles Eftos wrote 08/12/2020 at 22:40

Thanks for the message! Great find. The FJ-RC-MBS-1 is from Intesis: they also do a WiFi box that I know works (one of my friends has one). They are around $AU300, which I'm kind of contemplating, given how little time I have at the moment. That said, I've started reading up on all this again, and have ordered some parts today, so hopefully I can find some time this weekend to look again.

Are you sure? yes | no

Eddi wrote 08/13/2020 at 06:42

I have 2 wired split and one with it remote.

FJ-RC-MBS-1 costs ~200€ (100€ used)

FJ-RC-WIFI-1 costs ~300£...

Too much bucks to upgrade all my devices..

By DIY it at home with 1/10 of the expense we get something similar.

Are you sure? yes | no

Eddi wrote 08/02/2020 at 20:14

Hi,

Not checked yet... But following use 12v, 3 wire like our

https://github.com/ahuxtable/LG_Aircon_MQTT_interface

https://www.instructables.com/id/Hacking-an-LG-Ducted-Split-for-Home-Automation/

https://www.eevblog.com/forum/projects/where-to-start-trying-to-decode-a-data-stream/

Could you give a look if something may be reused?

I would say the protocol is the same... they have an a8, we have a 0xa0 (probably reversed nibbles)

It should be interesting to sniff a longer communication. If the protocol would be the same, from your dumps we have half message. It seems is missing the CRC.

Are you sure? yes | no

Myles Eftos wrote 08/12/2020 at 22:42

That EEVblog post has the hardware I need, I'm pretty sure. I've ordered the LM393 comparators, and I'll hack together a circuit. Then I think I can try and adapt that code (though, I think it is different). Great find!

Are you sure? yes | no

Eddi wrote 08/13/2020 at 07:30

Try to fill up again your excel by swapping the nibbles... 0x0A will be his 0xA0 :-).. it seems

If you look at LG waveform, the checksum waveform is similar to start byte. So if we have such checksum may be confused with the start of another packet (that's why I asked you if you have a longer waveform).

LG full period is 1.2 seconds your sampled period is 600ms...

I've ordered the comparator from Ali.. I already own some opto.

About the GitHub link:

"The code is based on using an Arduino Uno with Wiznet shield. There is no reason that this could not be done via serial with a Pro mini etc but it will not work with an ESP8266 as is. The ESP8266 will not allow for serial speeds low enough. However, it is possible that you could use a pro mini for the AC interface and i2C to an ESP8266 to still make it wireless"

You agree with this?

Why esp8266 wouldn't be able to work at such baud rate (104bps)?

Maybe it trigger the watchdog?

Are you sure? yes | no

Myles Eftos wrote 08/13/2020 at 11:25

Not sure about the e8266, but it looks unlikely for the 32 https://www.esp32.com/viewtopic.php?t=1476&p=7087&hilit=uart+break Though bit-banging that speed would be fine

Are you sure? yes | no

Eddi wrote 08/13/2020 at 11:47

I think they are speaking about the uart... But with software serial?

With software serial the issue is high baud rate...

I'll try to ask to softwareserial guys

I've seen a couple of issues with baud rate lower then 300..

https://github.com/plerup/espsoftwareserial/issues/30

Maybe some delay may help

Are you sure? yes | no

Myles Eftos wrote 08/13/2020 at 12:11

Just looking at the source of SoftwareSerial, and it would seem so.

Are you sure? yes | no

Eddi wrote 10/10/2020 at 13:16

I've got some logic level adapter and hooked an arduino nano to esp8266...

then i've compiled two swserial example... it seems that they can speak each other until 1200bps...

then i hooked togeather two esp8266 both runnign swsertest.ino with plerup/espsoftwareserial library and they can communicate at 104 bps...

i think i could try start testing with esp8266

I did a quick test... i've modified the lg aircon source to dump what i receive from the bus, connected just the rx pin to an arduino nano, so no trasmission yet....

I don't see any byte on my serial interface and sometime the wired controller show error... i have just to disconnect the data cable to make it to resume from error. :-(

Are you sure? yes | no

arko36 wrote 07/02/2020 at 11:33

Just got the control out off the wall and put the scope in the white wire, seams that this is a two way communication with the indoor unit. Therefore I see this very difficult to manage it with the ESP8266. I realized cause I saw the EE:EE error message in the screen so there should be a proprietary protocol that also can control the remote MCU. I also see the remote has Zones, which makes me think that there is a paring between the two devices. I will also research about the RS485 adapter, I think it will be quicker approach as it will come with some "instructions"

Hacking the protocol means to hook the scope with the remote installed and map every action reaction data. Right ?

Are you sure? yes | no

Myles Eftos wrote 08/12/2020 at 22:43

You can have a master-slave setup - if the ESP can act as a slave, it should be fine. I have a second head unit, so I'm going to wire it up over the weekend as a slave and see if I can sniff what it sends.

Are you sure? yes | no

Jacob wrote 06/23/2020 at 14:15

This is really a very nice effort. Most of the work is done.

But I think the control bus that connects the remote control to the indoor unit is different from the one that connects the indoor unit to the outdoor unit.
In other words, we still unable to directly control the outdoor unit.

Are you sure? yes | no

Myles Eftos wrote 08/12/2020 at 22:44

I think this is ok - If we can simulate a slave control unit we only need to control the indoor unit

Are you sure? yes | no

jose.aparici wrote 03/24/2020 at 23:11

any progress in the project, I am interested in it. I am investigating on my own.
Greetings ..

Are you sure? yes | no

Trueman wrote 05/30/2018 at 16:37

It's a great job of Reverse Engineering

I have a very similar device but the communication parameters are 500 Baud, 1 Start bit, 8 Bit of data, Even Parity, 1 Stop Bit.

At the moment I am developing the software for Arduino and I am going to adapt a circuit of a Lin interface for cars.

Are you sure? yes | no

Glen Ogilvie wrote 02/12/2018 at 22:16

Any update on this project? I'm about to buy an air conditioning unit (ducted) and want to be able to control it from a raspberry pi / esp8266 / esp32.

Are you sure? yes | no

Myles Eftos wrote 08/12/2020 at 22:45

It's been slow going, but it's beginning to pique my interest again. I may have some more time shortly to start looking again, and I've made some additional discoveries that are interesting.

Are you sure? yes | no

Neil wrote 02/08/2018 at 05:23

I've got a similarish unit and have discovered the CoolLink range of adapters to communicate with them. Not sure of cost at the moment.

Interestingly, in the documentation for their latest units:

https://coolautomation.com/lib/doc/quickstart/Quick-Installation-Guide-CoolMasterNet-v1.5-EN-WEB.pdf

It mentions the interface to Fujitsu heaters is through a Echelon U10 interface, which is LONWorks. I can't find many reference to LONWorks with Fujitsu, except using the "network converter", so not quite sure how this works.

I have an RS485 adapter too, so I could also see if that picks up anything on the remote connection...

Are you sure? yes | no

James wrote 01/26/2018 at 06:29

The documentation from Intesis interface used by @Beau McMurray contains details of the error codes - which could be very handy. What are the chances that the other details of the modbus protocol/registers in the document are 1:1 with the addresses of the Fujitsu native serial commands?

Documentation here:

https://www.intesisbox.com/intesis/product/media/intesisbox_fj-rc-mbs-1_user_manual_en.pdf

Are you sure? yes | no

Beau McMurray wrote 01/24/2018 at 08:27

@johntamplin @Myles Eftos Not sure if you had much success with this, however I can confirm the Intesis Modbus unit (FJ-RC-MBS-1) works beautifully as an interface with Fujitsu systems using this remote control.

I'm controlling mine now via a Raspberry Pi using Node-RED, with plans to turn it into a fully automated zoned system.

Are you sure? yes | no

Myles Eftos wrote 01/24/2018 at 10:24

interesting! According to my 20 second google is uses RS485 for the bus. How much was it and where did you get yours?

Are you sure? yes | no

Beau McMurray wrote 01/28/2018 at 12:59

It cost me $396AUD including shipping from IvoryEgg. Worth every cent IMO for the ease of use. Got it up and running in no time!

Are you sure? yes | no

Myles Eftos wrote 01/24/2018 at 10:30

ah. This converts their protocol into RS485.

Are you sure? yes | no

Beau McMurray wrote 01/28/2018 at 13:00

Correct.

Are you sure? yes | no

Glen Ogilvie wrote 02/12/2018 at 22:19

Hi Beau,

Could you provide a few more details as to how you have your raspberry pi talking to the FJ-RC-MBS-1 ?

Did you get a modbus shield for the raspberry pi?
wondering if this is the way to go, or if we are so close we can control these units without it?

Can you share the code you are using to talk to the modbus interface?

Regards

Glen Ogilvie

Are you sure? yes | no

johancoppens wrote 01/22/2018 at 12:09

Have you succeeded in a working installation? I want to control the heaters installed at our school from an arduino. Can you confirm that it is LIN protocol? I have ordered a MCP2025 to test it with an arduino. We will see what the results will be

Are you sure? yes | no

Myles Eftos wrote 01/24/2018 at 10:26

it’s been suggested it might be RS485. I will try and find an interface and see if that does the trick

Are you sure? yes | no

Andrius wrote 12/27/2017 at 10:06

Subscribed. My house is heated/cooled by similar 10kW Fujitsu-General duct unit and I'm looking for it's better automation than gives this legacy control panel, a something IP based control. Are you aware that this wired unit might be replaced with IR control? And that IR unit might be controlled by on the market avialable universal IR/wifi/home automation devices? IR device part number is UTY-LRH. Also worth mentioning and it might be helpfull searching for information that the same AC/heat pump units manufactured by Fujitsu were sold under multiple brand names- Fujitsu, Fujitsu-General anf Fuji Electric and might be even more.

The unit might be controlled by multiple remote controls- wired and IR on the same wire.

Are you sure? yes | no

adam.pang wrote 10/25/2017 at 07:04

Hi @Myles Eftos, it's good to know you are doing a similar project as mine. I am also using ESP8266. I wished to control my office aircon through IR technology but I noticed it's actually using a wired remote control. Have you succeeded? Would like to hear from you soon if you have figured it out....

Are you sure? yes | no

bullety.hasor wrote 08/16/2017 at 17:48

Really good work @Myles Eftos !!! Here another person interested in your project. I've same unit at home and I'd like to control it with ESP8266. Any new clue about protocol involved in communication? Maybe LIN protocol as @Eddi suggested? Thank for your time publishing the project here.

Are you sure? yes | no

johntamplin wrote 07/25/2017 at 08:40

This is EXACTLY what I've been trying to achieve; same unit, same damn Fujitsu unit. I did discover a KNX-based interface, but the costs involved there are prohibitive. How has progress been since your last post/log ?

Are you sure? yes | no

Reverse engineering a Fujitsu Air Conditioner Unit

Description

Details

Files

sequences.xlsx

Project Logs

Collapse

A hardware interface, maybe?

Let's have another look.

The protocol from the outdoor unit

Baseline communication

A test unit arrives

How does this thing work?

Discussions

Similar Projects

NextNet Wireless Antenna Breakdown

TeensyFlight36

74HCT6526

Beckman DU 600 Reverse Engineering

Reverse engineering a Fujitsu Air Conditioner Unit

Become a Hackaday.io member

Just one more thing

Description

Details

Files

Project Logs Collapse

Enjoy this project?

Discussions

Become a Hackaday.io Member

Similar Projects

Does this project spark your interest?

Report project as inappropriate

Send message

Remove Member

Project Logs

Collapse