Set zwave_js climate precision to tenths for F

[chilicheech]

Breaking change

Zwave_js climate devices that report their temperature in Fahrenheit will now report in tenth precision instead of whole precision, when the device supports it. Previously, when those devices reported a temperature of, for example, 67.6F it would be rounded and reported in whole precision as 68F. Those devices will now report the temperature with tenth precision, thus 67.6F. This means that if you currently have automation that depends on the temperature reported by these devices you may have to adjust their functionality to work properly with how the temperature is now being reported.

Proposed change

This is a change to the temperature precision of the zwave_js climate entities (or thermostats) that report their temperature in Fahrenheit. Currently, these entities report their temperature with whole precision. Meaning that, if the temperature reported by the climate/thermostat device is 67.6F the entity will round it and report it as 68F. This change will make it so that the entity reports more accurately in tenth precision, so that it will report 67.6F instead of 68F, which is what the climate/thermostat device reported.

This change does not affect the target_temperature_step. Meaning it won't change the precision at which the climate/thermostat entity's temperature is set. That will continue to function as it does now. This change only affects how the temperature is reported and displayed.

Please note that this change does not affect those climate/thermostat entities/devices that report in Celsius, as they already use tenth precision.

Also note that, thermostat devices that already report the temperature in whole precision will continue to do so, unaffected by this change. Meaning that if a thermostat only reports the temperature in whole precision, the climate/thermostat entity will still correctly display the temperature.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Black (black --fast homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

• No score or internal
• 🥈 Silver
• 🥇 Gold
• 🏆 Platinum

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[MartinHjelmare]

Looks good!

[chilicheech]

Here are some screenshots:

Difference between MQTT and ZWaveJS thermostats before the change:

Difference between MQTT and ZWaveJS thermostats after the change:

The setting of the temperature remains unchanged and still uses a whole precision: