4-Way-Cassette closes vanes during operation #16
Comments
florianbrede-ayet
changed the title
|
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 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. After that, I reconnected the PREMTB001 and put the ESP32 in listening only. When doing that, I noticed something interesting. Do you think it's possible that the 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. 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: |
|
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. |
|
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. |
|
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? |
|
You're right about Also, both of my units are sending PREMTB001 does not send |
|
On a side note, do you have any idea why PREMTB is sending byte 10 Log when connecting the controller to the running cassette: |
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.
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. |
|
@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). |
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 😆. |
Yes and some other brands are similar. I've heard the Heating + Fan trick also works with MHI multi-split units. |
|
I wanted to give a short update:
Log with vanes closing at I'm now testing EDIT: Another thing I noticed is that my unit is sending two different PREMTB001 seems to always send However the ESP32 is occasionally sending |
|
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?
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. |
|
I'm a bit out of ideas.
I now have a log of the ESP32 and PREMTB001 both in |
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. |
Yes the controller is in the attic at an ambient temperature of ~0°C, so that's correct. By restricting the ESP32 to |
|
Did you already change the handshake |
Haven't tried that yet. However, currently the ESP32 is going strong after over 6 defrosts - so it seems to be working now. I thought I had this procedure covered already, but I might have made a mistake previously. I also changed thermistor to
|
|
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
b.) Inappropriate unit fuzzy logic / intake sensor issue
|
|
I think I have to give up on debugging the issue. I will build optional workarounds for my two issues:
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.
|
|
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. |
|
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: @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? |
|
@JanM321 ill check my logs again later. |
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: |
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. |
|
@JanM321 that's almost my behavior and I'm also playing with an equivalent logic here. 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. 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. |
|
@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 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. |
|
@JanM321 I'm testing that right now, but did you say your unit actually turns on at setpoint for overheat mode |
It behaves like this: Maybe it depends on the indoor unit or maybe it's just the duo-splits. |
|
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. |
|
@JanM321 I'm not quite sure I understand what you mean, because the "error scaling adjustment" fixes that. Also my device uses For me, currently this quick hack is working fine (ignore the #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... |
|
@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 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" |
|
@JanM321 it works fine when checking the temperatures over time (I've kept it at I'll try your template instead although I'm not a big fan of Jinja2. |
|
@JanM321 I was too lazy to write a sensor template and instead removed the rounding from I'm happy with the results at
|
|
@JanM321 I've tested the changes for a while now and it works fine for me.
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: |
|
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.
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. |
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:
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
Logfile: https://gist.github.com/florianbrede-ayet/ac5afb42ddf7c0b21f0365854c11abba
The text was updated successfully, but these errors were encountered: