Enable setting sleep mode on slave ESP?

[Adam1986]

Is it possible to enable sleep mode on the slave ESP? as looking at the code it looks to be disabled/prevented.

But if you do set the ESP32 into master and the wall controller into slave, you can still apply sleep mode from the slave wall controller without any issue.

My brothers setup requires that his wall units are set as master, because he uses the thermistor that is built into the wall controller, rather than the unit itself. If we set the ESP32 to master, then we're reading inaccurate temperatures from the unit.

Thanks

[JanM321]

I think the tricky part is that the controller maintains the sleep timer (not the AC unit) and sends the remaining time in its status messages, so if we have two controllers connected, we don't want them to conflict with each other (for example one controller changing the other controller's timer). I'm not sure off-hand how the LG controllers handle this in slave mode.

If you set the ESP32 to master and the LG controller to slave, you could capture the ESP32's debug log file from before you set the sleep timer from the slave controller until after the unit turns off. That should give us an idea of how the LG controller behaves.

[Adam1986]

Hi @JanM321

Thanks for replying so quickly. I've attached the logs from the moment the physical slave wall controller was set to 1 hour sleep until it turned off.

Hoping this helps.

logs_tropic22_logs.txt

My wall mounts at my house don't have any hardwired controllers, only IR remotes and LG ThinQ control, so I'd think it would be the actual air conditioning unit itself maintaining the sleep timer?

[richardc1983]

@JanM321 First off – I just want to say thank you for the work you’ve put into this project. The ESP integration you’ve built here is genuinely impressive, and it’s already transformed how we can control LG systems beyond what LG themselves expose.

I’m the “brother” in this setup, and I wanted to add some additional context around Sleep mode and temperature sensing on ducted units, as this edge case keeps coming up for us.

One behavioural point that may be useful: when the ESP is set to slave and the wired controller is master, Sleep can be set on the wired controller as normal, and it can also be set via ThinQ, in which case the active Sleep state appears on the wired controller.

Likewise, when the wired controller is set to slave and the ESP is master, Sleep can be set as expected from the ESP side.

That behaviour suggests that Sleep is effectively written to the indoor unit by whichever controller issues the command, rather than being strictly owned by a single device. If multiple controllers are present, it appears that the most recent Sleep command simply overwrites the previous state.

Given that Sleep can already be initiated from different controller types (wired controller, ThinQ, ESP when master), it seems plausible that allowing Sleep commands in slave mode could be implemented safely, particularly in cases like ours where Sleep is being used purely to enable ultra-low fan operation and the timer is never allowed to expire.

On LG ducted indoor units, Sleep isn’t being used by us as a shutdown timer. Enabling Sleep unlocks an ultra-low fan speed that isn’t otherwise selectable via normal fan commands. This speed is ideal for gentle background heating/cooling (tick-over), where even “Low” can be too aggressive in steady-state operation.

We never allow the Sleep timer to count down to zero. Our automations continuously refresh the timer so the unit never turns off – Sleep is effectively being used as a fan-mode enabler, not a power-off mechanism. From a practical point of view, this removes the risk of conflicting shutdown timers entirely.

The other half of the problem is temperature sensing. In my case the wired controller is located in the living space and its thermistor gives a far more representative room temperature than the indoor unit sensor. If ESP is set as master, that sensor built into the controller is ignored and if you change the function code 4 to code 01 it is written back to 2; if ESP is slave, the wired controllers built in sensor can be used, but Sleep is unavailable.

That’s what creates the dead-lock for ducted systems:
– ESP master → Sleep works, but wrong temperature source
– ESP slave → Correct temperature source, but no access to the ultra-low fan via Sleep

I was wondering whether there might be a future path similar to how other values are handled via function codes (for example overheat temperature). Specifically, is there any scope for exposing the wired controller’s temperature sensor as a selectable source via a function code or proxy mechanism, rather than tying it strictly to controller mastership?

I completely understand the caution around multiple controllers managing state, and I appreciate why Sleep is currently disabled for slaves. I mainly wanted to clarify that in this ducted-unit use case, Sleep is not being used as a timer at all, and the wired sensor is critical for correct control.

I’m not sure whether screenshots from the engineering function codes are useful here, but I have also attached the full PDF with the complete list if helpful.

For reference, selecting the thermostat source is handled under function code 04, while the overheat settings are under function code 15. The wired controller in question is a PREMTB100, which I believe you’ve also tested previously, along with the premium touch screen controllers such as the PREMTA000.

One interesting quirk I’ve noticed: on the PREMTB100, overheat function code 15 – value 04 (0.5 °C thermostat on/off hysteresis deadband) is not available when the controller is set to Celsius, but becomes available when switched to Fahrenheit. On the premium controllers, the same value is available when set to Celsius.

I mention this mainly to highlight that LG already gate certain behaviours and options at the controller level depending on model and configuration, which may or may not be relevant here. I’m fairly clued up on LG systems and air conditioning generally, so I’m very happy to help test, capture logs, or dig into controller behaviour if that’s useful.

Happy to provide logs or capture any behaviour you’d like if it helps explore this further. And again – thank you for the work you’ve already done on this project.

controller settings.pdf

[JanM321]

It was surprising to me too when I implemented the sleep timer, but if there is a wired controller connected, it's responsible for maintaining the sleep timer. If there's no controller, the indoor unit handles this itself. At least that's how it works for my wall units.

If the controller doesn't update the timer, ThinQ for example will just keep showing the last number-of-minutes value we sent. Which is actually the behavior you want... maybe we could add a "sleep mode" switch for this that just keeps sending "30 minutes left" :)

Thanks for replying so quickly. I've attached the logs from the moment the physical slave wall controller was set to 1 hour sleep until it turned off.

Hoping this helps.

It helps but I forgot that slave controllers don't send any messages unless a setting is changed (I don't use slave controllers myself). So in this case I see that it sets the sleep timer to 60 minutes, but after that nothing so I don't know how it behaves when another setting is changed. Could you do the same thing but after a few minutes change some other settings such as set point and fan mode from the LG slave controller? If you wait a few minutes after that there should be sufficient information in the log.

I was wondering whether there might be a future path similar to how other values are handled via function codes (for example overheat temperature). Specifically, is there any scope for exposing the wired controller’s temperature sensor as a selectable source via a function code or proxy mechanism, rather than tying it strictly to controller mastership?

As far as I know that's not possible because this is how LG's protocol and units work.

For reference, selecting the thermostat source is handled under function code 04, while the overheat settings are under function code 15. The wired controller in question is a PREMTB100, which I believe you’ve also tested previously, along with the premium touch screen controllers such as the PREMTA000.

One interesting quirk I’ve noticed: on the PREMTB100, overheat function code 15 – value 04 (0.5 °C thermostat on/off hysteresis deadband) is not available when the controller is set to Celsius, but becomes available when switched to Fahrenheit. On the premium controllers, the same value is available when set to Celsius.

Yeah, I've noticed this too and have documented it in the protocol documentation. With my units, value 4 (+/- 0.5C) works in Celsius mode but it's a bit less reliable than the +/- 1C option (temperature drops too much sometimes while heating, might be a quirk of my units).

[richardc1983]

Thanks – that all makes sense, and your explanation of how Sleep ownership works depending on what controllers are present broadly matches what we’re seeing.

Just to clarify on the logs we shared: those were captured with ESP set as master and the wired controller set as slave. In that configuration, we can see Sleep being written to and reflected by the indoor unit, and ESP maintaining the timer when it is the active controller. So while those logs don’t show slave controllers refreshing Sleep, they do confirm that Sleep state itself is unit-level and that the system behaves as last-writer-wins when Sleep is asserted.

We now understand your point that slave controllers only transmit when another setting changes, we’re happy to run the additional test you suggested (set Sleep from the slave wired controller, wait a few minutes, then change setpoint and fan mode from the same controller and capture the resulting log).

To clarify our use case in practical terms: on our ducted units, Sleep is not used as a shutdown timer. It’s used purely to access the ultra-low indoor fan state that isn’t otherwise selectable via the fan modes exposed by the protocol. Staged fan control operates normally while the room is moving toward setpoint. Once the room reaches steady state (e.g. 22.0 °C), the automation forces fan low and applies Sleep (often long durations on ducted units) to hold the space quietly and stably. If the temperature drifts away from target (±0.5 °C), Sleep is cancelled immediately and normal staged fan logic resumes so the unit can actively correct again.

On wall-mounted units, where Sleep introduces temperature offsets over time, we periodically re-apply a shorter Sleep window (e.g. resetting to 60 minutes when conditions remain satisfied) to maintain the ultra-low fan state without the temperature stepping behaviour. In all cases, Sleep is applied and removed automatically based on temperature, not used as a fixed timer or shutdown mechanism.

By way of background, I work in commercial HVAC and building management systems, so the automations we’re running here are effectively a scaled-down version of standard BMS control strategies. Fan speed is staged based on temperature error, low-load operation is stabilised using a dedicated ultra-low airflow state, and that state is exited immediately when demand increases. From a controls point of view this is closed-loop, fully automatic climate control rather than a workaround or fixed-timer approach.

With that in mind, we were wondering whether allowing a slave controller to write or refresh Sleep would effectively mirror behaviour LG already support. On systems with multiple wired controllers connected to the same indoor unit, both controllers can write a Sleep timer and the behaviour appears to be last-writer-wins, with whichever controller sends the most recent command becoming the active timer owner. Conceptually, ESP acting as a slave and writing or refreshing Sleep feels equivalent to that supported topology rather than introducing a new control path.

This is particularly important for us because the wired controller must remain master (remote thermistor in the occupied space), which means ESP must remain slave. Being able to set or refresh Sleep from ESP in that role would allow us to maintain the ultra-low “tick-over” behaviour at steady state while still using the correct room sensor. See screenshot of temperature reading when unit uses the internal sensor that gets very warm.

We’re happy to provide the additional slave-controller logs you asked for, and if useful we can also capture logs showing Sleep being written sequentially by two controllers to demonstrate how the indoor unit handles overwrites and timer ownership in practice.

Thanks again for taking the time to look into this – we’re very happy to help test or capture logs if it helps move things forward.

[Adam1986]

I've attached the logs where we switched the ESP32 to master again and set the wall controller to slave and applied sleep and then after a few minutes changed various settings.

logs_tropic22_logs (2).txt

Thanks

[JanM321]

I've made some small changes to enable the sleep timer setting for slave controllers. Maybe you can test if this is sufficient for your use case.

[Adam1986]

Hi @JanM321 thanks so much for this, I will check this out and possibly apply it to one of the ESP32's and see how we get on.

I've been meaning to do a post for a while, as I forked the repository and spent quite a lot of time on GPT getting sleep working as well when in slave mode.

I'm not a programmer/developer, so C++ means very little to me, the code is probably unoptimised and ugly, but it does seem to work fairly well after a lot of further changes.

Initially there were some odd quirks, such as setting sleep mode, and it immediately reverting. Or not been able to cancel out sleep mode. Also seems if you set a sleep timer, if you want to apply another, say when it gets down to 1h remaining, then you have to cancel out the reservation as well, otherwise the unit doesn't take it and keeps the old reservation in place, ultimately resulting in the unit powering off, as the ESP32/Home Assistant counts down from what it thinks was applied. Initially setting sleep to 0 didn't work, and after sending some of the logs to GPT it said the reservation wasn't been cancelled, so some code was changed to do that when in slave mode too.

The older PREMTB001 in master and ESP32 in slave do seems to be a bit more "troublesome", sometimes changing a setting on the PREMTB001 results in invalid checksum loops, so I added some logic to reboot the ESP32 after so many failed checksums, to bring it back in working order automatically.

However, the PREMTA000 in master mode seems to work flawlessly with the ESP32 in slave mode, and I've not witnessed any invalid checksum loops.

My modifications can be found here, you can probably decipher it better than me what Ive done!

https://raw.githubusercontent.com/Adam1986/esphome-lg-controller/refs/heads/main/esphome/components/lg_controller_slave/LG-controller-checksum.h

Thanks
Adam

[Adam1986]

Just to update you on this, I applied your version of the code, and indeed sleep variables did become available, but we found the same issues as highlighted above, I.E sleep mode won't physically cancel but the ESP32 think's it has etc. So does seem the tweaks I referenced are needed.