4-Way-Cassette closes vanes during operation

florianbrede-ayet commented 10 months ago

This is a very interesting bug which happened three times since we added vane control (but might be unrelated to the feature itself).

What happens

During operation - I suspect it happens during defrost cycles and maybe also during oil-return cycles the cassette seems to lose track of its vane positions. During defrost cycles, the vanes are shut for cold-draft prevention. After returning to operation, the vanes either keep shut or open and shut again.

This is the unit operating (obv. without much effect):

Notes:

ThinQ allows to control positions, but at fixed intervals (ESP32 send interval) it closes them again
It doesn't find the correct vane positions and pushes against the endstop longer than expected, before stopping at arbitrary positions
Swing mode works neither in ThinkQ nor ESP32
Turning the indoor unit off and on again seems to fix the issues
Manually opening the vanes by hand fixes it until the unit tries to reposition the vanes (cold draft for example)
I had a similar incident last year, when I tried to operate the cassette without PREMTB001 connected. Back then I used just the stock universal LG remote and the WIFI module. After installing PREMTB001, this has not occured again for over a year.

A wild guess is that this that the cassette has a firmware bug which is mitigated by wired controllers. I have the feeling but no proof that with the PREMTB001 connected, the cassette was moving the vanes from endstop to endstop regularly even outside of regular cold-draft cycles.

I'm continuing to monitor the behaviour with a camera to catch the exact moment the vanes shut.

Log

At 15:58:xx I made to adjustments to a single vane while observing the unit.
Between 16:59:52 and 17:03:18, defrost was active
At 17:19:xx I came back (because the room cooled down despite operation) and noticed all vanes were shut
I tried numerous times with the ESP32 and ThinQ to open the vanes again, in the end they stayed shut and I opened them by hand.

Logfile: https://gist.github.com/florianbrede-ayet/ac5afb42ddf7c0b21f0365854c11abba

drbugfinder commented 10 months ago

On my mini-splits I've never seen this. Furthermore, the vanes are in the upmost (but not closed) position during the de-icing.

JanM321 commented 10 months ago

On my mini-splits I've never seen this. Furthermore, the vanes are in the upmost (but not closed) position during the de-icing.

Same here.

It's still easy for me to connect my PREMTB001 to the laptop and send your cassette's C9/CA/CB messages, to see what messages the controller sends over time. Let me know if that's useful.

florianbrede-ayet commented 10 months ago

On my mini-splits I've never seen this. Furthermore, the vanes are in the upmost (but not closed) position during the de-icing.

Same here.

It's still easy for me to connect my PREMTB001 to the laptop and send your cassette's C9/CA/CB messages, to see what messages the controller sends over time. Let me know if that's useful.

Thanks, I will monitor it for a few more days and will send you the communication procotol if it happens again. I've also only experienced it with the cassette.

florianbrede-ayet commented 10 months ago

I've monitored this for a while now and it happens frequently, always after defrost [real defrost where the vanes are supposed to close for 10+ minutes, not oil return] and when building up heat again.

If unlucky, even a power cycle of the entire unit doesn't help.

What's worse, while the indoor unit is "stuck with closed vanes", the fan operates at SLOW mode only and changing the speed is impossible. I'd say it's locked in some kind of special mode, waiting for some condition to resolve.

After that, I reconnected the PREMTB001 and put the ESP32 in listening only.

When doing that, I noticed something interesting. PREMTB001 is sending AC frequently as you mentioned in protocol.md, however, for me the message seems to change based on the thermistor setting:

TH controller: AC.00.00.00.00.00.00.80.00.00.00.00.79
TH unit      : AC.00.00.00.00.00.00.00.00.00.00.00.F9

Do you think it's possible that the AC byte 7 instructs the indoor unit to change its cold-draft prevention mode (vaguely described as "Hot Start" in the service manuals):

Assuming it's using the activated room temperature thermistor instead of the heat exchanger thermistor, it would probably never open the vanes if using the controller temperature. It doesn't match the SVC description, but that wouldn't be the first discrepancy I encounter.

An indication might be that the indoor unit thermistors differ:

Wall Unit:

Cassette:

Anyway, I still have to run this for a while, switch the TH setting around a bit and see if the cassette operates normally with PREMTB001.

Here is the log:


PREMTB001 INITIAL COMMUNICATION (including thermistor update from controller to unit at 22:45:31 - seemingly resulting in AC message change):

[22:43:25][D][lg-controller:440]: received A8.41.00.00.00.00.11.00.40.00.80.00.EF (13)
[22:43:25][D][lg-controller:440]: received A8.41.00.00.00.00.11.04.40.00.80.00.EB (13)
[22:43:25][D][lg-controller:440]: received A8.41.00.00.00.00.11.04.40.00.80.00.EB (13)
[22:43:25][D][lg-controller:440]: received A8.41.00.00.00.00.11.04.40.00.80.00.EB (13)
[22:43:37][D][lg-controller:440]: received C8.29.00.00.00.00.07.1A.00.00.40.00.07 (13)
[22:43:37][D][lg-controller:440]: received C8.29.00.00.00.00.07.1A.00.00.00.00.47 (13)
[22:43:37][D][lg-controller:440]: received A8.43.00.00.00.00.13.04.00.00.04.00.53 (13)
[22:43:37][D][lg-controller:440]: received A8.43.00.00.00.00.13.04.00.00.04.00.53 (13)
[22:43:37][D][lg-controller:440]: received A8.43.00.00.00.00.13.04.00.00.04.00.53 (13)
[22:43:43][D][lg-controller:440]: received A8.43.00.00.00.00.13.04.00.00.04.00.53 (13)
[22:43:49][D][lg-controller:440]: received AC.00.00.00.00.00.00.80.00.00.00.00.79 (13)
[22:43:49][D][lg-controller:440]: received AC.00.00.00.00.00.00.80.00.00.00.00.79 (13)
[22:43:49][D][lg-controller:440]: received AC.00.00.00.00.00.00.80.00.00.00.00.79 (13)
[22:43:49][D][lg-controller:440]: received AC.00.00.00.00.00.00.80.00.00.00.00.79 (13)
[22:43:49][D][lg-controller:440]: received C9.B9.EB.3F.BB.30.20.84.F7.D7.C4.A3.25 (13)
[22:43:49][D][lg-controller:440]: received C9.B9.EB.3F.BB.30.20.84.F7.D7.C4.A3.25 (13)
[22:43:49][D][lg-controller:440]: received CA.00.00.00.00.00.00.42.23.00.F1.01.74 (13)
[22:43:55][D][lg-controller:440]: received CA.00.00.00.00.00.00.42.23.00.F1.01.74 (13)
[22:43:55][D][lg-controller:440]: received CB.80.20.77.76.00.00.00.01.01.40.00.CF (13)
[22:44:07][D][lg-controller:440]: received A8.42.00.00.00.00.13.03.00.00.04.00.51 (13)
[22:44:07][D][lg-controller:440]: received CB.00.20.77.76.00.00.00.01.01.40.00.4F (13)
[22:44:07][D][lg-controller:440]: received CD.00.A5.0A.20.04.00.00.00.00.00.00.F5 (13)
[22:44:07][D][lg-controller:440]: received CD.00.A5.0A.20.04.00.00.00.00.00.00.F5 (13)
[22:44:07][D][lg-controller:440]: received CE.00.00.00.00.CD.2E.A7.01.C2.20.02.00 (13)
[22:44:07][D][lg-controller:440]: received CE.00.00.00.00.CD.2E.A7.01.C2.20.02.00 (13)
[22:44:07][D][lg-controller:440]: received CE.10.00.00.00.00.00.00.00.00.00.00.8B (13)
[22:44:07][D][lg-controller:440]: received CE.10.00.00.00.00.00.00.00.00.00.00.8B (13)
[22:44:07][D][lg-controller:440]: received CE.11.00.00.00.00.00.00.00.00.00.00.8A (13)
[22:44:19][D][lg-controller:440]: received CE.11.00.00.00.00.00.00.00.00.00.00.8A (13)
[22:44:19][D][lg-controller:440]: received CE.12.00.00.00.00.00.00.00.00.00.00.B5 (13)
[22:44:19][D][lg-controller:440]: received CE.12.00.00.00.00.00.00.00.00.00.00.B5 (13)
[22:44:19][D][lg-controller:440]: received CE.14.18.01.00.00.00.00.00.00.00.00.AE (13)
[22:44:19][D][lg-controller:440]: received CE.14.18.01.00.00.00.00.00.00.00.00.AE (13)
[22:44:19][D][lg-controller:440]: received CE.15.00.00.00.00.00.00.00.00.00.00.B6 (13)
[22:44:19][D][lg-controller:440]: received CE.15.00.00.00.00.00.00.00.00.00.00.B6 (13)
[22:44:19][D][lg-controller:440]: received CE.80.00.0F.17.00.2A.74.00.00.00.00.47 (13)
[22:44:19][D][lg-controller:440]: received CE.80.00.0F.17.00.2A.74.00.00.00.00.47 (13)
[22:44:31][D][lg-controller:440]: received CE.F2.08.5A.4D.4E.57.30.37.47.54.52.3D (13)
[22:44:31][D][lg-controller:440]: received CE.F2.08.5A.4D.4E.57.30.37.47.54.52.3D (13)
[22:44:31][D][lg-controller:440]: received CE.F2.48.41.30.20.20.20.20.20.20.20.0C (13)
[22:44:31][D][lg-controller:440]: received CE.F2.48.41.30.20.20.20.20.20.20.20.0C (13)
[22:44:31][D][lg-controller:440]: received CE.F2.88.20.20.20.20.20.20.20.20.20.3D (13)
[22:44:31][D][lg-controller:440]: received CE.F2.88.20.20.20.20.20.20.20.20.20.3D (13)
[22:44:31][D][lg-controller:440]: received CE.F2.10.32.30.35.4B.43.4C.48.30.47.55 (13)
[22:44:31][D][lg-controller:440]: received CE.F2.10.32.30.35.4B.43.4C.48.30.47.55 (13)
[22:44:31][D][lg-controller:440]: received CE.F2.50.46.30.38.20.20.20.20.20.20.2B (13)
[22:44:49][D][lg-controller:440]: received CE.F2.50.46.30.38.20.20.20.20.20.20.2B (13)
[22:44:49][D][lg-controller:440]: received CE.F2.90.20.20.20.20.20.20.20.20.20.25 (13)
[22:44:49][D][lg-controller:440]: received CE.F2.90.20.20.20.20.20.20.20.20.20.25 (13)
[22:44:49][D][lg-controller:440]: received C8.42.00.00.00.00.13.56.00.00.00.00.26 (13)
[22:44:49][D][lg-controller:440]: received C8.42.00.00.00.00.13.56.00.00.00.00.26 (13)
[22:44:49][D][lg-controller:440]: received CE.20.00.00.00.00.00.00.00.00.00.00.BB (13)
[22:44:49][D][lg-controller:440]: received CE.20.00.00.00.00.00.00.00.00.00.00.BB (13)
[22:44:49][D][lg-controller:440]: received CE.21.00.00.00.00.00.00.00.00.00.00.BA (13)
[22:44:49][D][lg-controller:440]: received CE.21.00.00.00.00.00.00.00.00.00.00.BA (13)
[22:44:55][D][lg-controller:440]: received CE.22.00.00.00.00.00.00.00.00.00.00.A5 (13)
[22:44:55][D][lg-controller:440]: received CE.22.00.00.00.00.00.00.00.00.00.00.A5 (13)
[22:44:55][D][lg-controller:440]: received A8.43.00.00.00.00.15.03.00.00.04.00.52 (13)
[22:44:55][D][lg-controller:440]: received A8.43.00.00.00.00.15.03.00.00.04.00.52 (13)
[22:44:55][D][lg-controller:440]: received AC.00.00.00.00.00.00.80.00.00.00.00.79 (13)
[22:44:55][D][lg-controller:440]: received AC.00.00.00.00.00.00.80.00.00.00.00.79 (13)
[22:45:07][D][lg-controller:440]: received A8.42.00.00.00.00.15.03.00.00.04.00.53 (13)
[22:45:07][D][lg-controller:440]: received A8.42.00.00.00.00.15.03.00.00.04.00.53 (13)
[22:45:07][D][lg-controller:440]: received AC.00.00.00.00.00.00.00.00.00.00.00.F9 (13)
[22:45:07][D][lg-controller:440]: received AC.00.00.00.00.00.00.00.00.00.00.00.F9 (13)
[22:45:31][D][lg-controller:440]: received A8.42.00.00.00.00.03.43.00.00.00.00.65 (13)
[22:45:31][D][lg-controller:440]: received A8.42.00.00.00.00.03.43.00.00.00.00.65 (13)
[22:45:31][D][lg-controller:440]: received AC.00.00.00.00.00.00.00.00.00.00.00.F9 (13)
[22:45:31][D][lg-controller:440]: received AC.00.00.00.00.00.00.00.00.00.00.00.F9 (13)
[22:45:31][D][lg-controller:440]: received C8.42.00.00.00.04.03.53.00.00.00.00.31 (13)
[22:45:31][D][lg-controller:440]: received C8.42.00.00.00.04.03.53.00.00.00.00.31 (13)
[22:45:37][D][lg-controller:440]: received C8.42.00.00.00.04.03.53.00.00.00.00.31 (13)

PREMTB001 CONTINOUS OPERATION WITH TH 0 (UNIT):

[23:51:17][D][lg-controller:440]: received A8.32.00.00.40.04.0B.80.00.00.00.00.FC (13)
[23:51:23][D][lg-controller:440]: received A8.32.00.00.40.04.0B.80.00.00.00.00.FC (13)
[23:51:23][D][lg-controller:440]: received AC.00.00.00.00.00.00.00.00.00.00.00.F9 (13)
[23:51:23][D][lg-controller:440]: received AC.00.00.00.00.00.00.00.00.00.00.00.F9 (13)
[23:51:41][D][lg-controller:440]: received A8.32.00.00.40.04.0B.80.00.00.00.00.FC (13)
[23:51:41][D][lg-controller:440]: received A8.32.00.00.40.04.0B.80.00.00.00.00.FC (13)
[23:51:41][D][lg-controller:440]: received AC.00.00.00.00.00.00.00.00.00.00.00.F9 (13)
[23:51:41][D][lg-controller:440]: received AC.00.00.00.00.00.00.00.00.00.00.00.F9 (13)
[23:51:59][D][lg-controller:440]: received A8.32.00.00.40.04.0B.80.00.00.00.00.FC (13)
[23:51:59][D][lg-controller:440]: received A8.32.00.00.40.04.0B.80.00.00.00.00.FC (13)
[23:52:05][D][lg-controller:440]: received AC.00.00.00.00.00.00.00.00.00.00.00.F9 (13)
[23:52:05][D][lg-controller:440]: received AC.00.00.00.00.00.00.00.00.00.00.00.F9 (13)
[23:52:23][D][lg-controller:440]: received A8.32.00.00.40.04.0B.80.00.00.00.00.FC (13)
[23:52:23][D][lg-controller:440]: received A8.32.00.00.40.04.0B.80.00.00.00.00.FC (13)
[23:52:23][D][lg-controller:440]: received AC.00.00.00.00.00.00.00.00.00.00.00.F9 (13)
[23:52:23][D][lg-controller:440]: received AC.00.00.00.00.00.00.00.00.00.00.00.F9 (13)
[23:52:41][D][lg-controller:440]: received A8.32.00.00.40.04.0B.80.00.00.00.00.FC (13)
[23:52:41][D][lg-controller:440]: received A8.32.00.00.40.04.0B.80.00.00.00.00.FC (13)
[23:52:47][D][lg-controller:440]: received AC.00.00.00.00.00.00.00.00.00.00.00.F9 (13)
[23:52:47][D][lg-controller:440]: received AC.00.00.00.00.00.00.00.00.00.00.00.F9 (13)
[23:53:05][D][lg-controller:440]: received A8.32.00.00.40.04.0B.80.00.00.00.00.FC (13)
[23:53:05][D][lg-controller:440]: received A8.32.00.00.40.04.0B.80.00.00.00.00.FC (13)
[23:53:05][D][lg-controller:440]: received AC.00.00.00.00.00.00.00.00.00.00.00.F9 (13)
[23:53:05][D][lg-controller:440]: received AC.00.00.00.00.00.00.00.00.00.00.00.F9 (13)
[23:53:23][D][lg-controller:440]: received A8.32.00.00.40.04.0B.80.00.00.00.00.FC (13)
[23:53:23][D][lg-controller:440]: received A8.32.00.00.40.04.0B.80.00.00.00.00.FC (13)
[23:53:29][D][lg-controller:440]: received AC.00.00.00.00.00.00.00.00.00.00.00.F9 (13)
[23:53:29][D][lg-controller:440]: received AC.00.00.00.00.00.00.00.00.00.00.00.F9 (13)
[23:53:47][D][lg-controller:440]: received A8.32.00.00.40.04.0B.80.00.00.00.00.FC (13)
[23:53:47][D][lg-controller:440]: received A8.32.00.00.40.04.0B.80.00.00.00.00.FC (13)
[23:53:47][D][lg-controller:440]: received AC.00.00.00.00.00.00.00.00.00.00.00.F9 (13)
[23:53:47][D][lg-controller:440]: received AC.00.00.00.00.00.00.00.00.00.00.00.F9 (13)
[23:54:05][D][lg-controller:440]: received A8.32.00.00.40.04.0B.80.00.00.00.00.FC (13)
[23:54:05][D][lg-controller:440]: received A8.32.00.00.40.04.0B.80.00.00.00.00.FC (13)
[23:54:11][D][lg-controller:440]: received AC.00.00.00.00.00.00.00.00.00.00.00.F9 (13)
[23:54:11][D][lg-controller:440]: received AC.00.00.00.00.00.00.00.00.00.00.00.F9 (13)

JanM321 commented 10 months ago

I think the controller sends an AC message with that bit set when a setting has changed (the A8 message that precedes it has the low bit of the second byte set). Does that match what you're seeing?

I even implemented this a while ago to see if it would make the unit send CC messages back, but with my units it didn't do anything as far as I could tell.

JanM321 commented 10 months ago

It would be interesting to catch this type of defrost with the LG controller. I wonder if it's sending/receiving something different at that point.

JanM321 commented 10 months ago

Oh I just noticed in your log file in the first message that your unit sends CC and CF messages. Does that happen regularly? Does the controller ever send AF messages?

florianbrede-ayet commented 10 months ago

You're right about AC, it's sent with 80 directly after a thermistor change (but not after sending AA for a vane update), otherwise it stays "empty":

[15:57:57][D][lg-controller:440]: received A8.93.00.00.40.04.08.87.00.00.00.00.5B (13)
[15:58:09][D][lg-controller:440]: received A8.93.00.00.40.04.08.87.00.00.00.00.5B (13)
[15:58:15][D][lg-controller:440]: received AC.00.00.00.00.00.00.80.00.00.00.00.79 (13)
[15:58:15][D][lg-controller:440]: received AC.00.00.00.00.00.00.80.00.00.00.00.79 (13)
[15:58:21][D][lg-controller:440]: received A8.92.00.00.40.04.08.87.00.00.00.00.58 (13)
[15:58:21][D][lg-controller:440]: received A8.92.00.00.40.04.08.87.00.00.00.00.58 (13)
[15:58:21][D][lg-controller:440]: received AC.00.00.00.00.00.00.00.00.00.00.00.F9 (13)
[15:58:21][D][lg-controller:440]: received AC.00.00.00.00.00.00.00.00.00.00.00.F9 (13)
[15:58:39][D][lg-controller:440]: received A8.92.00.00.40.04.08.87.00.00.00.00.58 (13)
[15:58:39][D][lg-controller:440]: received A8.92.00.00.40.04.08.87.00.00.00.00.58 (13)
[15:58:45][D][lg-controller:440]: received AC.00.00.00.00.00.00.00.00.00.00.00.F9 (13)
[15:58:45][D][lg-controller:440]: received AC.00.00.00.00.00.00.00.00.00.00.00.F9 (13)

Also, both of my units are sending CC and CF messages. For the Artcool, the messages are pretty empty, while the Cassette messages are rather interesting, especially CC bytes 6,7,9. This is the communication between PREMTB001 and the cassette in heating mode including an oil return at 15:18:45): https://gist.github.com/florianbrede-ayet/5cdbc84391b5a4db212f6aa10e030051

PREMTB001 does not send AF messages.

florianbrede-ayet commented 10 months ago

On a side note, do you have any idea why PREMTB is sending byte 10 80 in the handshake:

[16:45:21][D][lg-controller:440]: received A8.93.00.00.40.04.08.87.40.00.80.00.9B (13)

Log when connecting the controller to the running cassette: https://gist.github.com/florianbrede-ayet/afa20eab13d2904170f0d4a6968bfc1e

JanM321 commented 10 months ago

Also, both of my units are sending CC and CF messages.

Interesting. During normal operation my units only send C8 messages (and CA when I change settings).

I thought CC was a message type that's only used by older or single split units but apparently that's not true. I think it's mainly used to report information like power consumption, filter time, etc. Maybe that's why the controller just sends zeros for the most part.

Your cassette also sends a lot of CE messages. I guess they're using that second byte as extra message type because they didn't have more message types available. The message format is pretty weird.

On a side note, do you have any idea why PREMTB is sending byte 10 80 in the handshake:

I don't know. I've seen my PREMTB001 do this too and I've tried setting this bit myself, but the unit just clears it. It could be some kind of "we're initializing" state, but I'm not sure because there's already another flag for that (to request the settings). Maybe we should set this byte too to match the LG controller as much as possible.

JanM321 commented 10 months ago

@florianbrede-ayet I think I've noticed something a little similar with the thermistors: if indoor unit A is heating and indoor unit B is in pre-heating mode (because it reached its target temperature), then when using the internal thermistor, unit B will turn on its fan for at least a few minutes sometimes. I think to help spread the heat (because the unit also heats up a bit with a multi split). With the external thermistor I haven't seen this yet.

What's nice about the LG multi split units is that you can put one indoor unit in Heating mode and another on Fan and it will still be heating the room but using less power than when both units are set to heating. I created some automations in HA to put the bedroom unit in Fan mode when the outdoor unit turns on and the living room unit is in heating mode (and turn off when the outdoor unit turns off and it's in fan mode).

florianbrede-ayet commented 10 months ago

What's nice about the LG multi split units is that you can put one indoor unit in Heating mode and another on Fan and it will still be heating the room but using less power than when both units are set to heating.

I like how you're calling this a feature, I spent over a year trying to figure out why the Multi F would open powered-off unit EEVs slightly in heating mode :laughing:. But I've given up on that, I guess it's intentional because of pressure or capacity constraints - and it doesn't happen in cooling mode (where condensation might form).

JanM321 commented 9 months ago

I spent over a year trying to figure out why the Multi F would open powered-off unit EEVs slightly in heating mode 😆. But I've given up on that, I guess it's intentional because of pressure or capacity constraints - and it doesn't happen in cooling mode (where condensation might form).

Yes and some other brands are similar. I've heard the Heating + Fan trick also works with MHI multi-split units.

florianbrede-ayet commented 9 months ago

I wanted to give a short update:

PREMTB001 worked flawlessly in TH: Unit - I can't test TH: Controller anymore unfortunately (outside of thermal hull).
Adding the ESP32 and sending AC messages still reproduced the issue immediately
Disable sending AB and AA messages, flashing & power cycling reproduced the issue after the next real defrost
While the issue was present, I was able to immediately rectify the problem by switching to TH: Unit - the vanes opened promptly and the operation restarted

Log with vanes closing at 23:07:05 right after the defrost and opening at 23:35:30 after switching to TH: Unit: https://gist.github.com/florianbrede-ayet/86df08cdc0e951aec0d982f5cd0b1cd5

I'm now testing 2TH instead of Controller to see if it makes any difference. That has been my original PREMTB001 operation mode as well and I wonder if this masked the same issue I noticed over a year ago without ESP32.

EDIT: Just remembered that the Cassette always sends its unit thermistor temp.: C8.32.00.00.40.05.22.9F.00.00.00.00.55. What if in Controller mode, the unit needs a signal or its own temperature back in a different message to know when to open the vanes? This would make sense if the unit controller layout was similar to a duct type where you usually have externally operated vents.

Another thing I noticed is that my unit is sending two different CB messages:

[00:00:36][D][lg-controller:440]: received CB.00.08.4C.49.00.00.00.01.01.40.00.FF (13)
[00:00:36][D][lg-controller:440]: received CB.80.08.4B.49.00.00.00.01.01.40.00.7C (13)

PREMTB001 seems to always send AB.00 messages:

[16:26:54][D][lg-controller:440]: received AB.00.08.55.52.00.00.00.01.01.40.00.C9 (13)

However the ESP32 is occasionally sending AB.80 depending on the latest message received:

[06:36:25][D][lg-controller:432]: sending AB.80.20.55.52.00.00.00.01.01.40.00.61 (13)

JanM321 commented 9 months ago

The thermistor setting affecting this seems reasonable, but it's weird that you also saw the issue last year without any wired controller attached? Or is 2TH the default even then?

Just remembered that the Cassette always sends its unit thermistor temp.: C8.32.00.00.40.05.22.9F.00.00.00.00.55. What if in Controller mode, the unit needs a signal or its own temperature back in a different message to know when to open the vanes?

Interesting idea but so far we haven't seen anything like this in the PREMTB logs? If you have a list of messages I should try sending to the controller let me know.

florianbrede-ayet commented 9 months ago

I'm a bit out of ideas.

ESP32: 2TH also doesn't work
ESP32: Unit works fine
The indoor unit closes its vanes and refuses operation, if no A8 messages are received for about 240 seconds
The indoor unit cannot be operated over WIFI or IR if no wired remote is connected

I now have a log of the ESP32 and PREMTB001 both in TH:Controller and compared them. I hoped to find something significant, but the only difference I could spot are slight timing differences in the A8 messages (no other messages than the standard AC were sent from PREMTB001 during the defrost): https://gist.github.com/florianbrede-ayet/e7308ad8e5b6515430dc70d79d1a44be

JanM321 commented 9 months ago

I now have a log of the ESP32 and PREMTB001 both in TH:Controller and compared them. I hoped to find something significant, but the only difference I could spot are slight timing differences in the A8 messages (no other messages than the standard AC were sent from PREMTB001 during the defrost): https://gist.github.com/florianbrede-ayet/e7308ad8e5b6515430dc70d79d1a44be

Do you know why the PREMTB is sending a room temperature byte value of 0 which is <= 10 degrees (assuming that value is valid)? Was it very cold where the controller is? Seeing a value of 0 seems a bit suspicious.

A8.32.00.00.40.04.15.80.00.00.00.00.E6
                     ^^

florianbrede-ayet commented 9 months ago

Do you know why the PREMTB is sending a room temperature byte value of 0 which is <= 10 degrees (assuming that value is valid)?

Yes the controller is in the attic at an ambient temperature of ~0°C, so that's correct. The last thing I'm verifying now is if I can repeatedly switch the controllers without power cycling and get them to work / to fail.

By restricting the ESP32 to A8 and AC, I could prove that the only difference lies in these two messages (plus the handshake A8) or their timing.

JanM321 commented 9 months ago

Did you already change the handshake A8 to set that extra bit in byte 10 (I think) during initialization?

florianbrede-ayet commented 9 months ago

Did you already change the handshake A8 to set that extra bit in byte 10 (I think) during initialization?

Haven't tried that yet.

However, currently the ESP32 is going strong after over 6 defrosts - so it seems to be working now. What I did: 1.) Run unit with PREMTB001 and ESP32 in "Listen Only" mode 2.) Remove PREMTB001 3.) Wait 4 minutes until the unit shuts off 4.) Flash the standard ESP32 firmware but skip the initial AA and AB and make sure to only send A8 and CC messages 5.) Unit resumed automatically after receiving A8 messages

I thought I had this procedure covered already, but I might have made a mistake previously.

I also changed thermistor to Controller while testing, switched fan speeds and temperature - all worked fine. The prize question will be what breaks it:

Power cycle
AA
AB

florianbrede-ayet commented 9 months ago

I've discarded all of the ideas above, I'm relatively sure they are not responsible for the problem.

Right now I have two theories left that I am investigating:

a.) Centigrade precision

My unit supports centigrade precision, but it's not enabled.

It still seems to work fine, however PREMTB001 obeys the configuration and doesn't send centigrade A8 messages if not enabled:

[10:55:02][D][lg-controller:440]: received A8.41.00.00.00.00.01.00.40.00.80.00.FF (13)
[10:55:02][D][lg-controller:440]: received A8.41.00.00.00.00.01.0A.40.00.80.00.E1 (13)
[10:55:02][D][lg-controller:440]: received A8.41.00.00.00.00.01.0A.40.00.80.00.E1 (13)
[10:55:02][D][lg-controller:440]: received A8.41.00.00.00.00.01.0A.40.00.80.00.E1 (13)
[10:55:26][D][lg-controller:440]: received A8.32.00.00.40.04.0B.89.00.00.00.00.E7 (13)
[10:55:26][D][lg-controller:440]: received A8.32.00.00.40.04.0B.89.00.00.00.00.E7 (13)
[10:55:50][D][lg-controller:440]: received A8.32.00.00.40.04.0B.88.00.00.00.00.E4 (13)
[10:55:50][D][lg-controller:440]: received A8.32.00.00.40.04.0B.88.00.00.00.00.E4 (13)
[10:56:08][D][lg-controller:440]: received A8.32.00.00.40.04.0B.87.00.00.00.00.E5 (13)
[10:56:08][D][lg-controller:440]: received A8.32.00.00.40.04.0B.87.00.00.00.00.E5 (13)
[10:56:32][D][lg-controller:440]: received A8.32.00.00.40.04.0B.87.00.00.00.00.E5 (13)
[10:56:32][D][lg-controller:440]: received A8.32.00.00.40.04.0B.87.00.00.00.00.E5 (13)
[10:56:50][D][lg-controller:440]: received A8.32.00.00.40.04.0B.86.00.00.00.00.FA (13)
[10:56:56][D][lg-controller:440]: received A8.32.00.00.40.04.0B.85.00.00.00.00.FB (13)
[10:57:14][D][lg-controller:440]: received A8.32.00.00.40.04.0B.85.00.00.00.00.FB (13)
[10:57:14][D][lg-controller:440]: received A8.32.00.00.40.04.0B.85.00.00.00.00.FB (13)
[10:57:32][D][lg-controller:440]: received A8.32.00.00.40.04.0B.85.00.00.00.00.FB (13)
[10:57:32][D][lg-controller:440]: received A8.32.00.00.40.04.0B.85.00.00.00.00.FB (13)
[10:57:50][D][lg-controller:440]: received A8.32.00.00.40.04.0B.84.00.00.00.00.F8 (13)
[10:57:56][D][lg-controller:440]: received A8.32.00.00.40.04.0B.84.00.00.00.00.F8 (13)
[10:58:14][D][lg-controller:440]: received A8.32.00.00.40.04.0B.83.00.00.00.00.F9 (13)
[10:58:14][D][lg-controller:440]: received A8.32.00.00.40.04.0B.83.00.00.00.00.F9 (13)
[10:58:32][D][lg-controller:440]: received A8.33.00.00.40.04.1B.82.00.00.00.00.E9 (13)
[10:58:32][D][lg-controller:440]: received A8.33.00.00.40.04.1B.82.00.00.00.00.E9 (13)
[10:58:50][D][lg-controller:440]: received A8.33.00.00.40.04.15.82.00.00.00.00.E3 (13)
[10:58:56][D][lg-controller:440]: received A8.33.00.00.40.04.15.82.00.00.00.00.E3 (13)
[10:59:08][D][lg-controller:440]: received A8.32.00.00.40.04.15.82.00.00.00.00.E0 (13)
[10:59:08][D][lg-controller:440]: received A8.32.00.00.40.04.15.82.00.00.00.00.E0 (13)
[10:59:26][D][lg-controller:440]: received A8.32.00.00.40.04.15.82.00.00.00.00.E0 (13)
[10:59:26][D][lg-controller:440]: received A8.32.00.00.40.04.15.82.00.00.00.00.E0 (13)
[10:59:50][D][lg-controller:440]: received A8.32.00.00.40.04.15.82.00.00.00.00.E0 (13)
[10:59:50][D][lg-controller:440]: received A8.32.00.00.40.04.15.82.00.00.00.00.E0 (13)
[11:00:08][D][lg-controller:440]: received A8.32.00.00.40.04.15.82.00.00.00.00.E0 (13)
[11:00:08][D][lg-controller:440]: received A8.32.00.00.40.04.15.81.00.00.00.00.E1 (13)
[11:00:32][D][lg-controller:440]: received A8.32.00.00.40.04.15.81.00.00.00.00.E1 (13)
[11:00:32][D][lg-controller:440]: received A8.32.00.00.40.04.15.81.00.00.00.00.E1 (13)
[11:00:56][D][lg-controller:440]: received A8.32.00.00.40.04.15.80.00.00.00.00.E6 (13)

It could be possible that the half-degree-bit is confusing the unit if sent while or right after a defrost.
Since using the internal thermistor will replay the unit's temperature, it could be the reason why it works correctly.

b.) Inappropriate unit fuzzy logic / intake sensor issue

My cassette has an interesting behaviour I do not see in the same way on the Artcool Gallery: It is reducing the requested heat and the fan speeds (even at fixed setting) when coming within 2.5°C of the setpoint (+/- 0.5°C, not sure about its internal centigrade precision). Overheat setting 0.5°C and 1.0°C make no difference there.
This usually means the unit never reaches the setpoint or even comes close. IMO, it's the result of engineers who were not willing to implement a proper closed loop process regulation and went with fuzzy logic instead, there's some information about that in the HVAC Total Solution Data Book.
After defrost, the vanes usually stay closed until the intake thermistor exceeds approx. 24°C, afterwards they open up. But if the defrost happened while close to the setpoint, my old logs show the unit has trouble reaching these temperatures, because the requested heat is too low.
In TH:Unit mode, it seems to wait for an duration instead, probably because it can't measure the room temperature with closed vanes.
It might have always worked with PREMTB001, because I operated it with fixed fan speed modes and at higher setpoints that it usually didn't reach. PREMTB001 and its sensor placement was just unsuitable for proper heating of the room.
Last but not least, I found a few reports in HVAC forums about LG cassettes with issues that were resolved by positioning the sensor differently. It's "hanging freely" in the airflow and can be moved around to a certain degree.

florianbrede-ayet commented 9 months ago

I think I have to give up on debugging the issue. It's easily reproducible by just closing the bedroom door (resulting in room temperature increase), but I cannot figure out the conditions. I'm quite certain though that it is related to the pre-post defrost unit thermistor temperature.

I will build optional workarounds for my two issues:

Vane Fix: After defrost, monitor the CC message temperature. If it rises > 2°C above the pre-defrost temperature, send 3x A8 with internal thermistor + "high" setpoint. This always triggers the unit to reopen the vanes.
Cassette reduces fan speed and cannot reach setpoint: This will impact ThinQ if connected, but I'm planning to reduce the room temperature sent in A8 artifically to stay at least 2°C below the setpoint. When approaching it, increase the reported temperature smoothly towards the real value. (This "bug" exists on PREMTB as well and is independent from overheat setting and ceiling height)

My final logs for two vane failures, each triggered by closing the room doors. The second incident was surprisingly fast and at low room temperature.

FAILED:

# last C8 before defrost (th unit: 25.5°C)
[09:30:30][D][lg-controller:725]: received C8.52.00.00.40.04.14.9F.00.00.00.00.44 (13)

# last CC & CF before defrost
[09:30:30][D][lg-controller:725]: received CC.44.07.00.00.00.13.13.00.33.00.00.25 (13)
[09:30:30][D][lg-controller:725]: received CF.00.00.06.07.00.06.06.00.00.00.00.BD (13)

# first C8 after defrost
[09:42:06][D][lg-controller:725]: received C8.52.00.00.40.04.14.9A.00.00.00.00.59 (13)

# first CC & CF after defrost
[09:43:12][D][lg-controller:725]: received CC.44.07.00.00.00.00.00.00.2E.00.00.10 (13)
[09:43:12][D][lg-controller:725]: received CF.00.00.03.F1.00.03.49.00.00.00.00.5A (13)

# last C8 before vane opening (th unit: 29.5°C)
[11:26:06][D][lg-controller:725]: received C8.52.00.00.40.04.14.A7.00.00.00.00.4C (13)

-----
WORKED:

# last C8 before defrost (th unit: 22.5°C)
[12:41:48][D][lg-controller:725]: received C8.52.00.00.40.04.14.99.00.00.00.00.5E (13)

# last CC & CF before defrost
[12:41:48][D][lg-controller:725]: received CC.41.07.00.00.00.13.13.00.2D.00.00.32 (13)
[12:41:48][D][lg-controller:725]: received CF.00.00.03.F5.00.03.F5.00.00.00.00.EA (13)

# first C8 after defrost
[12:47:30][D][lg-controller:725]: received C8.52.00.00.40.04.14.94.00.00.00.00.53 (13)

# first CC & CF after defrost
[12:48:36][D][lg-controller:725]: received CC.41.07.00.00.00.00.00.00.2C.00.00.15 (13)
[12:48:36][D][lg-controller:725]: received CF.00.00.02.F6.00.02.F6.00.00.00.00.EA (13)

# last C8 before vane opening (th unit: 26.5°C)
[12:52:00][D][lg-controller:725]: received C8.52.00.00.40.04.14.A1.00.00.00.00.46 (13)

-----
FAILED:

# last C8 before defrost (th unit: 25.5°C)
[17:22:05][D][lg-controller:725]: received C8.52.00.00.40.04.14.9F.00.00.00.00.44 (13)

# last CC & CF before defrost
[17:22:05][D][lg-controller:725]: received CC.3C.07.00.00.00.00.00.00.33.00.00.17 (13)
[17:22:11][D][lg-controller:725]: received CF.00.00.08.67.00.08.9F.00.00.00.00.B0 (13)

# first C8 after defrost
[17:30:47][D][lg-controller:725]: received C8.52.00.00.40.04.14.9A.00.00.00.00.59 (13)

# first CC & CF after defrost
[17:31:53][D][lg-controller:725]: received CC.3C.07.00.00.00.00.00.00.2F.00.00.6B (13)
[17:31:59][D][lg-controller:725]: received CF.00.00.03.1C.00.03.1C.00.00.00.00.58 (13)

# last C8 before vane opening (th unit: 31°C)
[18:23:23][D][lg-controller:725]: received C8.52.00.00.40.04.14.AA.00.00.00.00.49 (13)

JanM321 commented 9 months ago

For the fan speed / setpoint issue, have you tried using a temperature offset, so a higher value for both sensor and setpoint?

I wonder if it lowers the fan speed to prevent blowing cold air when it's not requesting enough heat.

JanM321 commented 8 months ago

One of the last things I'm trying to figure out is bytes 6 and 7 of the AC/CC message. I can get the PREMTB100 to send non-zero values for these if I set it to dual setpoint with some other changes.

These bytes seem to be setpoint (byte 7) and some kind of upper bound for heating (byte 6). Byte 7 also has the high bit set if there's a change in settings. I think the max temperature value in byte 6 is used for dual setpoint auto mode when the room is unoccupied. I can change this value using the "Home Leave Set Temperature" setting.

So for example:

AC.00.C0.00.00.00.23.94.00.2A.35.00.D7
byte 6: 0x23 => 35 degrees C
byte 7: 0x14 => 20 degrees C setpoint

@florianbrede-ayet your unit often sends 11.11 for these bytes (= 17°C) which is similar to the setpoint so it makes sense. I'm not sure why it sometimes sends zeros though, maybe when the room is occupied according to its sensor?

florianbrede-ayet commented 8 months ago

@JanM321 ill check my logs again later. However, while my cassette has support for an occupation sensor, it isn't fitted.

JanM321 commented 8 months ago

@JanM321 ill check my logs again later. However, while my cassette has support for an occupation sensor, it isn't fitted.

Hm mysterious. I doubt we can do something interesting with these fields, but it's a bit weird that it sometimes sends 00.00 instead of the setpoint.

Btw it stores 0.5 degrees (for both values) in byte 8. I'm also seeing that in your logs: 11.11.55 means 17.5°C, twice.

JanM321 commented 8 months ago

My cassette has an interesting behaviour I do not see in the same way on the Artcool Gallery: It is reducing the requested heat and the fan speeds (even at fixed setting) when coming within 2.5°C of the setpoint (+/- 0.5°C, not sure about its internal centigrade precision). Overheat setting 0.5°C and 1.0°C make no difference there.

For what it's worth, I think I see the same with my units with overheat setting 4 (0.5°C). Especially when it's cold it lets the temperature drop way too far and I have to send a temperature that's a few degrees lower to get it to ramp up again. I still have to double check if it behaves the same way with the LG controllers.

I wonder if it's an internal bug where the unit incorrectly applies a 2 degrees offset in some cases (the 2 degrees offset is the default for my units with overheating setting = 0).

For now I'm using the +/- 1C setting with a template sensor to 'compress' the values around the setpoint. temperature > setpoint + 0.45 results in sending setpoint + 1 etc and that seems to work pretty well.

florianbrede-ayet commented 8 months ago

@JanM321 that's almost my behavior and I'm also playing with an equivalent logic here. For me it starts heating though, just at a way too low fan speed regardless of the fan setting.

I wanted to create a PR for that with a config "bugfix" flag eventually. If you start adjusting the room temperature at 2°C it also works for the 0.5deg overheat setting btw.

Also this doesn't happen on my LG Artcool Gallery for some reason.

Furthermore, you recommended to shift the setpoint and room temperature a while ago. A 4°C shift works and fixes the vane issue (2 was not enough, 3 seemed to work fine so I opted for 4°C). I will also create a PR for another optional flag in the config for that.

So the vane bug is an issue of the indoor unit controller, it requests less heat than the threshold needed to reopen the vanes at low setpoints.

JanM321 commented 8 months ago

@florianbrede-ayet Do you see any difference between 0.5C and 1C overheating modes, other than (of course) the start heating and stop heating thresholds? 0.5C seemed to use a bit less energy when I tried it initially but I'm not sure if that was actually true.

With 1C, units start heating at setpoint instead of setpoint - 1 when the outdoor unit is running for another indoor unit which can be nice.

I'm trying to decide if making 0.5C work is worth doing or if I should just stay with 1C which doesn't have the bug for me.

florianbrede-ayet commented 8 months ago

@JanM321 I'm testing that right now, but did you say your unit actually turns on at setpoint for overheat mode 3? I think my cassette behaves as described in the data book:

1: +4°C / +6°C
2: +2°C / +4°C
3: -1°C / +1°C
4: -0.5°C / +0.5°C

JanM321 commented 8 months ago

@JanM321 I'm testing that right now, but did you say your unit actually turns on at setpoint for overheat mode 3? I think my cassette behaves as described in the data book:

It behaves like this:

0: +1/+3. With outdoor unit on for other unit: +2/+3
3: -1/+1. With outdoor unit on for other unit: 0/+1
4: -0.5/+0.5

Maybe it depends on the indoor unit or maybe it's just the duo-splits.

JanM321 commented 8 months ago

I also find it annoying that with cold weather, the reported temperature from the controller is often 0.5C below the setpoint for hours. The unit thinks this is acceptable and doesn't even try to reach the setpoint by working a little harder.

Using a smaller temperature range (with a template sensor) helps though and maybe I'm too demanding. But I've wondered about writing my own thermostat code and using the sensor just as a +/- signal. Maybe that would confuse the unit too much.

florianbrede-ayet commented 8 months ago

@JanM321 I'm not quite sure I understand what you mean, because the "error scaling adjustment" fixes that.

Also my device uses -1°C / +1°C regardless of single / dual IDU operation.

For me, currently this quick hack is working fine (ignore the TEMP_OFFSET, that fixes my vane bug) and keeps the temperature -0.25°C / +0.25°C from the setpoint:

#define TEMP_OFFSET 4
#define TEMP_OVERSCALE 3.0f
#define TEMP_UNDERSCALE 3.0f
#define MIN_TEMP_SETPOINT 16
#define MAX_TEMP_SETPOINT 30-TEMP_OFFSET

...

float temp_adjustment=0;
if (temp > this->target_temperature) {
    // Overscale the setpoint error to overheat less
    temp_adjustment = (temp-this->target_temperature)*TEMP_OVERSCALE;
}
else {
    // Overscale the setpoint error to underheat less
    temp_adjustment = -(this->target_temperature-temp)*TEMP_UNDERSCALE;

}

send_buf_[6] = (thermistor << 4) | ((uint8_t(target) - 15) & 0xf);
send_buf_[7] = (last_recv_status_[7] & 0xC0) | uint8_t((temp+temp_adjustment+TEMP_OFFSET - 10) * 2);

Also ignore that the logic would work with a single LOC obviously...

JanM321 commented 8 months ago

@florianbrede-ayet Does this work for you with both 0.5C and 1C settings? Especially for 1C it seems pretty aggressive because after the rounding to 0.5 degrees, it will never report setpoint + 0.5.

If I change my template sensor to do something similar I get this:

   - name: "LG Living Room Sensor"
     state: >
       {% set temperature = states.sensor.atc_a2d5_livingroom_temperature.state | float | round(1, "half") %}
       {% set setpoint = states.climate.lg_living_room.attributes.temperature | float %}
       {% if (not is_state('climate.lg_living_room', 'heat')) %}
         {{ temperature }}
       {% else %}
         {{ temperature + (temperature - setpoint) * 3 }}
       {% endif %}
     unit_of_measurement: "°C"

florianbrede-ayet commented 8 months ago

@JanM321 it works fine when checking the temperatures over time (I've kept it at -1/+1 for now). But indeed, the rounding in get_room_temp could force the unit to modulate less and make the heating less efficient.

I'll try your template instead although I'm not a big fan of Jinja2.

florianbrede-ayet commented 7 months ago

@JanM321 I was too lazy to write a sensor template and instead removed the rounding from get_room_temp() and then round the final calculated values ad-hoc when building the message and setting current_temperature.

I'm happy with the results at -1°C / +1°C, although it's still disappointing how weak the modulation range of the ODU is:

florianbrede-ayet commented 7 months ago

@JanM321 I've tested the changes for a while now and it works fine for me. Should I create pull requests for my changes:

yaml flag to enable "temperature_offset" (fixes the vane bug)
yaml setting for setpoint_error_multiplier (to allow units to reach and accurately hold setpoint)

I think your template solution is fair, but it gives the component an incorrect room temperature which I find unpleasant when using climate entities.

On a side note, I finished my solution for Toshiba / Carrier HVAC units (under MIT), which is based on your structure: esphome-toshiba-hvac-controller

JanM321 commented 7 months ago

Adding a temperature offset setting makes sense to me. Instead of a multiplier I'm using a different scheme that works better for me (maybe I have too much free time...) so I'd prefer to not upstream that part.

On a side note, I finished my solution for Toshiba / Carrier HVAC units (under MIT), which is based on your structure: esphome-toshiba-hvac-controller

Very nice. I'm jealous of all the information and settings you have available there :)

My LG units have actually been working really well the past weeks. It's still a shame that LG's firmware is so bad because the hardware is quite powerful and they could get a lot more out of it if they fixed their software.

JanM321 / esphome-lg-controller

4-Way-Cassette closes vanes during operation #16

What happens

Notes:

Log