Repeated disconnections from Home Assistant

[drogfild]

Hi,

First thanks for all the great work you have put into this! But for some reason I'm unable to get this running properly. I get repeated Home Assistant disconnections and I don't find a reason for it. It's connecting, updating other values to HA (but client component is missing details) but then it disconnects. After few seconds it reconnects and same happens again.

I have now tried two different ESP32 boards connected to CN105 and also without connection to heatpump. It builds up just fine without problems. First I was with beta version of ESPHome 1.15.x and now with official release 1.15.2.

Could you check and advice how to troubleshoot this? Is there something missing in my configuration? Or how to find the real issue in this?

Log:

[12:45:11][D][time:040]: Synchronized time: Wed Sep 23 12:45:11 2020
[12:45:12][D][api:067]: Disconnecting Home Assistant 0.115.2 (192.168.1.240)
[12:45:12][D][api.connection:604]: Client 'Home Assistant 0.115.2 (192.168.1.240)' connected successfully!
[12:45:12][D][time:040]: Synchronized time: Wed Sep 23 12:45:12 2020
[12:45:12][D][api:067]: Disconnecting Home Assistant 0.115.2 (192.168.1.240)
[12:45:12][D][api.connection:604]: Client 'Home Assistant 0.115.2 (192.168.1.240)' connected successfully!
[12:45:12][D][time:040]: Synchronized time: Wed Sep 23 12:45:12 2020
[12:45:12][D][api:067]: Disconnecting Home Assistant 0.115.2 (192.168.1.240)
[12:45:12][D][api.connection:604]: Client 'Home Assistant 0.115.2 (192.168.1.240)' connected successfully!
[12:45:13][D][time:040]: Synchronized time: Wed Sep 23 12:45:12 2020
[12:45:13][D][api:067]: Disconnecting Home Assistant 0.115.2 (192.168.1.240)
[12:45:13][D][api.connection:604]: Client 'Home Assistant 0.115.2 (192.168.1.240)' connected successfully!

Short part of Very Verbose log:

[21:26:35][VV][api.service:131]: send_text_sensor_state_response: TextSensorStateResponse {
  key: 2119287227
  state: '1.15.0b4 Sep 12 2020, 21:24:38'
  missing_state: NO
}
[21:26:35][VV][api.service:131]: send_text_sensor_state_response: TextSensorStateResponse {
  key: 1752637618
  state: '192.168.1.248'
  missing_state: NO
}
[21:26:35][VV][api.service:181]: send_climate_state_response: ClimateStateResponse {
  key: 1293927233
  mode: CLIMATE_MODE_OFF
  current_temperature: nan
  target_temperature: -1.69474e+38
  target_temperature_low: 0
  target_temperature_high: 0
  away: NO
  action: CLIMATE_ACTION_OFF
  fan_mode: UNKNOWN
  swing_mode: UNKNOWN
}
[21:26:35][D][api:067]: Disconnecting Home Assistant 0.114.4 (192.168.1.240)
[21:26:38][VV][api.service:192]: on_hello_request: HelloRequest {
  client_info: 'Home Assistant 0.114.4'
}
[21:26:38][V][api.connection:588]: Hello from client: 'Home Assistant 0.114.4 (192.168.1.240)'
[21:26:38][VV][api.service:012]: send_hello_response: HelloResponse {
  api_version_major: 1
  api_version_minor: 3
  server_info: 'mitsubishiheatpump (esphome v1.15.0b4)'
}

Notice how target_temperature is weird value at least in the log. And disconnection happens right after that. I didn't find any interesting logs from Home Assistant side that would correlate with these.

My code:

substitutions:
  devicename: mitsubishiheatpump
  upper_devicename: MitsubishiHeatpump
  description: https://github.com/geoffdavis/esphome-mitsubishiheatpump

# cd src
# git clone https://github.com/geoffdavis/esphome-mitsubishiheatpump.git

esphome:
  name: $devicename
  platform: ESP32
  board: esp-wrover-kit
  comment: $description

  libraries:
    - SwiCago/HeatPump
# tried this library also, but that didn't compile without errors and seems to be included in SwiCago now
#    - https://github.com/geoffdavis/HeatPump#init_fix  

  includes:
    - src/esphome-mitsubishiheatpump

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: $devicename
    password: !secret esphome_backup_ap_password

#captive_portal:

# Enable logging, but disable for uart
logger:
  baud_rate: 0
#  level: VERY_VERBOSE

# Web server can be removed after enabling HA API
#web_server: 
#  port: 80

# Sync time with Home Assistant.
time:
  - platform: homeassistant
    id: homeassistant_time

# Enable Home Assistant API
api:
  password: !secret esphome_api_password

ota:
  password: !secret ota_password
  id: otapw

sensor:
  - platform: uptime
    name: uptime
  - platform: wifi_signal
    name: wifi_signal
    update_interval: 120s

text_sensor:
  - platform: version
    name: version
  - platform: wifi_info
    ip_address:
      name: ip

climate:
  # ESP32 only - change &Serial to &Serial1 or &Serial2 and remove the
  # logging:baud_rate above to allow the built-in UART0 to function for
  # logging.
  - platform: custom
    lambda: |-
      auto my_heatpump = new MitsubishiHeatPump(&Serial);
      App.register_component(my_heatpump);
      return {my_heatpump};
    climates:
      - name: "Heat Pump"

I have also tried &Serial1 and &Serial2 but those didn't have any effect on the issue.

[thompsa]

The HA Esphome api will disconnect if any invalid states are send through, you can check this by increasing the logging

logs:
  aioesphomeapi: debug

It will show something like

2021-04-27 06:38:44 DEBUG (MainThread) [aioesphomeapi.connection] heatpump.local: Got message of type <class 'api_pb2.ClimateStateResponse'>: key: 4281390649
current_temperature: nan
target_temperature: -1.6947395e+38
fan_mode: 254
swing_mode: 254

2021-04-27 06:38:44 INFO (MainThread) [aioesphomeapi.connection] heatpump.local: Unexpected error while reading incoming messages: 254 is not a valid ClimateFanMode
2021-04-27 06:38:44 DEBUG (MainThread) [aioesphomeapi.connection] heatpump.local: Closed socket

I resolved this by initialising those on setup. It is trying to publish the state before the first SwiCago/HeatPump callback.

diff --git a/espmhp.cpp b/espmhp.cpp
index e3a217d..0ba46bb 100644
--- a/espmhp.cpp
+++ b/espmhp.cpp
@@ -412,6 +412,10 @@ void MitsubishiHeatPump::setup() {

     ESP_LOGCONFIG(TAG, "Intializing new HeatPump object.");
     this->hp = new HeatPump();
+    this->current_temperature = 16;
+    this->target_temperature = 16;
+    this->fan_mode = climate::CLIMATE_FAN_OFF;
+    this->swing_mode = climate::CLIMATE_SWING_OFF;

 #ifdef USE_CALLBACKS
     hp->setSettingsChangedCallback(

[bulletmark]

@thompsa, how do you go about making the above change? I am new to HA and ESPHOME, only discovering them by reference from this repo. I am using ESP32 D1 mini clones from Aliexpress for my 4 new aircon units. I thought I would practice generating my ESP32 boards before I get them connected as I am waiting for delivery of the CN105 connectors. Esphome seems to build and install fine but I get constant immediate disconnects/connects to HA, probably due to the issue you point out just above. If I change the source file in my build dir then it gets regenerated when I do a compile. If I git clone this repo to my machine and change the external_components/source line to point to that then I get Platform not found: 'climate.mitsubishi_heatpump' error. How can I make esphome use my own source? [I guess I could fork this repo and point to that, but there has to be a simpler way].

Also, @geoffdavis, this seems a simple fix. Any reason you don't want to add it? BTW, thanks for superb project. I leaned back in amused shock when I typed the esphome run command and everything downloaded, built, uploaded by USB to the device, then it appeared on my wifi network and automatically in HA.

[bulletmark]

OK, so I went ahead and forked this repo, made the change, pointed the component to my forked repo, then rebuilt and uploaded where it is now working fine, i.e. it stays connected (and showing 16 degrees in HA of course now). Still interested in knowing how to do a change locally though?

[thompsa]

For me this turned out to be a symptom of the serial connection to the heatpump not working, I was using Serial2 on the ESP32 which worked fine for TX (I could control the heatpump mode, etc) but RX did not work. As the esp was not receiving any data from the heatpump the above state variables were uninitialised. Switching back to Serial0 resolved it.

While initialising them does stop HA from repeatedly disconnecting the sensor, you will want to fix the communication issue. You don't want it to say 16 degrees forever.

[bulletmark]

@thompsa, please understand, I certainly don't want my HA to report 16 degrees forever!? It won't once I eventually get it connected to my aircon unit but that is not the issue here.

@geoffdavis, the issue is that if the CN105 connection is down (i.e. unplugged, wrongly configured, etc), then the ESP device goes into a hard thrash loop where it is disconnecting and reconnecting to the HA server at least 4 times per second forever, i.e. it smashes the server ad-infinitum. Clearly this is undesirable and I am simply stating that the 4 line patch above fixes that issue.

[bulletmark]

I worked out how to make source changes locally. You have to point to the actual components dir when specifying a path.

Also, a better patch is:

diff --git a/components/mitsubishi_heatpump/espmhp.cpp b/components/mitsubishi_heatpump/espmhp.cpp
index e1cb942..5bceea9 100644
--- a/components/mitsubishi_heatpump/espmhp.cpp
+++ b/components/mitsubishi_heatpump/espmhp.cpp
@@ -428,6 +428,10 @@ void MitsubishiHeatPump::setup() {

     ESP_LOGCONFIG(TAG, "Intializing new HeatPump object.");
     this->hp = new HeatPump();
+    this->current_temperature = NAN;
+    this->target_temperature = NAN;
+    this->fan_mode = climate::CLIMATE_FAN_OFF;
+    this->swing_mode = climate::CLIMATE_SWING_OFF;

 #ifdef USE_CALLBACKS
     hp->setSettingsChangedCallback(

[geoffdavis]

I like the NAN values better than dummy valid values, as it signifies to the user that something is wrong. I wish there were something similar for the climate modes. It might be worth adding a binary sensor that signifies a working connection to the equipment.

[geoffdavis]

Fixed in GH-34