@ -92,8 +92,14 @@ You can use the `verify_flash` option to ensure its correctly written back. Howe
Once powered up, the device should register on your network and appear online within ESPhome's dashboard. You should be prompted to create a new device in home assistant, and create a default lovelace card. From here everything should work as you might expect. You can control the operating mode, fan speed, set temperature and swing mode from Home Assistant (I didn't yet bother implementing C/F switching, smart cool or sleep mode, but the UI would need modifying too). You should see the temperature readout (in Celsius), and the UI will report when the unit is 'off' vs when it is 'idle'. That is, turned on in heating or cooling modes but fan off (idle) while at set temperature.
## Further development
## Overrun
These AC units have a design flaw in that when reaching set point in heating mode, both compressor and fan shut down together. The latent heat in the evaporator has nowhere to go, so the measured temperature (which we assume to mean *room temperature!*) rises many degrees. This has the negative effect of preventing further heating for an excessive period, without turning the set point right up. The MCU should overrun the fan after turning off the compressor to remove this latent heat.
Fortunately that now happens! I've implemented this in a standard ESPhome automation, configured in the Yaml file. It's optional, and you may omit this by simply not using the configuration below the overrun comment.
I should state somewhere, *I am not a programmer!* So while I've tried to keep the code clean and sane within my extremely limited abilities, I expect there's much room for improvement. I have no idea how to implement the "custom fan modes" so currently the only speeds available are 1, 3 and 5 (low/mid/high). There's also the possibility that due to who-knows-what, a command from Home Assistant might not make it to the module. I'm unsure why this *(only very rarely)* happens, but rather than checking for individual mode / fan / swing / temperature changes, perhaps the code could poll Home Assistant for all the states, and apply them where the desired state differs from the states reported by the MCU? Alternatively, this logic might be implemented in a HA automation too to ensure reported state == desired state.
Figuring out this logic revealed the MCU can't be trusted to report what you expect when you would expect it (leading to race conditions and faulty logic, for example the MCU might report state HEATING for a few moments when it's already IDLE). Ultimately this lead to improvements within the main code to detect mode and current state (idle/heating etc) among other tweaks.
## Further development
Also interesting to note, these AC units have a silly design flaw in that while in heating mode, they don't overrun the fan when reaching the target temperature. The compressor and fan simply stop together (idle mode), and the latent heat in the evaporator causes the temperature to shoot up much higher than room temperature. Therefore the readout is misleading, and it's impossible to call for more heat without turning the temperature much higher, or simply waiting a number of minutes. The manufacturer should have designed the system to overrun the fan after turning off the compressor to remove the latent heat. The problem is noticeable within the Tuya app also, but the panel only displays the set temperature. Fortunately, we can now achieve this with a little automation, although that might be better left to an automation in Home Assistant to switch into fan mode for 10 seconds after switching state from heating to idle, then return to heat mode? Or perhaps and ESPhome lambda function in the yaml.
I should state somewhere, *I am not a programmer!* So while I've tried to keep the code clean and sane within my extremely limited abilities, I expect there's much room for improvement. I have no idea how to implement the "custom fan modes" so currently the only speeds available are 1, 3 and 5 (low/mid/high). There's also the possibility that due to who-knows-what, a command from Home Assistant might not make it to the module. I'm unsure why this *(only very rarely)* happens *(and might even be fixed!)*, but rather than checking for individual mode / fan / swing / temperature changes, perhaps the code could poll Home Assistant for all the states, and apply them where the desired state differs from the states reported by the MCU?