* Add Z-Wave thermostat fan entity
* Fix failing test, increase number of entities to 27
* Add tests to improve coverage
* Take back unrelated changes to climate.py
* Clean up guard clauses, use info.primary_value, and make entity disabled by default
* Fix tests
* Add more tests for code coverage
* Remove unused const
* Remove speed parameter from overridden method since it was removed from entity
* Address PR comments
After some debugging, it seems room.canonical_alias contains the
room alias that matches the room_id_or_alias value but is not
contained in room.aliases (which is empty). As a result, the
matrix component thought the room wasn't alread joined, joins
again, and this replaces the previous room which had the listener.
This resulted in the component callback not being called for new
messages in the room.
This fixes#66372
* Fixed the issues related to auto mode
I was having the same issues as described in #63403, specifically, the error stating that Mode 7 is not valid, only Heat, Cool, Off when trying to do anything while the thermostat is set to Auto. This error originates with the way the Lyric API handles the modes. Basically, when one queries the changeableValues dict, you get a mode=Auto, as well as a heatCoolMode, which is set to either Heat, Cool, Off. Per the documentation, heatCoolMode contains the "heat cool mode when system switch is in Auto mode". It would make sense that when changing the thermostat settings, mode=Auto should be valid, but it's not. The way the API understands that the mode should be set to Auto when changing the thermostat settings is by setting the autoChangeoverActive variable to true, not the mode itself. This require changes in the async_set_hvac_mode, async_set_temperature, and async_set_preset_mode functions. Related to this issue, I got rid of the references to hasDualSetpointStatus, as it seems that it always remains false in the API, even when the mode is set to auto, so again, the key variable for this is autoChangeoverActive.
While I was working on this I also noticed another issue. The support flag SUPPORT_TARGET_TEMPERATURE_RANGE had not been included, which did not allow for the temperature range to be available, thus invalidating the target_temperature_low and target_temperature_high functions. I added this flag and sorted out which set point (heat vs cool) should be called for each of them so things work as expected in Lovelace. I have tested all of these functionalities and they all work great on my end, so I thought I'd share.
* Update climate.py
* Update climate.py
Fixed two additional issues: 1) When the system is turned off from Auto, the heatCoolMode variable becomes 'Off', so when you try to restart the system back to Auto, nothing happens. 2) I now prevent the async_set_temperature function from being called with a new set point when the system is Off.
All changes tested and functional.
* Update climate.py
* Update climate.py
Return SUPPORT_PRESET_MODE flag only for LCC models (i.e. they have the "thermostatSetpointStatus" variable defined). TCC models do not support this feature
* Update climate.py
After playing with the official Honeywell API, I realized it doesn't like to received commands with missing data, i.e., it always wants to get a mode, coolSetpoint, heatSetpoint, and autoChangeoverActive variables. This was causing some random issues with changing modes, especially from coming from off, so I modified the async_set_temperature, and async_set_hvac_mode fuctions to always send all pertinent variables.
* Update climate.py
* Update climate.py
* Update climate.py
* Update climate.py
* Clean code and test everything
Alright, sorry for the multiple commits, fixing this properly took a fair bit of testing. I went ahead and cleaned up the code and made the following big picture changes:
1) The integration now supports the Auto mode appropriately, to include the temperature range.
2) There's a bug that actually manifests when using the native app. When the system is 'Off' and you try to turn it on to 'Auto', it will turn on briefly but will go back to 'Off' after a few seconds. When checking the web api, this appears to be related to the fact that the heatCoolMode variable seems to continue to store 'Off', even if the mode accurately displays 'Auto', and the autoChangeoverActive=True. So to overcome that inherent limitation, when the system is 'Off' and the user turns it to 'Auto', I first turn it to Heat, wait 3 seconds, and then turn it to 'Auto', which seems to work well.
* Update climate.py
* Fixed errors
* Fixed comments that were resulting in error.
* Update climate.py
* Update homeassistant/components/lyric/climate.py
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
* Update homeassistant/components/lyric/climate.py
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
* Update climate.py
I removed a blank line in 268 and another one at the end of the document. I also fixed the outdents of await commands after the _LOGGER.error calls, not sure what else may be driving the flake8 and black errors. Any guidance is much appreciated @MartinHjelmare
* Update climate.py
* Update climate.py
corrected some indents that I think were the culprit of the flake8 errors
* Update climate.py
I used VS Code to fix locate the flake8 errors. I ran black on it, so I'm hoping that will fix the last lingering black error.
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
* Change debug level of integration reload after config update to debug
* Remove extra .keys() call for dict itreation
* Remove unecessary type check
* Remove unused LOGGER reference
