Google Nest issues after upgrade -> 6.3.0 #518
Comments
|
Hello @sapphonie, Thank you for your report, this really thing to be a bug introduce with 6.3.0 and Google Nest thermostat and Farenheit conversion. I have to find out what happens (thanks for the logs). Please stay in 6.2.9, but because I'm not in Fahrenheit it is complex to reproduce. I have many problems in the past with F° (see: old issue #240, #38). @mag2352 solves the issue for me. Maybe he can have a look is something is broken with 6.3.0. Are you on HA 2024.10 ? I don't have tried with this release and I see some change on Thermostat with this release |
|
I haven't updated to 6.3.0, so I haven't observed this issue. I will look into it soon. Does the change in code for issue #508 between 6.2.9 and 6.3.0 cause the issue? I am also on 2024.9.3. Hopefully I can get back to you in a couple of days. Edit: That unit conversion is failing from the Google Assistant integration... that's interesting. I hope this isn't a google specific issue, since I don't have a nest. |
|
Thank you @mag2352 . I guess this is the #508 change which introduce this. When reverting back to 6.2.9 @sapphonie says that is issue is not preset. I don't have change so many things in this release. |
I also tried updating to HA 2024.10, and 6.3.0 is necessary on my system due to the issues in #508. So I'm not sure if this is a Google Nest specific problem, since I think 6.3.0 is a necessary update for 2024.10. Does anyone else have the issue described in this post? |
Yes ! It have been done for that. |
jmcollin78
added
not reproduced
|
Also @sapphonie, why is it in the second set of logs you posted that HA is trying to convert from Fahrenheit to Celsius? Is your system using Celsius as the default unit? It seems you are expecting to see Fahrenheit, yet HA is trying to convert Fahrenheit back to Celsius. Edit: Considering the America/New_York time zone (and the VT temperature unit of F), I'm going to assume you are using Fahrenheit. Are you able to try another temperature sensor and confirm if the issue still exists there? Can you also confirm if you use the TPI algorithm or Central Config in VT's settings (just confirming that the changes to those 2 features between 6.2.9 -> 6.3.0 are not the issue here)? |
jmcollin78
added
developed
|
Try this fix release please: https://github.com/jmcollin78/versatile_thermostat/releases/tag/6.3.1 This fix the error message I saw in your log: "ThermostatOverClimate object has no attribute __attr_preset_modes" |
Yes, I use F, I already tried another temp sensor, and tried with/without a central cfg setup. Going to update to 6.3.1 and see if it's resolved. |
|
Can still repro, no log error spew, but cool does not kick on - this is debug logs after i turn the temp from 68 to 67 while the temp sensor i have set up is showing 75: I also see in logs occasionally. |
This is the new error message replacing the exception stacktrace you had before The target temperature doesn't have value in your case. |
Could this be related to #497 ? |
|
I guess not. It seems to be specific to Google Nest and Fahrenheit |
|
Hey, I put myself inside the conversation as I got a similar behavior with my underlying climates (Atlantic AC). Versions :
State of my underlying climate : hvac_modes: off, heat_cool, cool, heat
min_temp: 16
max_temp: 30
fan_modes: auto, on
current_temperature: 22.8
temperature: null
target_temp_high: null
target_temp_low: null
fan_mode: auto
occupied_cooling_setpoint: 2150
occupied_heating_setpoint: 2100
system_mode: [<SystemMode.Off: 0>]/off
friendly_name: Clim bureau JD Thermostat
supported_features: 395When comparing #510 code (underlyings.py) : async def set_temperature(self, temperature, max_temp, min_temp):
"""Set the target temperature"""
if not self.is_initialized:
return
# Issue 508 we have to take care of service set_temperature or set_range
target_temp = self.cap_sent_value(temperature)
if (
ClimateEntityFeature.TARGET_TEMPERATURE_RANGE
in self._underlying_climate.supported_features
):
data = {
ATTR_ENTITY_ID: self._entity_id,
"target_temp_high": target_temp,
"target_temp_low": target_temp
}
else:
data = {
ATTR_ENTITY_ID: self._entity_id,
"temperature": target_temp,
}and action form (on the underlying climate) : I quickly fix the code for a live test, and doing this works well : # Issue 508 we have to take care of service set_temperature or set_range
target_temp = self.cap_sent_value(temperature)
if (
ClimateEntityFeature.TARGET_TEMPERATURE_RANGE
in self._underlying_climate.supported_features
):
data = {
ATTR_ENTITY_ID: self._entity_id,
"target_temp_high": target_temp,
"target_temp_low": target_temp,
"temperature": target_temp # Line added
}
else:
data = {
ATTR_ENTITY_ID: self._entity_id,
"temperature": target_temp,
}Maybe you was not able to test it ? |
|
Thank you @jdeksup , you are totally right, the temperature is missing in TARGET_TEMPERATURE_RANGE data structure. I cannot test that myself because I don't have such thermostat but you have found the trick. Many thanks for this. I will fix that rapidly tomorrow. The VTherm of @sapphonie have the same capability (TARGET_TEMPERATURE_RANGE), so I guess this will fix also its case. |
|
I have put the fix into a beta release https://github.com/jmcollin78/versatile_thermostat/releases/tag/6.3.4.beta2 Because I cannot test it myself, can you please give it a try and let me know if it fixes the bug ? |
|
Please give a try to this release and let me know if the issue is still there. I hope not becaue of the important fixes this release contains: https://github.com/jmcollin78/versatile_thermostat/releases/tag/6.3.4 I keep it open for one or two weeks |
|
@jmcollin78 you're welcome ! Many thanks for this project as it is very useful and thanks for the fix. |
|
Works as expected here too. Tysm!
…On Sun, Oct 13, 2024, 4:26 PM jkreiss-coexya ***@***.***> wrote:
@jmcollin78 <https://github.com/jmcollin78> you're welcome ! Many thanks
for this project as it is very useful and thanks for the fix.
I tried 6.3.4 today and it works as espected with my AC.
—
Reply to this email directly, view it on GitHub
<#518 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADU3EGIAKYLAO74EHMHARU3Z3LJRDAVCNFSM6AAAAABPG3M3BSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBZGEYTGNRWGE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Errrrrrrrrrr... Maybe not, I'm seeing a lot of sudden weird behavior where my thermostat will get yanked like, 6 degrees lower from a manual set target temp, and also seeing 429 errors in my logs... there may be more work to do haha |
What are the errors please ? |
|
Latest vers 429s are likely a result of me "fighting" it and pulling the temp back down to intended values |
|
Seems to only happen on manual preset, setting to comfort/etc I don't see any strange behavior, at least so far |
|
Can also see when manually changing heat cool mode |
sapphonie
changed the title
This is possible if the device sends its state before any setpoint command are send to it before. I imagine this is rare but possible. I will add more test for this case. |
For this error, the code of Nest component is the following: the error is when calling: trait.set_heat(temp) but I have no idea of why this calls fails in HEAT mode. |
|
For the first error message: |
|
Have not seen any errors or strange issues since updating to latest version as of now. Also recreated my config for good measure. Probably good to close. |
Version of the custom_component
6.3.0
Configuration
If it is releveant to regulation performance or optimisation some curves are needed
N/A
Describe the bug
I'm trying to:
And I expect:
But I observe this ....
✔️ I read the documentation on the README.md file and I don't find any relevant information about this issue.
Logs
Upon trying to change temperature:
Switching to Heat/Cool instead of Cool initiates cooling, but then I see
in logs.
Reverting to 6.2.9 fixes the issue for me.
It also looks like Thermo target temp low / high are getting set in C rather than in F -
Please let me know if you need anything else from me. Thanks!
The text was updated successfully, but these errors were encountered: