Feature: Add support for "Hold" functionality.

[MindrustUK]

Add support for "Hold" functionality, looks like "Away" but needs a time to 'hold' at a temperature and state for.

[albarlow]

Hi,

I just wanted to express interest in this functionality.

I have made a small modification on my own fork to add attributes to show whether a Hold is active and the hold temperature and remaining duration. Only thing is, I don't think I use profiles, I think I use 'profile 0', which is what is on the device, rather than the hub. Has anyone else experimented with this?

I amended the extra state attributes section in climate.py thus:

    def extra_state_attributes(self):
        """Return the additional state attributes."""
        attributes = {}
        attributes['low_battery'] = self.data.low_battery
        attributes['hold_on'] = bool(self.data.hold_on)
        attributes['hold_time'] = str(self.data.hold_time)[:-3]
        attributes['hold_temp'] = self.data.hold_temp
        attributes['offline'] = self.data.offline
        attributes['standby'] = self.data.standby
        attributes['floor_temperature'] = self.data.current_floor_temperature
        attributes['preheat_active'] = bool(self.data.preheat_active)
        return attributes

This works for my use case, does it interfere with other peoples' use cases?

For now, I am setting the boost (Hold) using NodeRed to send a command to the hub to trigger the boost and then reading if it worked with these added attributes.

[albarlow]

Does my pull request, which has now been merged, close this issue or do you think there is scope to build the hold functionality into the integration so that it doesn't need the wider coding I wrapped around it?

[timpea]

@albarlow is it possible to set the hold temperature & time? I tried creating a scene and editing the values in the yaml file, but it doesn't appear to work.

[Trouble-51]

I now managed to get this:

type: custom:simple-thermostat

entity:

  - climate.study

layout:

  mode:

    headings: false

    icons: true

    names: true

sensors:

  - attribute: hold_on

    name: Hold

    step: column

  - attribute: hold_temp

    icon: mdi:thermometer

    name: Hold Remaining

    step: column

  - attribute: hold_time

    icon: mdi:av-timer

    name: Hold Remaining

    step: column

step_size: '0.5'

decimals: '1'

control:

  hvac:

    - heat

    - 'Off'

header: {}

But it works with input selects and of course a script:

type: entities

entities:

  - entity: input_select.set_room         (this is a list all the rooms with a thermostat, 11 in my case))

  - entity: input_select.set_temperature     (a list of temperartures)

  - entity: input_select.set_time                   ( a list of durations)

  - entity: script.start_hold_duplicate

theme: Home

title: Select

And the script:

No doubt it can be improved but have a look and let me know your thoughts

From: albarlow @.> Reply to: MindrustUK/Heatmiser-for-home-assistant @.> Date: Wednesday, 21 December 2022 at 18:45 To: MindrustUK/Heatmiser-for-home-assistant @.> Cc: Subscribed @.> Subject: Re: [MindrustUK/Heatmiser-for-home-assistant] Add support for "Hold"functionality. (#9)

Does my pull request, which has now been merged, close this issue or do you think there is scope to build the hold functionality into the integration so that it doesn't need the wider coding I wrapped around it?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[MindrustUK]

• Add option to surface "hold" controls to Dashboard, Do this per Thermostat or System Wide?
• Add input's for TIME and Button / Switch to toggle hold on and off.

[albarlow]

If I'm understanding the question correctly, it would need to be per thermostat. I would not want to have to boost every zone to boost a single zone. If you wanted to affect the whole system, you could have a script that targeted all climate entities in the system. If I remember correctly, the way I think it would happen is as a thermostat 'Preset' mode. So at the moment the choices are 'Heat' (which is Auto (timer) mode) and Standby (Off).

I couldn't figure out the code to make that big of a change to the climate entity. I was trying to use the Hive integration as a template as I know they had implemented the boost function.

That would essentially act as the 'switch/button' to toggle the hold - there would be an extra 'button' on the thermostat card (such as the ones shown below). Once you are in hold (boost) mode, the temperature control will automatically update to the boost temp and you can control the boost temperature using the regular thermostat controls. Once boost ends, it will return to the 'Auto' temp or 'Standby' temp, depending which mode you were in prior to applying the hold/boost. As to setting the time, I don't know if there's a mechanism to control it within the entity or not.

[MindrustUK]

@albarlow The question was really more to myself as notes while building out this feature and to give some sort of signal that I haven't forgotten about this.

It looks like the hold button and time will have to be separate controls (Time, or a slider + a button or switch) as you've cited in the Hive integration.

The question being that should these controls (Time setting + on / off) be configurable per thermostat or system wide, i.e. some users may wish not to see hold controls for all thermostats, where others will want to see them either on selected, or on every thermostat. This is my thought process.

Hopefully I'll have a test branch out sooner rather than later as your feedback is very much welcomed.

[albarlow]

I thought that might be the case, but went on the basis that you'd posted it in question form and same as you wanted to show there's still interest in the feature.

For what it's worth, I can see the value of both having a central system slider for those that don't want or need granular control but for me, the whole reason I went for the Heatmiser system was to have the ability to have that granular control (I moved away from Hive because it supported max 2 zones plus a hot water tank so you could have an upstairs zone and downstairs zone).

I'll be keen to beta test anything you've got once it's ready. I can mess about with things but ease of use features will help the non-power-users of my dashboards interact with the heating - it's a bit opaque unless you really know how it's been set up, even with the work done so far (though that has certainly moved things forward a lot).

[MindrustUK]

@albarlow there's an early cut of in development work here: https://github.com/MindrustUK/Heatmiser-for-home-assistant/tree/dev please test and provide feedback. Sensors and controls are now available for timers and climate devices, neo plugs are currently broken but high on my list of things to fix.

[albarlow]

@MindrustUK - I've got it installed and see the new switch and number displays. I don't know which bits are still in progress so apologies if I'm jumping the gun with any observations. I've tried to give feedback based on my impressions as a user without having a snoop of the code so I don't only try to use it the 'intended' way.

For my V1 and V2 stats

As a user, I was unclear whether the number fields are intended to be 'live' values when the boost is active or 'stored' values to apply when a boost is called using the toggle. I'm suspecting the latter? The number fields were initially blank and any time I left the device window the fields would lose their values. When I boosted using the existing hold service, it didn't populate the duration...I don't know whether, once the functionality is complete that calling a hold from the service should update the boost temp/hours/mins fields or keep them as separate approaches to controlling holds.

When I manually filled in the numbers and used the toggle, it used those numbers for the boost but when I left the device screen and came back, it had forgotten the numbers again. The toggle (once poll cycle came around) showed correct hold status whichever method I used to set the hold. Turning off the hold toggle also successfully cancelled holds, whether it had been initiated by the toggle or the service call.

I noticed that when I apply a hold with no number values populated in the field, it initially errored per the image below until I had called a boost with time values filled in. Once I had called a boost at least once in the past, if I populated the minutes but not hours or vice-versa, it defaulted the blank field to the last value used e.g. if I last boosted 1hr 30min and next time set it to hr 20min it would set 1hr 20min or if i were to set it to 2hr min, it would set to 2hr 30min.

I don't know if its just me that it's not auto-populating for or whether you found the same at all, but I think if that is resolved my issues calling the hold with an unpopulated field will be resolved. I don't know whether those fields can be set to be mandatory-popluated (i.e. you set them with a default value and if the user tries to delete the value, it won't let them save) or if that's just a 'user-beware' thing.

In any event, it's looking really good, and I think it will make it much easier to see, understand and configure holds on the stats!

[MindrustUK]

@albarlow Great feedback, thanks!

I'd say it's safe to say things are still pretty fluid across the board, but the major components in terms of numbers and switches should be near final for now.

Don't worry about jumping the gun, if the issues aren't on the list already they probably need to be! And I'm very grateful for the "Black box" user testing approach, nothing worse than missing the user requirement!

Live vs Stored fields: As it stands I didn't want to pull the hold values and have them moving while a user was trying to set a hold timer so I added a sensor for 'Hold time remaining' and opted for the hold hours and minutes to be separate 'stored' fields. I was going to use a timed duration input but that started down a rabbit hole of duration's and time zone's which rapidly got over complicated. I may raise a ticket for the Home Assistant core to allow arbitrary times without corresponding to the real world, but that's for later.

The existing hold / boost uses a different service embedded in the Climate entity. I wouldn't expect it to immediately affect anything as there will be time needed to update the sensor, however the hold duration 'should' work. I'll investigate this myself but both the hold active should become 'on' and the duration should be accurate. Please note hold status updates will only update the sensor and state only, not the hours or minutes fields.

Loosing hold hours and minutes on navigation is something I've not quite covered correctly, there's some attributes I've added in the objects that when set per instance should preserve this value but don't this is something I need to figure out. I'm not sure if I want to default these to 0 every time or preserve the last value, thinking about it this could be a configurable default value globally or per thermostat but that maybe taking things a bit too far...

The error on null value is something I know about, I saw the error in Home Assistant but as nothing died in a ball of flames I opted to focus my energy on other features and come back to the issue later.

Glad you find the changes beneficial! I'll look into the things reported and there will also be some features coming to configure hold controls enabled / disabled etc. in the future.

[heisenberg2980]

@MindrustUK could you provide a quick update of how this new "hold" funcionality is going? any estimation of when it will be available?

[MindrustUK]

Nothing significant to report at the minute. I'm struggling for time to put into this project due to competing priorities. Updates as and when they arrive, watch this space.