Allow Hold On temperature in 0.5 increments

[ocrease]

The hold_on service expects the temperature to be an integer, but heatmiser allows increments of 0.5 degrees. I updated climate.py and services.yaml to allow float rather than int and used the HA Developer Tools to call the service with a x.5 temperature and it was accepted:

action: heatmiserneo.hold_on
data:
  hold_duration: "01:00:00"
  hold_temperature: 23.5
target:
  entity_id: climate.zone1

hvac_modes: off, heat
min_temp: 7
max_temp: 35
target_temp_step: 0.5
current_temperature: 21.5
temperature: 23.5
hvac_action: heating
low_battery: false
offline: false
standby: false
hold_on: true
hold_time: 0:56
hold_temp: 23.5
floor_temperature: 127.5
preheat_active: false
friendly_name: Zone1
supported_features: 385

It would be nice to remove the restriction requiring an integer. Happy to raise a pull request if that helps.

[MindrustUK]

Hi @ocrease from memory I have a feeling the V1 thermostats only allow stepping as an integer, I think the V2 and above models handle 0.5 increments or 'steps'. I'll do some investigation and see if that's still the case or if firmware updates etc have happened. I know there was a "stepping" function somewhere, maybe this could be checked and logic applied based on the increment...

[ocrease]

Hi @MindrustUK, yeah I saw this in the heatmiser API docs:

Note The temperatures are no longer integers this is to allow 0.5 degree set points to be implemented. In older hardware that cannot display the 0.5 degree set point the display will be rounded down.

That note was not specifically in a section about hold temperatures so not sure if a V1 thermostat would handle the message. Mine are all v2 so I wouldn't be able to test it. My thermostats have target_temp_step: 0.5 as an attribute, maybe that could be used to help decide the allowable step for the hold temperature as well

[MindrustUK]

Ah, excellent. Thanks for investigating. I've managed to build up a selection of devices so I can test this to see what the behaviour is and go from there. Bit short on time this week, will probably be the weekend before I get a chance to give this a look so bear with me if there are no updates before then.

[ocrease]

No worries, I need to find time to upgrade to the dev branch anyway. In the meantime I am trying it out with my little hack in place.

[MindrustUK]

@ocrease The behaviour is as stated; setting a float on an older model device causes it to round down without issue. Preparing merge now.

[MindrustUK]

@ocrease New in dev, please test and let me know if you have any issues.

[ocrease]

@MindrustUK Thanks for making the change. I've installed the dev version and tried out the changes. The Hold On action works fine and allows 0.5 increments:

However, I notice that there are new controls in the device details, one of which is a number to set the hold temperature, and this doesn't allow 0.5 increments:

Notice how its highlighted in red.

A few other minor observations regarding the new controls in the dev branch:

• Is it possible to remove the "Heatmiser Neostat V2" prefix (presumably changes depending on the actual device) from each of the controls and sensors? As you can see above, you can't see what each box is for without hovering to see the full name
• Is there a reason the hold time needs to be specified in separate hours and minutes boxes? I think it uses two NumberEntity entities, couldn't you use a single TimeEntity instead?
• The hours entity has a lower case t for time (eg Hold time Hours vs Hold Time Minutes):

[MindrustUK]

Hi @ocrease Great feedback, thanks again!

On the 0.5 increments in the hold controls I forgot I'd actually need to update things outside the service. I'll change this to float too.

"Heatmiser NeoStat V2" Prefix. This was done as uniform approach across the board as without some sort of useful prefix things were getting muddled up in the UI. That's not to say it couldn't be revised just that this was the solution I chose at the time as "good enough" and decided to put my focus elsewhere. It's on my list to revisit, but cosmetics are way down the list.

RE: Number entity vs Time Entity, I did originally try using time but it didn't work out for some reason. I think it was to do with some weird time zone formatting problems. I have hold times on my list to re-visit fairly high on the list of things I want to tend to ahead of the 2.0 release of this plug-in, I'm not happy with the hours vs minutes split. As I'm sure you've already picked up on these are also not populated when a hold is set. I'd like to do something fancy like reflecting the actual hold state in this box and having it count down as well as being updatable.

time vs Time, Thanks for pointing this out. I'll patch at some stage.

[MindrustUK]

Closing @ocrease I think we've addressed the issue and there's clearly move development afoot here outside of the scope of 0.5 degree increments.