Closed Pierre-33 closed 4 months ago
Hello @Pierre-33,
Thanks for your message.
What you're describing is quite weird! I'd like to know what's happening. You can find on the project GitHub a lot of logging configuration examples so as to have some more info. We could see the incoming requests and try to check what is happening. However, I also need to see your complete yaml setup file please.
Here is the complete Yaml
esphome:
name: clim-bureau
friendly_name: Clim Bureau
esp8266:
board: esp01_1m
uart:
id: HP_UART
baud_rate: 2400
tx_pin: 1
rx_pin: 3
# Enable logging
logger:
baud_rate: 0
# Enable Home Assistant API
api:
encryption:
key: xxx
ota:
platform: esphome
password: xxx
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Clim-Bureau Fallback Hotspot"
password: xxx
captive_portal:
external_components:
- source: github://echavet/MitsubishiCN105ESPHome
climate:
- platform: cn105
id: hp
name: None
update_interval: 4s
compressor_frequency_sensor:
name: Compressor Frequency
vertical_vane_select:
name: Vertical Vane
horizontal_vane_select:
name: Horizontal Vane
#remote_temperature_timeout: 60min
debounce_delay : 500ms
sensor:
- platform: homeassistant
name: "Temperature Sensor From Home Assistant"
id: current_temp
internal: true
entity_id: sensor.clim_bureau_temperature_sensor
on_value:
then:
- lambda: 'id(hp).set_remote_temperature(x);'
button:
- platform: restart
name: "Restart"
I saw the topic about logger granularity in the documentation but I don't know which part would be relevant in debug and I'm affraid activating everything could be overwhelming. Any particular component you want in debug?
Ok thanks, First try please to set these options in the climate component. Choose the values you want for min and max. But set the target and current temperature like in this example:
visual:
min_temperature: 18
max_temperature: 25
temperature_step:
target_temperature: 0.5
current_temperature: 0.1
Then set the logger:
level: DEBUG
logs:
EVT_SETS : DEBUG
WIFI : INFO
MQTT: INFO
WRITE_SETTINGS: INFO
SETTINGS: DEBUG
STATUS: INFO
CN105Climate: WARN
CN105: INFO
climate: WARN
sensor: WARN
chkSum: INFO
WRITE : WARN
READ : WARN
ACK : DEBUG
Header: INFO
Decoder : DEBUG
CONTROL WANTED_SETTINGS: INFO
UPDT ITVL: DEBUG
CYCLE: DEBUG
Here is a video of the issue with the logging option you requested and the change in the climate section :
Hi guys! I can confirm pretty much similar condition. My behaviour is slightly different, though: my climate cools one degree lower than set: if i set cooling to 25 it cools to 24, if i set to 26 it cools to 25 etc... only difference from Pierre is that in my case it seems that reported temperature doesn't display 1 degree lower, it really cools down to shown temperature. My logger is pretty much the same as above from Pierre, i also get "wanted" target -1°C.
all this is very interesting but I don't have any idea of why you guys are facing these issues... I dig...
my climate cools one degree lower than set: if i set cooling to 25 it cools to 24, if i set to 26 it cools to 25 etc... only difference from Pierre is that in my case it seems that reported temperature doesn't display 1 degree lower, it really cools down to shown temperature.
I think this is just the heatpump itself overshooting, either because the unit is a bit large for the room, or the temperatures are mild and you are bumping up against the min output. Are you getting a lot of short cycles right now?
Either way, if your unit is displaying the setpoint you entered, and displaying the actual temp you are measuring, then the integration is working properly, it is just the heatpump overshooting for other reasons (which is common).
Room is definitely not too big… interesting is that i have more climates in my house (in bigger rooms, too) and this is happening only on this one… today i moved xiaomi sensor on other side of the room to see if there will be any difference. Interesting is that difference is very accurate at 1 degree…
I agree with you that integration seems to work properly, since current temperature IS changing;
I do wonder, however…is there any way to know if climate works on internal sensor or external one? Yaml has “fail-safe” function: if there are no data from external sensor for 30 minutes it switches to internal, but how (if at all) can i know that it did switch to internal?
Well you can check at the logs for that info it is a fall back situation. As soon as the heatpump receives a new external temperature it is going back to external mode.
Grasping at straws a bit here, but in other integrations I've found some value discrepancies as a result of not keeping a consistent data type through the calculations. For instance, casting a float value as an int will simply truncate the decimal, meaning 1.9 will be displayed as 1, rather than 2, which would be the intuitive rounding.
For example:
{% set value = 1.8 %}
Raw value = {{ value }}
Cast to int = {{ value | int }}
Cast to float = {{ value | float }}
Round and then int = {{ value | round (0) | int }}
results in this output:
Raw value = 1.8
Cast to int = 1
Cast to float = 1.8
Round and then int = 2
When I see "off by one" errors, this is one thing I look at.
In my lambda for external temperature settings, I specifically cast the variable as a float (because I'm doing a calculation with it). But if I recall, I had to do that because by default it was casting it as an int, and truncating the value.
services:
- service: set_remote_temperature
variables:
temperature: float
then:
# Select between the C version and the F version
# - lambda: 'id(hp).set_remote_temperature(temperature);'
- lambda: 'id(hp).set_remote_temperature((temperature - 32.0) * (5.0 / 9.0));'
- service: use_internal_temperature
then:
- lambda: 'id(hp).set_remote_temperature(0);'
Another would be errors in unit conversions and rounding, though it appears you are using C as the native temperature unit. For F users, you can get a situation where, say 73F can be interpreted as either 22.5C or 23.0C depending on the "direction" of the calculation, and when the rounding happens. This can result in some ambiguous setpoints when you are around 23C/73F, 18C/64F, and 28C/82F.
Ok, so all those discussions about overshooting made me remember that last summer to compensate overshooting I actually wrote an automation that reduce of 1 degree the temperature I feed to the heatpump... so the temperature sensor you saw in my video is not the one I feed to the heat pump and everything is actually working exactly like it should.
TLDR: This is a mistake of mine and their is not actual issue.
Since their is a lot of other comment talking about something apparently similar, I let you decide wether you want to close the issue or not.
Thanks for your great integration and your quick answer and sorry about the fake issue :-/
I did some further testing... First, i installed Geoff's FW, just to double-check: result was also 1 degree lower temperature with external sensor.
Then i switched to internal sensor for one day. Result was ALSO 1 degree to low! So, i can't think of anything else than poor internal calibrating or something in this direction. Especially since i have another (newer model) climate also from Mitsubishi which cools to decimal of degree correct, while epshome FW is exactly the same (checked, double-checked, triple-checked...)
Now i think I'll "recalibrate" my homeassistant sensor in esphome with filter --> offset.
Hi I'm using an external sensor for temperature monitoring like in your example:
This seems to work as the temperature display in Home Assistant for my heatpump is the same as the one of my sensor (26°), but as soon as a I turn on the heatpump, the temperature drop to 25° (my external sensor stay at 26°), and a few seconds after I turn off the heatpump it get back to 26.
I used the same setup with the original geoffdavis component that worked like a charm, but maybe yours need a slightly different setup?