choosing with current temperature to use on a thermostat (if there are multiple sensors)

[proddy]

From https://github.com/proddy/EMS-ESP/issues/582#issuecomment-730197722

@MichaelDvP suggested

create a value haTemp in the mqtt and set the HA-climate to uses this as roomtemperature. If we have currtemp (roomthermostat) , publish it also as haTemp, If thermostat is weather-controlled use the setpoint_roomtemperature also as haTemp. That's not completly wrong, the thermostat internally sets the flowtemperature to reach this roomtemperature and assumes always that setpoint and roomtemp are identical (if not: heatingcurve is wrong). As a third option we can add a command roomtemp and send a value to ems-esp that is republished as haTemp. This allows users to measure roomtemperature with a aqara-sensor, a sonoff-T1 or something else and inject the temperatue to the climate-widget.

So idea is to have an option to configure which current room temperature sensor to use

• "none": which will use a value of 0
• "thermostat": which will use the thermostat currtemp (if it exists, otherwise 0)
• "outside": using the thermostat supported outdoor/outside/weather sensor (if it exists, otherwise 0)
• "other": which points to an MQTT topic which has the value, like your sonoff example

this would be a pull-down select setting in the WebUI for the Master Thermostat.

not sure though how to handle the different heating circuits?

Originally posted by @proddy in https://github.com/proddy/EMS-ESP/issues/582#issuecomment-730217771

[proddy]

and Michael's code:

Why not select automatically by checking the valid value in hierarchical order:

           if (Mqtt::mqtt_format() == Mqtt::Format::HA) {
                if (Helpers::hasValue(hc->ha_temp)) {
                    dataThermostat["hatemp"] = Helpers::round2((float)hc->ha_temp / 10);
                } else if (Helpers::hasValue(hc->curr_roomTemp)) {
                    dataThermostat["hatemp"] = Helpers::round2((float)hc->curr_roomTemp / curr_temp_divider);
                } else {
                    dataThermostat["hatemp"] = Helpers::round2((float)hc->setpoint_roomTemp / setpoint_temp_divider);
                }
            }

and set the ha_temp by

bool Thermostat::set_roomtemp(const char * value, const int8_t id) {
    float f = 0;
    if (!Helpers::value2float(value, f)) {
        LOG_WARNING(F("Set roomtemperature: Invalid value"));
        return false;
    }
    uint8_t                                     hc_num = (id == -1) ? AUTO_HEATING_CIRCUIT : id;
    std::shared_ptr<Thermostat::HeatingCircuit> hc     = heating_circuit(hc_num);
    if (hc == nullptr) {
        return false;
    }
    if (f > 100 || f < 0) {
        hc->ha_temp = EMS_VALUE_SHORT_NOTSET;
    } else {
        hc->ha_temp = (int16_t)(f * 10);
    }
    return true;
}

[MichaelDvP]

Should i add[1] my code to the actual thermostat together with the controlmode/program enhancements? Then you only have to edit the fallback-routine to your settings later. You also need a 0-fallback in your selection mode.

You have to add settings for each heating circuit and most people will select roomtemp and complaining if not working or always displaying zero. I think a foolproof solution is not possible.

([1] it's in my testbuild, so not remove before pushing is correct)

[proddy]

@MichaelDvP this is in b7 right? So let's do some testing with the users (specially PhillyGilly who reported the original issue)

[MichaelDvP]

@proddy, It was in this commit, but does not work because hcs without currtemp were skiped, in b7 they are not skiped.

Yes i hope the users with HA-thermostat and no roomsensor will test, also with spoofing a external temperature with topic thermostat = {"cmd":"roomtemp", "data":21.4} or something like that (This also overwrites a working sensor if you like to manipulate, setting <0 or >100 disables).

[proddy]

implemented this in the #632 branch. Still experimental.