LG Therma V before 2019.

I have THERMA V, ODU - HU071MR.U44 and IDU - HN0916M.NK4. For some time I try to connect them to my HA server but without any result. That IDU have onboard modbus port and even two dip for control it's behaviour. But still without success. I found in some documents on LG site that version of IDU have some issues and modbus communication doesnt work with that. So I have some questions about Your project:

do You connect modbus directly to ODU or IDU?
what voltage do You use, because I'm using EW11a wifi converter supplied by 5V, because at PCB is described as 5V
in documentation that modbus is described as 9600-8N1 but it doesnt work at all as a MODBUS or LGAP

If You help me connect to my IDU or ODU i will try to help You to document LGAP protocol side.

With regards Nedyarrd

Thanks for reaching out! You have a couple of options for integration. If you want to interface with the ODU then this project is likely for you, if you want to integrate with an IDU, then check this project out: https://github.com/JanM321/esphome-lg-controller.

I've pulled up the installation manual (https://gscs-b2c.lge.com/downloadFile?fileId=4qXYBRCQT7VWO8sw2Pg) and it seems like you have the following options for integration:

There seems to be an onboard Modbus interface? at least it talks about it on a few pages. In the case where it may be possible to integrate with that interface, this video may be useful: https://www.youtube.com/embed/Xuj2YFZ5zME?si=3Ovf-9DifcNpapcV.
Page 125 suggests you can potentially integrate an LG PI-485 board with your ODU. The PI-485 board will present a Central Control/LGAP interface that we can use with the protocol work I've been doing. Long story short - this option should work with the code I've been writing, but does require to purchase the PI-485 board. I've seen them on ebay in the past. To be clear, I haven't done any testing with the PI-485 board yet, so I can't guarantee it will work yet. But the documentation does seem to suggest it.

It doesn't matter what type of unit will I use, main goal is to at beginning monitor whole heatpump. JanM321 is one things I want to try, but Your project is more interesting, because:

as You said I have RS485 interface onboard
as I found in hn0916m.nk4 there is a problem with Modbus RTU (reference needed - I found one on some site, but now I cant find it. It was on some LGE site chart, what is working on their boards and what is not).
- NK5 is model where Modbus is working.
- https://www.intechna.cz/fotky81432/funkce/LG-Therma-V-AWHP-R32-Split-PDB.pdf - only one reference I found - for modbus there is need for RTU (module?) (page 42) in PDF
- I think that CN_COM interface is a RS485 bus as it is stated in manual, but MODBUS function described on PCB is not working
- maybe that interface can be used as described by You but protocol can be slightly different, I think it can be extended version like in JanM321 13 byte protocol. But I can't get it to work
- I found that serviceman installed something like WiFi service stick to query information from ODU via something like RS485 for later service use.
- other thing is that communication between ODU and IDU is by one additional wire it looks like it is some kind of RS485 too, but with common A or B wire connected to ground (GND)

Here are some photos of my PCB's

20240304_205029 20240304_205020 20240301_213425 20240303_113603

So I have some questions:

I thoutght Your project is to connect directly to ODU omitting PI-485 board? Do I need PI-485 then?
it is possibile to run RS485 with 5V only? as it is seen on stickers on my PCB? Maybe that is my communication problem
I think that when Modbus function is broken on this board it is possible that RS485 interface in IDU speaks some of LGAP protocol

Some additional findings:

akb74855311 - display/controller uses that same protocol as described by JanM321
akb74855311 - is linux PCB with TI - AM3354BZCZ60 ARM Cortex A8 processor
have RS232 serial connector
it looks like whole IDU, ODU and display shares that same data across multiple busses so no matter where we try to connect to desired data, so still main goal is to reverse engineer LGAP protocol

Additional photos of display PCB. 20240304_213739 20240304_213929 20240304_213754 20240304_213459

Apologies for the delay in my response. This is a lot of great information you've collected here. The photos are especially interesting. Just coming back to your questions:

I thought Your project is to connect directly to ODU omitting PI-485 board? Do I need PI-485 then?

My project is supposed to work with any LGAP interface. In my particular case (Multi-V S), I have an LGAP interface on-board which is labelled as "Central Control A/B". I'll grab a photo of my PCB next time I open the unit. My understanding regarding the PI-485 board is where you have a unit that is older or doesn't have an RS485 interface, the PI-485 provides a bridge to these older devices. The PI-485 can speak both LGAP and non LGAP protocols depending on the DIP switches you select.

It is possible to run RS485 with 5V only? as it is seen on stickers on my PCB? Maybe that is my communication problem I think that when Modbus function is broken on this board it is possible that RS485 interface in IDU speaks some of LGAP protocol

I haven't measured the voltage on my central control pins yet. I will do this and let you know next time I open the unit.

I also noticed in your images that you have some wires attached to the 3rd party controller A/B terminals with a resistor across them. Was that installed by you or by the installer that you mentioned? I re-watched the youtube video I had linked earlier to check the label that's on his terminals and it actually matches the same as what you're seeing on yours. That does make me suspect that this is actually a modbus interface rather than LGAP especially given his unit was also a Therma V unit.

Just to be clear, are those the main integration pins you're observing? or are you also looking at some other pins as potentially carrying the LGAP signal?

To your point around IDUs also potentially using LGAP protocol, I do think you're right. There are also indoor specific SKUs of the PI-485 also.

No proble, spring is in way, so I have many work outside house ;-) I didn't look here either.

Apologies for the delay in my response. This is a lot of great information you've collected here. The photos are especially interesting. Just coming back to your questions:

I thought Your project is to connect directly to ODU omitting PI-485 board? Do I need PI-485 then?

My project is supposed to work with any LGAP interface. In my particular case (Multi-V S), I have an LGAP interface on-board which is labelled as "Central Control A/B". I'll grab a photo of my PCB next time I open the unit. My understanding regarding the PI-485 board is where you have a unit that is older or doesn't have an RS485 interface, the PI-485 provides a bridge to these older devices. The PI-485 can speak both LGAP and non LGAP protocols depending on the DIP switches you select.

It is possible to run RS485 with 5V only? as it is seen on stickers on my PCB? Maybe that is my communication problem I think that when Modbus function is broken on this board it is possible that RS485 interface in IDU speaks some of LGAP protocol

I haven't measured the voltage on my central control pins yet. I will do this and let you know next time I open the unit.

Yeah I attached wires to simply terminate RS485 line. It didn't helped anyway. I also noticed in your images that you have some wires attached to the 3rd party controller A/B terminals with a resistor across them. Was that installed by you or by the installer that you mentioned? I re-watched the youtube video I had linked earlier to check the label that's on his terminals and it actually matches the same as what you're seeing on yours. That does make me suspect that this is actually a modbus interface rather than LGAP especially given his unit was also a Therma V unit.

On dip switch there are two settings: 1st - master - slave 2nd - Exclusive/General (protocol selection)

That same connector is used for ie. Power meter interface.

I did try some other things with this connector, but I might have a RS485 problem. Because sometimes I have responses that I don't see. So at beginning:

I wrote python script to use my EW11A modbus/WiFi converter it does:

change baud rate
change parity/bits etc
send sequences of bytes:

I found that:

correct way to connect modbus is A->B B->A not A->A and B->B to have something.
controller at startup send pack of information at slow speed, it is slower than 300bps, because at 300bps it is 0xFF
any response from controller is not full real time, sometimes it takes some seconds, because after some combinations ie. 9600-8N1 4800-8N1 non typical settings like 2400 or 9600-8E2 - have some weird responses in about 23 bytes length. Sadly I don't know what is in response because EW11A filters them out :( And shows only statistics.

Just to be clear, are those the main integration pins you're observing? or are you also looking at some other pins as potentially carrying the LGAP signal?

Yep there are some more pins, that I think can be useful.

To your point around IDUs also potentially using LGAP protocol, I do think you're right. There are also indoor specific SKUs of the PI-485 also.

There's some interesting insights there. I've made some pretty significant progress since my last update too.

I found that a number of people were also having issues with the LILYGO T-RSC3 and the manufacturer has been silent on the subject. With that in mind I decided to try a different board M5Stack Atom Lite (which I had on-hand) and I added on ATOMIC RS485 Base.

This setup uses a different RS485 chip that doesn't require a flow control pin and the other nice thing is that it has 4 pins in a row - GND, 12V, A, B and can power the board using the 12V pin. That's perfect for my use case plugging into my outdoor unit as I have an internal 12V and GND pin right next to the central control pins.

After putting everything together, changing the target in esphome to use this the Atom Lite instead, the custom driver I wrote worked! I was able to send requests and get bytes back, decode the bytes and enable the Climate entities to show up within HA. I'm now working on optimising the driver as there are a couple of timing issues, but my main worry of comms is all resolved.

To your point about finding data at very slow speeds, JanM321's project speaks the wall controller protocol at 104bps, perhaps that's what you're seeing there?

jourdant / esphome-lgap

LG Therma V before 2019. #2