rbroker / ecodan-ha-local

Local HomeAssistant support for Air to Water Heat Pump Data/Control for Mitsubishi Ecodan
GNU General Public License v3.0
46 stars 10 forks source link

Problem with switch heat_pump_force_dhw #7

Closed limkinZero closed 9 months ago

limkinZero commented 10 months ago

Hi,

I think there is a problem with the control heat_pump_force_dhw.

Yesterday night, when i sent the order to force hot water from home assistant control, all communication with the esp32 board brokes. I could not access the web server to see the logs nor did I receive any mqtt messages. All entities became unavailable.

This morning, after reset the board manually, I tried again and the same error again. There's no communication and everything is blocked. Before the new developments this worked fine.

Could you see if there are any errors with this. In the payload that is sent from HA it is:

{
  "name": "force_dhw_588f23ce877c",
  "unique_id": "force_dhw_588f23ce877c",
  "icon": "mdi:toggle-switch-variant",
  "device": {
    "identifiers": [
      "588f23ce877c"
    ],
    "name": "Mitsubishi A2W Heat Pump",
    "sw_version": "v0.1.0",
    "model": "Ecodan Air Source Heat Pump",
    "manufacturer": "MITSUBISHI ELECTRIC",
    "configuration_url": "http://192.168.1.91/configuration"
  },
  "state_topic": "ecodan_hp/mode_dhw_forced_588f23ce877c/state",
  "stat_t_tpl": "{{ value }}",
  "state_on": "on",
  "state_off": "off",
  "command_topic": "ecodan_hp/force_dhw_588f23ce877c/set",
  "command_template": "{{ value }}",
  "platform": "mqtt"
}

On the other hand, do you know how you can debug or view logs remotely? My indoor unit is not accessible so I have to disassemble everything to reset the esp32.

Regards

rbroker commented 10 months ago

Sorry, I will be a bit busy the next few days so I wont have much time to help with this. Do you have Dump Serial Packets enabled? If so, maybe try disabling it (I had some problems before where it could cause a stack overflow in some cases). It seems unlikely this is the problem, if the board is stuck, but not resetting itself after ~30s, it means it must still be stuck in a loop where it is still pinging the watchdog timer.

I don't think there is a simple way (unfortunately) to get debug information back if the board becomes unresponsive. That payload looks like a discovery topic though, so it should be sent from ESP32 to HA.

limkinZero commented 10 months ago

No. I haven't enabled dump serial packets. I've checked the code and I'm not 100% sure that it enters the condition where it creates the watchdog thread. Maybe my board isn't one of those. Right now I use the esp32 wroom devkit.

    {
     #if CONFIG_IDF_TARGET_ESP32S2 || CONFIG_IDF_TARGET_ESP32S3 || CONFIG_IDF_TARGET_ESP32C3
        esp_task_wdt_init(30, true); // Reset the board if the watchdog timer isn't reset every 30s.
     #endif
    }
limkinZero commented 10 months ago

Indeed I have verified that with my board (esp32 wroom 32) it does not meet the condition so it did not initialize watchlog nor its thread. Furthermore, I have seen that this board does not have an internal temperature sensor so there is another condition that is not met when loading the sensor information.

Using the macro CONFIG_IDF_TARGET_ESP32 yes.

I'm doing tests internally. I'll keep you informed.

limkinZero commented 9 months ago

The error was fixed. Thanks