Remote current Temperature overwritten by local current temperature

[victorgolfecho]

I setup a remote temperature sensor which is correctly updates the temperature based on the HA entity id. However, the Current Temperate is regularly overwritten by the room temperature being provided by unit. Note: this behavior is happening on only 1 of my 2 heat pumps (they are different models) configured with a remote thermostat.

I enabled DEBUG log and captured when it's happening. In this example, the remote temp is reading 19.5C and the unit is reading 11C.

[13:30:27][D][CN105:308]: sending a request for settings packet (0x02)
[13:30:27][I][CYCLE:039]: 1: Cycle start
[13:30:27][D][CYCLE:311]: 2a: Sending settings request (0x02)
[13:30:27][D][CN105:323]: creating Info packet
[13:30:27][D][CN105:084]: writing packet...
[13:30:27][D][WRITE:170]: FC 42 01 30 10 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7B
[13:30:27][D][Header:091]: command: (62) data length: [10]<-- header
[13:30:27][D][READ:170]: FC 62 01 30 10 02 00 00 01 01 0F 02 05 00 00 00 A0 00 00 00 00 A3
[13:30:27][D][chkSum:077]: OK-> A3=A3
[13:30:27][D][CYCLE:315]: 2b: Receiving settings response
[13:30:27][D][Decoder:173]: [0x02 is settings]
[13:30:27][D][Decoder:181]: [Power : ON]
[13:30:27][D][Decoder:182]: [iSee : 0]
[13:30:27][D][Decoder:183]: [Mode : HEAT]
[13:30:27][D][Decoder:195]: [Temp °C: 16.000000]
[13:30:27][D][Decoder:198]: [Fan: 1]
[13:30:27][D][Decoder:201]: [Vane: ↓↓]
[13:30:27][W][lookup:204]: wideVane reading caution: value 0 not found, returning value at index 0
[13:30:27][D][Decoder:206]: [wideVane: ←← (adj:0)]
[13:30:27][D][SETTINGS:113]: [current ]-> [power: ON , target °C: 16.0, mode: HEAT , fan: 1 , vane: ↓↓, wvane: ←←]
[13:30:27][D][SETTINGS:113]: [received ]-> [power: ON , target °C: 16.0, mode: HEAT , fan: 1 , vane: ↓↓, wvane: ←←]
[13:30:27][D][EVT_SETS:072]: [wanted ]-> [power: - , target °C: -1.0, mode: - , fan: - , vane: - , wvane: - , hasChanged ? -> NO, hasBeenSent ? -> NO]
[13:30:27][D][SETTINGS:087]: [climate]-> [mode: HEAT, target °C: 16.0, fan: LOW, swing: OFF]
[13:30:27][D][CN105:218]: setting action to -> 4
[13:30:27][D][CN105:267]: Climate mode is: 3
[13:30:27][D][CN105:268]: Climate action is: 4
[13:30:27][D][climate:396]: 'Heat Pump - Living Room' - Sending state:
[13:30:27][D][climate:399]: Mode: HEAT
[13:30:27][D][climate:401]: Action: IDLE
[13:30:27][D][climate:404]: Fan Mode: LOW
[13:30:27][D][climate:416]: Swing Mode: OFF
[13:30:27][D][climate:419]: Current Temperature: 19.50°C
[13:30:27][D][climate:425]: Target Temperature: 16.00°C
[13:30:27][D][CYCLE:318]: 3a: Sending room °C request (0x03)
[13:30:27][D][CN105:323]: creating Info packet
[13:30:27][D][CN105:084]: writing packet...
[13:30:27][D][WRITE:170]: FC 42 01 30 10 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7A
[13:30:27][W][component:237]: Component esphome.coroutine took a long time for an operation (75 ms).
[13:30:27][W][component:238]: Components should block for at most 30 ms.
[13:30:27][D][Header:091]: command: (62) data length: [10]<-- header
[13:30:27][D][READ:170]: FC 62 01 30 10 03 00 00 01 00 92 96 00 00 00 00 00 00 00 00 00 31
[13:30:27][D][chkSum:077]: OK-> 31=31
[13:30:27][D][CYCLE:324]: 3b: Receiving room °C response
[13:30:27][D][Decoder:253]: [Room °C: 11.000000]
[13:30:27][D][Decoder:254]: [OAT °C: 9.000000]
[13:30:27][I][STATUS:134]: [received ]-> [room C°: 11.0, operating: NO , compressor freq: 0.0 Hz]
[13:30:27][I][STATUS:134]: [current ]-> [room C°: 19.5, operating: NO , compressor freq: 0.0 Hz]
[13:30:27][D][CN105:218]: setting action to -> 4
[13:30:27][D][CN105:267]: Climate mode is: 3
[13:30:27][D][CN105:268]: Climate action is: 4
[13:30:27][D][climate:396]: 'Heat Pump - Living Room' - Sending state:
[13:30:27][D][climate:399]: Mode: HEAT
[13:30:27][D][climate:401]: Action: IDLE
[13:30:27][D][climate:404]: Fan Mode: LOW
[13:30:27][D][climate:416]: Swing Mode: OFF
[13:30:27][D][climate:419]: Current Temperature: 11.00°C
[13:30:27][D][climate:425]: Target Temperature: 16.00°C
[13:30:27][D][CYCLE:327]: 4a: Sending status request (0x06)
[13:30:27][D][CN105:323]: creating Info packet
[13:30:27][D][CN105:084]: writing packet...
[13:30:27][D][WRITE:170]: FC 42 01 30 10 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 77
[13:30:27][W][component:237]: Component esphome.coroutine took a long time for an operation (56 ms).
[13:30:27][W][component:238]: Components should block for at most 30 ms.
[13:30:27][D][Header:091]: command: (62) data length: [10]<-- header

Here is the relevant parts of the config yaml:

sensor:

• platform: homeassistant
  name: "Temperature Sensor From Home Assistant"
  entity_id: ${remote_temp_sensor}
  internal: false
  device_class: temperature
  state_class: measurement
  unit_of_measurement: "°C"
  filters:
  • lambda: 'return (x - 32) * (5.0/9.0);'
  • clamp: # Limits values to range accepted by Mitsubishi units
    min_value: 1
    max_value: 40
    ignore_out_of_range: true
  • throttle: 30s
    on_value:
    then:
    • logger.log:
      level: WARN
      format: "Remote temperature received from HA: %.1f C"
      args: [ 'x' ]
    • lambda: 'id(hp).set_remote_temperature(x);'

climate:

• platform: cn105
  name: ${friendly_name}
  id: hp
  remote_temperature_timeout: 30min
  update_interval: 4s
  debounce_delay : 100ms

Lastly, this is easily reproducible on my side. It oscillates between the two temp readings every few seconds, happy to provide any more info if it'd be helpful.

[jan-dewit]

I have the same issue, it is updating from the remote sensor, but it's mixing up for some reason.
I also noticed my unit is not stopping when at target temperature, there seems to be a built-in offset of at least 1 degree.

@echavet any idea in which direction a solution can be found for this issue?

[CopperSubstrate]

I've had this issue as well.

[victorgolfecho]

I have a change into the geoffdavis version of this project that appears to be working for me: geoffdavis/esphome-mitsubishiheatpump#173

I have not had a chance to make the changes to this version.

[phidauex]

@victorgolfecho What indoor and outdoor unit models do you have? I wonder how the MHK and Kumo systems deal with the issue if something about the indoor unit overwrites the remote temperature value on its own (perhaps they do what your proposed solution does, and simply republish the remote temperature frequently).