Internal temperature always reports 22°C #45
Comments
|
Thanks for all the info! Could you also take a look in the logs for the "Current Temp Response" packet? Should look something like: Mitsubishi has two different ways to handle temperature and we've run into issues in the past where certain equipment does something different than we're expecting. |
|
For some reason this doesn't show up in my logs. Do I need to change verbosity? So it looks like the 22°C is just the last thing Home Assistant registered from when it was still working. I initially configured all units to sync to the same external HA temperature sensor, so that's probably why they all report the same value. |
|
Ah, sorry, yes, logs should be logger:
level: VERBOSE
logs:
sensor: WARN |
|
It really does seem to think it's a constant 22°C 🤔 
|
|
I've monitored the Current Temp Responses over a longer period while turning the unit on and off (cooling/heating) to see how it affects the returned data. It looks like it's currently picking I'm not sure how accurate these readings are, because they seem to fluctuate a bit, but they're closer to the actual temperature. The number seems to go up when I set it on "heat" and goes back down again when I set it to "cool". I've checked the code of the SwiCago lib and echavet's component and they both seem to do the same thing: picking |
|
Update: I've switched back to echavet's component and it now also consistently reports 22°C. I'm now seriously doubting myself if it ever worked correctly after I switched from MELCloud to esphome, so let's forget about that. The room temperature is still wrong, but at least it's consistent with the other components, including SwiCago. ... or something really weird has happened that made the unit believe it's 22°C all the time. When I started with this component, I briefly had the same config on all four units, so they were all synced to the same external temperature sensor in HA. After that, I've removed it from the config for three of the units in order to switch back to the internal thermostat. I know it sounds far-fetched, but could that have anything to do with it? |
|
Another update: It's definitely related to the fact that I (temporarily) configured an external temperature source in the past. I've just added an external source and then switched back again to the internal source and now it continuously reports 22.5°C as the current temperature. I can't find the relevant code in this component, but looking at SwiCago, I see the following snippet: if(data[6] != 0x00) {
int temp = data[6];
temp -= 128;
receivedStatus.roomTemperature = (float)temp / 2;
} else {
receivedStatus.roomTemperature = lookupByteMapValue(ROOM_TEMP_MAP, ROOM_TEMP, 32, data[3]);
}Could it be that my heatpump is supposed to get it's current temp using the If that's the case, |
|
Well that's puzzling for sure. You're definitely on the right track. As you've found, because
In your ESPHome config, add a sensor: sensor:
- platform: template
id: fake_temp
name: "Fake Temperature"
lambda: |-
return 24.5;and then add it to the Mitsubishi ITP section: climate:
- platform: mitsubishi_itp
temperature_sources:
- fake_temp
...This should give you a "Temperature Source" select menu available in Home Assistant. Switch to Fake Temperature, and presumably the temperature will show 24.5°. Switching back to "Internal" will send a packet to the heat pump that should tell it to use its internal sensor. See if that fixes things. This might already be what you're doing with the "external source", but just want to confirm so we're on the same page. I'm not sure I've seen |
|
Yeah, that's exactly what I did to add the external source, but I'll do some more experimenting with it. Not sure if I updated the "Temperature Source" select option for example. The reason I mentioned The other values that I saw changing looked like it was just going up every minute (like some sort of timer) and the last byte, which I assume is a checksum. I'm not sure if my unit is supposed to use I'll go down this rabbit hole and report back if I find anything interesting. |
|
Yeah, switching it to the So, this is kind of a weird edge-case, but it looks like the reported room temperature of the heatpump can get stuck at some fixed value when:
Now it is impossible to get the heatpump to report the correct temperature, unless:
If it's possible to send the "Use internal thermostat"-signal to the heatpump on boot when there's no other temperature source(s) defined might prevent other people from running into the same problem. Thank you for your patience! |
|
Hooray! But also weird. My experience with my MSZ-GL06NA has been that if no new remote temperature packet was sent, after 10 minutes the unit will automatically revert to using the internal temperature. (i.e. I see the behavior you do where the current temperature is stuck, but then after 10 minutes it just switches to internal and unsticks) I think your suggestion of sending "Use Internal" on boot is probably good idea-- I can't immediately think of any reason why this would cause problems for anyone. I'll leave this issue open to track that fix. As you continue in your testing though, if you could do us a favor: If you convert the values in If they seem like reasonable outdoor values, I'll probably go ahead and add that as a sensor (we just haven't had a unit that supports that to test on yet). |
|
Yeah, my MSZ-HR25VF doesn't seem to do that automatically. As you can see in the HA graph a few comments up the unit was blasting on 18°C all night because it kept thinking it was still 22°C in the room. And I definitely had no other Temperature Sources configured. As for I can test this for a longer period and compare it to the readings of my other thermostat, but then I would need the sensor configured in the component. If you have a branch or patch I could run to help test this, please let me know. |
|
Okay, so I just pushed 14e75bb to the I made a note in #44 to preemptively send an Internal Temperature packet when we only have the one source; there might be some other refactoring so I'll just keep it all together over there. Closing this issue for now since your temperature is unstuck, but definitely please let me know if Outdoor Temperature is working successfully. |
|
Thanks @Sammy1Am, I've installed the latest version on all my units and started tracking the outside temperature in Grafana: 
Some preliminary findings:
I'll keep monitoring them for a couple of days, but either the sensor is really inaccurate or it's not really the outside temperature. Maybe it's some kind of internal gas/fluid temperature. |
|
Looks like the sensor for the outdoor temperature is not sent to HA correctly: Only the initial state of the sensor is published correctly, after that I only get NaN's. I think this is because you directly update state instead of |
|
Yup, that would do it. Got confused looking at the binary sensors instead. Should be fixed, thank you. |
|
I've installed the latest @dev branch on all my units and I can confirm the sensor now gets updated correctly. Thanks for the fix! Now, as for the results... this is my reference graph, the outdoor temperature as measured by my central heating unit: 
The indoor temperature as reported by esphome for all units: 
And finally, the outdoor "temperature" ( 
Some observations:
I'm starting to think that
|
|
I just noticed that the heat pump switched to "inactive": 
This also stabilizes the outdoor sensor: 
|
🤔 |
|
Out of curiosity, do all of your units report outdoor temperature sensor support in your 7B? (Byte 9, flag 0x20). This flag came from the JP mobile app and was tested to be Mostly Correct:tm: on my NA units, but it's possible that there's some weird quirk for EU/AUS units. Given these units tend to generate quite a noticeable temperature change in their immediate surroundings by virtue of their purpose, I wouldn't be surprised if the temperature readouts aren't particularly accurate. This almost seems correlated by the fact that they only move in 1 degree Celsius increments (something I've noticed on NA units as well), and the fact that this isn't really used anywhere either. |
|
@KazWolfe I assume you refer to the extended connect stuff, right? I've just checked all units and they all report the same value: All my units are from the same series. The only difference is the capacity (2.5kW vs 5kW). For some reason one of my units started reporting 0x01 for a couple of minutes (which translates to -63.5°C). The reason I'm doubting we're looking at some temperature related to the outdoor unit is the fact that the value doesn't change at all when the unit is inactive (it doesn't even have to be turned off completely). One of them kept reporting a consistent 20°C all night, while the actual outdoor temperature was about 10°C. |
|
-63.5°C weirdness aside, the purpose of the sensor is probably to help systems with defrost/auxiliary heat, so it might only be needed when the system is running. I.e. I don't know if this value was ever supposed to be shown to end users anyway. |
|
I suspect something similar - this is some semi-diagnostic sensor that we're exposing because we can. Strangely though, I cannot reproduce this on my unit - even with it off, it tracks properly. I don't think I've ever seen it as 0x01, but I'll look more. It's very possible this field is overloaded, is different per-region, or is just something else we don't fully understand yet. |
|
Yeah, I think so too. Doesn't look like the sensor provides any useful information for the end user, although it would be nice to get a complete spec of the protocol eventually. In any case, I'll keep monitoring it until you decide to remove it 😊 If there's anything else I can do to help, please let me know. Thanks! |
|
For some reason the reported value seems to stabilize. This is the "real" outdoor temperature and the reported value from the unit for the last 48h: 
And, for completeness, the indoor temperatures (target + current): 
The indoor unit is turned off automatically by a HA automation at midnight and the turned on again at 5:30PM. It reports 0x01 during the night, but when it's active the reported temperature seems to be pretty accurate (going up during the day, going down at night, pretty consistently 1 or 2 degrees above what my central heating was reporting). No clue what happened the first day though, because the values were all over the place. |
|
For posterity, here's my own log with my heat pump/outdoor sensor:
It looks like yours also mostly follows this behavior, but interrupts at odd cases. I don't yet have a good explanation for why your unit is doing this, though I'll definitely try to experiment more with my units to see what's going on with them. Regarding your temperature jump, is your system purely the ESP or do you have a thermostat or other control unit connected? We've seen that certain units will "fall out" of auto mode in favor of a thermostat offering its own dual setpoint support. As a general note for cleanliness, can you please create a new issue for each individual problem you have so that we can track them accordingly. |
|
After monitoring the outdoor temperature for a couple of days it definitely looks like it's pretty much consistent with reality. The only difference being that my unit is returning 0x01 when it's not active/turned off. 
I'll leave it up to you to decide if the sensor is valuable enough to keep around :) For the record: My system is purely the ESP indeed. I started with MELCloud and the "official" wifi module on the CN105, but switched to esphome when they messed up their API for the third time in a row (TLS issues, rate limiting issues, etc.). Three of my units are using the internal thermostat, for the fourth one I'm using another sensor in HA as temperature source. I do have an issue with that, though, because the unit keeps switching back to the internal thermostat by itself. Sometimes after 7 minutes (which I know is the default "time-out" for additional temp sources), sometimes after 10 or 20 minutes... and it does not switch back automatically. I'll do some investigation and will open a new issue once I get some more details. Unless you want me to do some further digging, you can probably go ahead and close this issue. |
You may already be aware of this and your issue may be entirely unrelated, but just in case you've missed it, the documentation has this warning: "IMPORTANT: This component does not poll the sensors explicitly, but rather subscribes to update events on the sensors. If no updates have been received for 7 minutes, the equipment will be switched back to its internal temperature sensor. This means that even if the temperature hasn’t changed, the sensors need to publish updates. This may require the use of e.g. |
|
@paravoid Thanks for this! I was not aware of the (updated) documentation, but I found it. The old docs on the muart-group website do mention the "7 minutes" part, but are missing the rest. This is probably exactly what I'm running into, as the current temperature obviously doesn't change every 7 minutes. I find the docs about - platform: homeassistant
id: woonkamer_temperature
name: "Woonkamer Temperature Sensor"
entity_id: sensor.inhouse_temperature
force_update: true
filters:
- lambda: return x;Which (obviously?) doesn't work, because this is not a sensor that publishes state changes from some internal component to Homeassistant, but a sensor that provides updates to esphome based on an sensor defined in HA. (Correct my if I'm wrong, I'm new to the whole esphome stuff). So this probably means that my source sensor ( So, would it be fair to say that the preferred way of getting this to work semi-reliably is to set-up the |
|
You are correct, the
More or less, yes. I was able to set The danger with just publishing every minute is that if the sensor breaks (runs out of battery, etc.) the ESP/heat pump will potentially keep thinking Heat or Cool is needed forever. You could probably add a check in the automation to make sure the value has changed at least in the last 30-60min or something just to make sure the sensor is still working (and stop publishing values if it's not so the unit can fall back on the internal sensor). |
I have four units (3xMSZ-HR25VF and 1xMSZ-HR50VF) and I have been running the integrations from both geoffdavis and echavet on a Wemos D1 mini for a couple of weeks before switching to this one.
For the unit in my living room, I'm using an external thermostat (a sensor in Home Assistant) and that seems to be working fine. For the other units, I'm using the internal temperature and that doesn't seem to be working. On both the
devandjune-improvementsbranches the "Current Temperature" is stuck at 22°C. Since the thermostat was working on the components from geoffdavis and echavet, either my config is wrong, or I'm running into a bug.my config (the relevant part):
Extended connect response:
If there's anything else I can do to help diagnose this issue, please let me know.
The text was updated successfully, but these errors were encountered: