I’m not sure, so I would try this by powering DC/DC converter only (not connected to aircon) from some power supply, if I did this. Then I would measure if the output voltage is 5V DC compared to GND and finally if everything as expected, connect it to aircon
If ESP GND is connected with aircon gnd (Vin) and there is no voltage between these GND pins, then everything should be ok.
Thanks for your answer, I tried it with an external power supply. 5v output is ok. Now Gnd from AC and esp32 are shared, I guess tr/tx data will be allright.
I flashed a Wemos Esp32 D1 Mini with FujitsuAC and connected 2 leds. I did not yet connect the esp32 to the AC. When I switch it on, both leds are on. The device is in AP mode then. When I enter credentials for WiFi and MQTT, I succeed in connecting both. But the state of the leds does not change, both stay on. What is see on the MQTT end, is that messages are send, about every second. (fujitsu/940db3f4e9d4/state/status Init1 Send
fujitsu/940db3f4e9d4/debug/send 00 00 00 00 04 00 00 00 00 FF FB) Does it behave like this because I did not connect it to the AC?
Hi. Sorry, I did not add circuit for leds to the repo yet.
They should be connected like that (they are optional, of course):
Resistor values depends on LED’s you are using
Thanks a lot for this project, want to report back that I was able to control my ducted unit with this project:
Unit PN:
Condenser AOYG14LUC (Outdoor)
Evaporator: ARYG14LSLAP (Indoor)
Remote: UTY-RLRY (2 Wire, connected to the unit and operational)
Connected to CN65 White connector (top of main board):
Pin1 (+12V)
Pin2 (GND)
Pin3 (AC TX Meaasured at 0V vs GND) → Level Shifter → ESP32 RX GPIO16
Pin4 (AC RX Meaasured at 5V vs GND) ← Level Shifter ← ESP32 TX GPIO17
All wiring per repo picture by author.
Import note:
I had this level shifter - SparkFun Link - Initially used the “resistor divider” based path for AC - RX - this didn’t work as expected - solution was to move both lines to the “bi-directional” path’s,
Here is the correct wiring with this level shifter, hope this will help someone:
It would be simpler, but this is OEM level solution. You get 2 way communication, so you are always sure that aircon received the command, you can see its reported temps and you get aircon state synced when something is changed by the remote controller.
Also you dont have to think where to place the blaster and how to get power for it. These dongles placed inside aircons in their dedicated slots.
Hi @Benas,
thanks for checking!
From the wall controller I was able to change the registers of the internal unit and set the wall controller thermometer as the default one.
How to interpret/map the request data frames you sent?
3 = command type (read)
0 0 0 - padding
14 - payload length in hex (= 20 in decimal, so there should be 10 addresses queried (each address consist of two bytes))
1 50 = 0x0150 (address)
1 51 = 0x0151 (address)
1 52 = 0x0152 (address)
...
...
FC 25 = checksum of the frame to validate data integrity
When you change wall controller thermometer to default, do you notice any register change in mqtt logs? I think it just enables internal logic in the wall controller to do setpoint temp adjustment, but of course its just a guess.
What registers were you able to change? Any additional which are in the current registry table but not named yet?