Ability to set current temperature

[fresnoboy]

It would be good to be able to set the current temperature as well as the target temperature. The temp sensor in the unit, especially for the large convention ducted units, is not an accurate representation of the actual room temps.

Being able to set this current temp based on one or more sensors in the room would be much more accurate and result in better comfort.

[jhuang0]

That in no way shape or form is going to be supported at the integration level. You can make the request at the Home Assistant level - but they'll tell you the same thing I'm going to tell you: it's a bad idea.

If you want to do something like that, you can do so by writing your own automation.

[fresnoboy]

Thanks for the quick response, but I am curious as to why you think it's such a bad idea? I may be missing something and want to understand what that is!

This is a capability in the esphome driver to control the heatpump using an 8266: https://github.com/geoffdavis/esphome-mitsubishiheatpump and that supports home assistant setting the current temp as well as using the internal temp of the indoor unit.

Thanks, and apologies if I am being obtuse.

[danielgoepp]

I would agree, that doesn't sound like something to complicate the integration with. As there are hopes of getting this integration merged into core, keeping it as simple as possible to start is key to its acceptance. However even after this it sounds to me like the calibration of the device is something for Kumo (or Mitsubishi) to handle, not the integration or even the automation. I would recommend you look into the Kumo Wireless Temperature & Humidity Sensor Setup Model: PAC-USWHS003-TH-1 which could improve the accuracy of your reading. Or, just do the simple math. Know you are 2 degrees shy for example, and always set it 2 degrees higher, for example.

That ESP driver is the actual hardware that plugs into the unit, and is a more complicated and low level application. If they choose at that level to allow this kind of thing, great. This integration just relies on the existing wireless integration provided via the Kumo Cloud service, not plugging into the heads themselves.

Interestingly, I barely care what the actual temp is, I care how I feel. I'm dialing it up and down a little all the time to adjust for my perceived temp or comfort level, not a specific number. Not to say there isn't a justification for wanting to calibrate your unit! I get it, but I do stand by that is something the thing creating that number should do, not the thing reading and presenting it. Contact Mitsubishi and tell them there is no way to get their unit to report an accurate number :) I presume the temp is wrong in the Kumo app too, since it's what's getting reported by the unit itself?

[dlarrick]

I agree with the comments here. The purpose of this integration is to accurately reflect what the Mitsubishi unit is reporting. To do otherwise would make it too hard to tell when there is some problem -- as there was with the original integration, converting back & forth between F and C too many times and losing information.

I'll point out, though, that my unit linked to one remote sensor uses that sensor's temperature for both reporting and deciding what heating/cooling is needed. With two sensors, I'm sure it's doing something that makes sense to the Mitsubishi engineers -- averaging them, choosing the one furthest from the setpoint, etc. Some thermostats do even smarter things -- Ecobee, for example, does a weighted average of its sensor inputs based on motion sensed in the room.

But here's the thing: it's entirely possible to do smart things like these in HomeAssistant itself The Mitsubishi sensors don't have motion sensors, but if you have them from another integration you can implement something like what Ecobee does if you like. But that's where it belongs: in your automations.

[fresnoboy]

Guys, thanks for the feedback.

I will point out however that the Mitsibushi VRF (Variable Refrigerant Flow) units don't run just on and off like a normal HVAC unit, they modulate the compressor so that the bigger the delta T between the room temp and the target temp, the more the refrigerant flow is used. This is the reason why people don't use their PAC-US444CN-1 adapters with Ecobees or Nests. You lose that variable flow based on Delta-T that makes the system so good at never under or overshooting in a given zone.

I had seen the indoor sensors, but they are a bit ugly to stick on a wall. I was actually hoping to use Ecobees in sort of a dumb configuration (jumpered to not actually talk to a HVAC system), where I would use HA to take the Ecobee's room temp value and feed that to the indoor unit as it's current temp, and then have the target temp track whatever the target temp was set by the Ecobee. Effectively this would allow me to control the Mitsubishi HVAC units with the Ecobees but with all the advantages of their native MHK1 or MHK2 units, and without the painful UI and cloud dependency of the Honeywell total comfort cloud system. I prefer local control!

I don't think I can do this without setting the current temp in the indoor unit, but maybe I am missing something. I guess I can go the ESPhome approach, but the Kumo seems easier to implement.

[dlarrick]

Oh, that's even worse than what I thought you were asking for. There is zero capability in Mitsubishi's API to tell the unit, "This is what you should think the temperature is". The only feature we could possibly implement in the Kumo integration is lying to HA about the temperature the unit is reporting.

To have any hope of accomplishing something like this you'd have to offset the setpoint, not the reading.

[fresnoboy]

The esphome method I mentioned earlier for Home Assistant already supports that functionality. I will go that route for the HA integration. Thank you for considering the request.