Inverted RX, original controller, extra sensors, swing angle etc.

[Smandurlo]

Hi, first of all, thank you for the great work on this integration! I'm trying to better understand some aspects of how the Daikin S21 protocol is handled in this project and would really appreciate any clarification on the following points:

1. Inverted RX: I'm a bit confused about when the inverted: true setting is needed for the UART RX line. Is it required for all Daikin units using S21, or only in specific cases?

2. Original controller and extra sensors: my current Daikin controller supports full local control, I would only consider replacing it if that's the only way to get access to the external temperatureas reference. Additionally, with the official Daikin Home Assistant integration, I can see extra sensors like heating/cooling power consumption, compressor frequency, and also a switch for the Streamer (air purification) function. Are these supported (or potentially supportable) via this custom ESPHome component?

3. If an external temperature sensor is enabled via this integration, is there any fallback or safety behavior in case the sensor goes offline or becomes unavailable?

4. Vertical swing angle (Byte 0): In the S21 protocol documentation from Faikin github, I noticed that byte 0 includes info about the Vertical swing angle. Is there currently a way to read this value through this component?

Thanks again for your time and any help you can provide.

[joshbenner]

Hi, first of all, thank you for the great work on this integration! I'm trying to better understand some aspects of how the Daikin S21 protocol is handled in this project and would really appreciate any clarification on the following points:

1. Inverted RX: I'm a bit confused about when the inverted: true setting is needed for the UART RX line. Is it required for all Daikin units using S21, or only in specific cases?

I think this was only needed for my specific case using the Faikin board and how it was designed.

3. Original controller and extra sensors: my current Daikin controller supports full local control, I would only consider replacing it if that's the only way to get access to the external temperatureas reference. Additionally, with the official Daikin Home Assistant integration, I can see extra sensors like heating/cooling power consumption, compressor frequency, and also a switch for the Streamer (air purification) function. Are these supported (or potentially supportable) via this custom ESPHome component?

I don't know. Any ability to talk to S21 has been based on reverse engineering the protocol with the units those of us working on it have had on hand. We've learned that S21 behavior and what data it includes can vary a fair bit between models.

5. If an external temperature sensor is enabled via this integration, is there any fallback or safety behavior in case the sensor goes offline or becomes unavailable?

No.

7. Vertical swing angle (Byte 0): In the S21 protocol documentation from Faikin github, I noticed that byte 0 includes info about the Vertical swing angle. Is there currently a way to read this value through this component?> > Thanks again for your time and any help you can provide.

Code changes to how we're interpreting S21 responses might be able to get that info. Currently it does not read the swing angle.

[Smandurlo]

thank you for your reply.

I think to have a fallback if the external temperature sensore is not available is very important. I have some mitsubishi with esphome and it works this way: you can set up a timeout for the external temperature update. Maybe you can think of it?

You can have a look at the code here: https://github.com/echavet/MitsubishiCN105ESPHome

Thank you for your great work!

[joshbenner]

I'm not sure what you mean by a fallback. All this integration does is report the outdoor temperature reading -- it is not involved in making any decisions about what commands to send the unit.

[Smandurlo]

Reading your post here (https://github.com/joshbenner/esphome-daikin-s21/issues/2) and the information on the Faikin GitHub page, I understand that the reference temperature for the split is adjusted using a setpoint. Mitsubishi takes a different approach — it simply uses the external temperature as-is. If the external temperature becomes unavailable, it falls back to the internal temperature sensor.

However, if the external temperature (not to be confused with the outdoor unit temperature) goes offline or becomes unavailable, the setpoint may be calculated incorrectly. In that case, it should fall back to a setpoint of 0 to rely solely on the internal temperature sensor. Of course, once the external temperature becomes available again, the dynamic setpoint calculation should resume.

I hope it is more clear now

[joshbenner]

The external sensor referred to in #2 is a separate arbitrary sensor you can configure to use to calculate an offset for the setpoint calculation, not the HVAC system's exterior temperature sensor (while it could be used to calculate the offset, I doubt that would make sense). If you wish to use that feature with some sort of fallback, you might be able to accomplish that in HA with a template sensor.

[Smandurlo]

I am familiar with the offset. Making a template sensor is a possibility, but to make it work I need the split internal temperature without the offset or the calculated offset or the possibility to write the offset with an automation knowing the steps and the min/max values.

I think it is more easy and convenient to do it inside your code.

EDIT: I realised in my previous post I wrote "setpoint" instead of "offset". My mistake

[joshbenner]

I essentially used two-source via template sensor in my use case:

  - sensor:
      name: Office Multi-Sensor Temperature
      unit_of_measurement: "°F"
      device_class: temperature
      state: "{{ (states('sensor.office_temperature') if has_value('sensor.office_temperature') else states('sensor.awair_element_121694_temperature')) | float }}"

You could just as easily sub in any set of sensors that makes sense for your case, including the temperature sensors from the HVAC unit itself.

[Smandurlo]

Your solution works if Home Assistant is always available, but that's a major limitation. What happens if Home Assistant stops working or is unavailable for any reason? In that case, the AC will never revert to its internal temperature sensor, and the system won’t behave as expected.

This kind of fallback logic really should be handled internally by ESPHome, not by Home Assistant. ESPHome is capable of running independently, so it makes much more sense for it to manage such a critical function without relying on an external system.

Also, your solution only works if you have two separate temperature sensors — and I don’t have that option. The internal sensor of the HVAC is already being corrected with an offset, so it can’t be used directly as a fallback.

TVRs do support this kind of setup because they allow you to specify an offset and expose it as an entity, which can be adjusted dynamically. But if the offset is managed internally and not exposed, there’s no way to implement a proper fallback unless you're using two physical thermometers.

Even then — what if both sensors are Bluetooth and Bluetooth fails? You’d lose both of them at once.

[joshbenner]

Sure, that makes sense. I'd happily take a look at a pull request that accomplishes that.

[Smandurlo]

Thanks again! I'm not able to create a proper pull request myself, as I'm not familiar enough with the codebase or ESPHome development — but I wanted to describe the behavior as clearly as possible, in case someone else would like to take a look. Suggested behavior (fallback when external temperature is unavailable):

• There should be a configurable timeout, e.g. external_temp_timeout: 300s.

• If no new value is received from the external temperature sensor within that time, the offset should automatically fall back to 0, so the AC uses only its internal temperature sensor.

• As soon as the external temperature becomes available again (i.e., a new reading is received), the system should resume calculating and applying the offset dynamically, as before.

This would make the logic much more reliable — especially in situations where:

• The temperature sensor may go offline

• Home Assistant becomes unavailable

• there's only one temperature sensor and no fallback is possible

Letting ESPHome handle this internally would avoid depending entirely on Home Assistant and make the behavior more resilient.

[asund]

@Smandurlo I have a local branch with the swing angles and compressor frequency being reported. I hope to get them integrated at some point but would need your help decoding the purifier mode and power consumption as I don't have reference values to compare to the seemingly-to-me arbitrary values being read out.

[Smandurlo]

@asund thank you for your message! Yes, I can help. The only issue is that my Daikin units are at my second home in Portugal, and I haven’t planned when I’ll be going back yet.

Please let me know how I can assist. I believe a friend of mine, who has several Daikin AC units, might be able to help you right away.

[asund]

@asund thank you for your message! Yes, I can help. The only issue is that my Daikin units are at my second home in Portugal, and I haven’t planned when I’ll be going back yet.

Please let me know how I can assist. I believe a friend of mine, who has several Daikin AC units, might be able to help you right away.

I have been working on a fork in my repo for a little bit now. How skilled are you two with coding? Disconnected development will be difficult, especially when trying to polish how things work through to the Home Assistant UI, but I'm willing to take a shot. Feel free to open or comment on some issues in my repo. I would first want to work on detecting the capabilities of the units, so knowing which models they are and if my mostly untested protocol detection code works for you and what it reports would be a good starting point. After that it would be adding commands for additional sensor and state readout followed by control.