Hi there.
First all many thanks @rabbit-aaron for this great work !
I had build my device and try to control my AC pump (in my case a old General duct split with a remote controller AR-3TA1 with 3 wires so similar to others that posted are working fine) and once fully assure the hardware are propperly tested and working I’m unable to make it work over ESP32 with ESPHome compiling from GitHub - rabbit-aaron/esphome-fujitsu downloaded source code.
I tested two ESP boards but stuck in boot loop with same error when trying to boot and finally boot in safe mode:
This is error are raised compiling with ESPHome version 2022.8.3:
I see in this treath @spokosjr had same error, but I not see if he solved his problem.
I tested single-core FujitsuHeatPump files and then it boot fine but with they cannot control the AC unit and remains “waiting frames” forever seems without success to sync over the LIN bus.
Really appreciate if anyone can help to sort out that issue.
Thank you.
First of all, thank you @rabbit-aaron for this great integration! Good thing I had another look around for a cheap solution before buying those expensive Intesis modules!
As many of you, just stumbled upon your project and now I can’t wait to get my hands on the electronic components to try it.
@xploss: thanks for the tip on the arrow.com website. However, I also live in Europe and can’t get past the VAT ID field when trying to complete an order. How did you manage to do it?
Hi.
I reply to myself some findings about this issue.
I have reviewed the possible cause of the problem that causes the ESP to restart when trying to start the vtask and it seems that in ESPHome they may have changed something in the core that prevents the task from executing with a priority higher than 1 and that causes wdt error.
Changing the vtask definition with priority to 1: “xTaskCreatePinnedToCore(serialTask, “FujiTask”,* *10000, (void *)this, 1, &(this->taskHandle), 1);” , I can run without no more wdt crashes.
Issue is now that still cannot control the AC pump. My main controller no show any error and the ESP is not updating values on the ESPHome climate and if I change some value the AC pump and the controller seems not reacting at all.
I enable print debug with #define DEBUG_FUJI (on “FujiHeatPump.cpp” file) I can see incoming frames (mSrc: mDst: mType: write: login: unknown: onOff: temp: mode: cP: uM: cTemp: acError:) changing quick to the ESP32 mainly with login 1 and 0 and values reflecting good the current system status and because that I think LIN bus seems are readed good from the ESP32 and I see that values on this frames are reflecting what is configured on my main controller and any change on the primary controller are propperly reflected on the frames received and printed, but this values are not udated on the ESPHome climate and if I try to change anything on the ESPHome climate control I can see the message ESPHome are triying change them, but no reaction from AC pump or main controller about this new value.
At this moment I want using this ESPHome module with local mode (AP mode, not connected to Home Assistant) with only the autogenerated ESPHome webpage with the climate control.
This is my yaml:
So still struggling to figure what are now the issue because hardware (ESP32, LIN transceiver, etc…) seems fime but still unable to make it working propperly.
I simply update all the information I have in case this can help someone in the future who suffers the same problems or doubts
I finally managed to get the module working.
In addition to the bootloop problem mentioned by the uart vtask statement, the problem is that my AC system had the main thermostat set to only one primary thermostat.
Changing the switch (in my case 1) in dual controller mode (primary+secondary) everything started to work. Bellow a pic. to configure my controller from Fujitsu Intallation doc:
Now all seems fine and ESPHome module are working (in my case in stand alone AP Mode without connection to mqtt or HA).
I have only noticed that in some moments the change orders are not “applied” and it seems that they are not received by the primary controller and/or the indoor unit does not recognize them and it is necessary to repeat (sometimes several times) the order until the system accepts the change.
Best wishes and hope all the best to all people in this new year.
Hello, I have the same problem as @spokosjr, I have reviewed what @jirm comments but I still have the same problems. I have not yet connected the esp32 with the MCP2025 to the air conditioning unit (I don’t know if that could be the problem). @jirm, I don’t have the same definition of vtask that you mention, could you copy and paste the code as you modified it? Has anyone else had the problem and found a solution? I would appreciate if someone help me to solve the problem. Thanks in advance.
Hi @revecas, I modified in the library file “FujitsuClimate.cpp” in the setup function the xTaskCreatePinnedToCore() statament changing only the priority parameter to 1, bellow I copy all the statement and you can see the value I changed:
Then I upload this modified file to my ESPHome folder and build the device.
I belive you can build and flash the ESPHome device and boot the ESP32 without error even though LIN transceiver (MCP2025) are not attached to it and only try the ESP32board, but I don´t understand what you want achieve with this and I don’t think either will be a good “test” because the device cannot initialize propperly the UART and receive/transmit anything from it.
If I can help to anything more don’t dubt to post here, and I try do my best.
I’ve finally managed to get some time to work on connecting my AC using your project and all the tips from the discussion. I figured I could share my experience. Spoiler alert: everything works!
To start with, I basically went with all the components suggested in the original post by @rabbit-aaron, except for the buck converter which I replaced by a 360 mini. It is way more compact, but the drawback in my opinion is the adjustable output tension through a quite sensitive screw. It was not easy to get to 5v and avoid hitting the screw too much in order not to change the setting.
It was my first prototype board ever. So it took me a long time planning the components positions and connections. Also I’m not that familiar with soldering, so I patiently did it thinking twice or thrice before maiing the connections! At the end, I ended up with a compact board of the same size of the esp32, which is nice. I’m pretty sure it could be even more compact and a design with pin connectors instead of direct soldering for the esp32 would be better, nevertheless, I’m satisfied with the result. Especially because it was small enough to be inserted in the wall cavity.
On the soft side, it was rather easy, although I must thank @jirm for his tip to modify the code: it worked like a charm.
In HA a simple climate card will do the trick in the interface. It is a two-way connection between the wall-mounted remote and HA, so everything is synchronized.
I would like to thank you all for this great project and for the information shared!
i’m new here and just found this conversation. The way i see it, this is about communicating with the old 3-wire remote-controller, is that correct? Fujitsu starts to switch to 2-wire remote controllers two years ago, is there already a BUS hack for that (2-wire)?
What I’ve done here is take their work and put it together with the ESPHome API. If anyone has decoded the new 2-wire protocol, I could help with building an ESPHome layer on top of it, but I wouldn’t be able to test them as I don’t have the 2-wire AC unit.
Hey jirm, I’m not too familiar with the ESPHome API nor the FreeRTOS API, what does priority 1 here mean?
I have tried something like this before, but when WiFi is flaky and sometimes the ESP32 missed a frame or something, and my master controller will report an error, I had to power cycle it.
Thus my decision to pin the serial task to the second core with the highest priority.
I’m thinking of using two chips, one to handle the serial and another just to handle communication with ESPHome/Home assistant.
Hi @rabbit-aaron, Yes I totally agree with you which is not a good solution because task priority 1 means the Serial task will be executed at lower priority lever and can be seriosly compromissed by other EspHome core processes and on certain circumstances maybe some frames can be lost and the ESP can go out of sync (bound) at the LIN bus.
But with actual EspHome version a task priority putting a upper level to 1 causes a bootloop to the ESP, so seems EspHome core tasks are not happy at all executing any other high priority task (I tried on both cores) that tries to run in parallel to the EspHome core processes.
I can only say that several days in test my ESP device had not lossing sync, so seems the device are enough stable at the moment. So mean while we cannot find a best solution to elevate the priority for the serial task that can affort the device can boot and keeps working with actual EspHome version at least with this workaround Esp devices can be build and running at the moment.
Found my loopback issue , just connect ESP32 to my fujitsu and voila everything boot well I was thinking only esp32 with program running without connect to Fujitsu will be ok for the first test on breadboard.
Order wrong LIN number but MCP2021-330E/P works well too
My Fujitsu Heatpump have Quiet mode (low low speed) for night that will be great add for the night but i’ll start with this and look around if possible to add.
Same trouble for me (looptask), did you find anything.
ELF file SHA256: 0000000000000000
Rebooting… ets Jul 29 2019 12:21:46
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0030,len:1184 load:0x40078000,len:13132 load:0x40080400,len:3036 entry 0x400805e4 [I][logger:258]: Log initialized [C][ota:469]: There have been 7 suspected unsuccessful boot attempts. [D][esp32.preferences:113]: Saving 1 preferences to flash… [D][esp32.preferences:142]: Saving 1 preferences to flash: 0 cached, 1 written, 0 failed [I][app:029]: Running through setup()… [D][fuji:028]: Fuji initialized [D][fuji:035]: starting task [D][fuji:010]: reached task [D][fuji:011]: serialTask started on core 1 E (10360) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time: E (10360) task_wdt: - loopTask (CPU 1) E (10360) task_wdt: Tasks currently running: E (10360) task_wdt: CPU 0: IDLE E (10360) task_wdt: CPU 1: FujiTask E (10360) task_wdt: Aborting.
Eventually after about a month of this error On and Off - the error is permanent and the outdoor unit is no longer communicating with the indoor = a very hot summer without the compressor working…
Had someone come around and diagnosed, replaced the outdoor unit PCB’s, so back in operation again.
As you had mentioned, the code is set to run as a slave and not a master controller - does this esp32 controller need to be wired in a daisy chained from the main master control panel(behind)?? Or can it be wired directly from the 3 terminals at the roof indoor unit where the master controller is wired to?
In theory, I don’t see any difference in either of the wiring options mentioned above, however fujitsu documentation suggests the slave controllers to be daisy chained to the main master controller(behind)…
I have wired the esp32 directly into the roof indoor unit, and after spending 2k to fix the outdoor unit pcb - I’m trying to find the cause.
Done Fujitsu ASU12RL AOU12RL
Wall remote UTY-RNBYU
Communication box kit UTY-XCBXE (need for 12RL maybe 9RL not included for add wall remote)
Lin transceiver, wrong # order but, MCP2021-330E/P works well
Amazon esp32 dev board 30pin
LM 2596 DC-DC convertor
Project install in a small box behind the wall in entry closet.
Only missing fan mode Quiet (slow speed) in home hassistant , Quiet fan mode support by IR or wall remote ?
Lin transceiver need to but connect with AC else ESP32 will enter in bootloop
For my wall remote (UTY-RNBYU) no need to swith DIP switch1 -2 for dual controller, in dual mode error ? single mode everything works without any error ?
nicely done! looks good!
Likely those in boot loop had some wiring issue with the LIN transceiver. Note that Tx connects to Tx and Rx connects to Rx, unlike the other UART connections.
There is a fix for the Economy mode, not sure if that’s what u mean by quiet mode. I’ll update the library later to attempt to support it.
And I plan on fixing the intermittent problems where settings might not work, and you have to send the control command several times.
Quiet is only slow fan speed perfect for the night.
Economy (operation) Mode probably refer for Eco mode see the photo for description.
I never use this Economy Operation Mode I install the wall keypad for got remote temperature sensor for better temperature control and for weekly timer but the timer is so dumb i stop use it.
I was thinking only esp32 with program running without connect to Fujitsu will be ok for the first test on breadboard.
I never use this Economy Operation Mode I install the wall keypad for got remote temperature sensor for better temperature control and for weekly timer but the timer is so dumb i stop use it.