gysmo38 / mitsubishi2MQTT

Mitsubishi to MQTT with ESP8266 module
GNU Lesser General Public License v2.1
371 stars 133 forks source link

HVAC Control portion of Web UI dashboard doesn't seem to work at all (other than temp) #182

Open anth-dinosaur opened 1 year ago

anth-dinosaur commented 1 year ago

Is it just me, or does the HVAC control portion of the web UI not seem to work except for Set Temp setting? I am unable to set power, mode, fan, vane, or wide vane from the UI - as I monitor the MQTT topics, I do not see my "settings" update. Verified that the POST requests are working fine. I've noted the following:

When modifying the beginning of the change_states function on line 1202 as follows:

heatpumpSettings change_states(heatpumpSettings settings) {
  if (server.hasArg("CONNECT")) {
    hp.connect(&Serial1);
  }
  else {
    bool update = false;
    if (server.hasArg("POWER")) {
      settings.power = server.arg("POWER").c_str();
      if (_debugMode) mqtt_client.publish((ha_debug_topic + "msg").c_str(), (char*)("Power: ")); //debugmsg
      if (_debugMode) mqtt_client.publish((ha_debug_topic + "msg").c_str(), (char*)(server.arg("POWER").c_str())); //debugmsg
      if (_debugMode) mqtt_client.publish((ha_debug_topic + "msg").c_str(), (char*)(settings.power)); //debugmsg
      update = true;
    }
...

I get the following three messages on my "debugmsg" MQTT topic:

1. Power:
2. ON
3. �?/

Perhaps this is my unfamiliarity with C++, but settings.power was set equal to server.arg("POWER").c_str(), shouldn't # 2 and # 3 show identical output?

Confirming the above:

I noticed this as I was able to set the power setting properly by publishing to MQTT, which calls hp.set functions explicitly rather than building a heatpumpSettings object and calling hp.setSettings.

Last thought, the set temperature from the web UI does seem to work properly. Again I am not very familiar with C++ but it seems this is passed as a float rather than a pointer which might make the difference?

Using latest versions of this and Swicago/Heatpump library.

anth-dinosaur commented 1 year ago

I have not. I suspect it has something to do with data types and/or assignments given the difference in my example output #2 vs #3, but I am not quite familiar with C enough to understand. Will post back if I find something, but I’m primarily using the MQTT implementation which seems to work without issue.Sent from my iPhoneOn Oct 30, 2022, at 7:31 AM, juuzonieminen @.***> wrote: I have same problem. Did you find solution?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

maxmacstn commented 2 months ago

I have the same issue. The solution for me was to copy the string before assigning it to the setting

  if (server.hasArg("CONNECT")) {
    hp.connect(acSerial);
  }
  else {
    bool update = false;
    if (server.hasArg("POWER")) {
      settings.power = strdup(server.arg("POWER").c_str());
      Log.ln(TAG, "Power = " + String(settings.power));
      update = true;
    }
    if (server.hasArg("MODE")) {
      settings.mode = strdup(server.arg("MODE").c_str());
      Log.ln(TAG, "Mode = " + String(settings.mode));
      update = true;
    }
    if (server.hasArg("TEMP")) {
      settings.temperature = convertLocalUnitToCelsius(server.arg("TEMP").toInt(), useFahrenheit);
      Log.ln(TAG, "Temp = " + String(settings.temperature));
      update = true;
    }
    if (server.hasArg("FAN")) {
      settings.fan = strdup(server.arg("FAN").c_str());
      Log.ln(TAG, "Fan = " + String(settings.fan));
      update = true;
    }
    if (server.hasArg("VANE")) {
      settings.vane = strdup(server.arg("VANE").c_str());
      Log.ln(TAG, "Vane = " + String(settings.vane));
      update = true;
    }
    if (server.hasArg("WIDEVANE")) {
      settings.wideVane = strdup(server.arg("WIDEVANE").c_str());
      Log.ln(TAG, "WideVane = " + String(settings.wideVane));
      update = true;
    }

ps. Please ignore Log.ln() function.

andrewleech commented 2 months ago

FYI this issue has been addressed in similar ways in both #248 and #253