Feature: Adding support for changing profiles

[richhalliwell]

It would be a huge help to be able to change the profile a stat is currently reading. Editing the profiles is okay still in the native app, but to be able to create an automation for stat to switch between 'working from home mode' and 'i'm out the house' mode the day before would be helpful. this is much more powerful than setting a 'hold' as i can create automations that reset after 24 hours
new docs show profiles are accessible

[MindrustUK]

What sort of thing did you have in mind? The profiles look available in the API as you've suggested. I'm not sure I could surface anything immediately useful in the HASS UI, I should be able to expose an attribute you could then manipulate as you see fit?

[andriuss-amd]

It would be a huge help to be able to change the profile a stat is currently reading. Editing the profiles is okay still in the native app, but to be able to create an automation for stat to switch between 'working from home mode' and 'i'm out the house' mode the day before would be helpful. this is much more powerful than setting a 'hold' as i can create automations that reset after 24 hours
new docs show profiles are accessible

You can try Node-RED for that. It can talk to home-assistant and achieve a fairly powerful automations.

[richhalliwell]

What sort of thing did you have in mind? The profiles look available in the API as you've suggested. I'm not sure I could surface anything immediately useful in the HASS UI, I should be able to expose an attribute you could then manipulate as you see fit?

Yes that world be great. To be able to read and update the active profile on a star using its ID via an attribute. Do you think this is easy to implement? Trying to get my system setup for winter and I'd like to be able to make Alexa commands like 'I'm working in the living room tomorrow' and it would replace a profile that only heats it in the evening to one for the whole day then roll back after 24 hours. I can do the other bits but the only option for Neo is to create a delay script to simulate a profile with delay timers. It is much neater to change a profile from evening only to all day then back 24 hours later

[richhalliwell]

I think i'm on the right track with something like this:
` @Property
def profile_id(self):
"""Return preset modes."""
return self._profile_id

def set_profile_id(self, **profile_id):
    """Set preset mode."""
    if profile_id == self.profile_id:
        return
    else:
        self._profile_id = profile_id
        self.json_request({"RUN_PROFILE_ID":[int(kwargs.get(ATTR_PROFILE_ID)), self._name]})`

What i can't work out is 1) is this close to right 2) how do i add new custom attributes that are outside of the climate standard attribute sets. Also not sure if i'm using kwargs in the right way. From the API docs the call i need to make is something like:

{“RUN_PROFILE_ID”:[25,"Kitchen"]}
where '25' is a number between 1 and 100 - and 0 is reserved - it may set it back in comfort control mode setting to 0.

[richhalliwell]

Any updates?

[PhillyGilly]

I have a different but similar challenge. My hot water is heated by Solar thermal with gas back-up. The solar thermal heats the full tank but the gas only heats the top part of the tank. In the winter I heat the water in the morning and evening using gas. In the summer I only use gas in the evening. As the tank is heated by solar thermal in the day, this basically reduces the amount of gas needed to in the evening, and reduces it to zero on any sunny days. I have "HW winter" and "HW summer" profiles set up in my neostat HW clock timer. It works fine in the winter and in the summer, but of course in spring/autumn I end up using gas to heat water when I could use solar, because nobody wants to have a cold shower. I am currently testing the HA Home forecast.solar integration and I think that is accurate enough to be useful. So what I would like to do would be to select a profile to run in my neostat depending on the forecast solar. If this isn't possible another option would be to run permanently on winter profile and get HA to switch the neostat HW off in the morning if the solar forecast exceeds a threshold. However that would go against my (well actually my wife's !!) fundamental principle that key services (e.g. hot water) have to work even if HA stops working. So setting a profile to run in a neo-stat is preferred to having HA running a profile.

[PhillyGilly]

@richhalliwell is there any progress in this idea?

[MindrustUK]

Switching profiles, can use a select entity to present these in the UI, not sure how to setup or surface a duration in a nice way. Maybe another good candidate for a custom service and surface a sensor / current profile mode as a sensor in the dashboard / UI.

[ocrease]

I've been experimenting with this. So far I have a select entity that shows all the current profile and allows changing to other available profiles:

The list of profiles is different for a Timer.

I would like to also add sensors for:

• Profile Temperature (Or Profile State for a timer)
• Next Profile Time (eg when does the next profile level start)
• Next Profile Temperature (What is the temperature of the next level. Not needed for timers, since the next state is just the opposite of the current state)
• Temporary Set flag (there's already Temporary Set Flag #222 to add this since it doesn't require api changes)

I also need to investigate Profile 0 which is assigned when a thermostat is not using a profile but it is programmed directly on the thermostat.

Managing the profile definitions is out of scope. That would still be done via the Heatmiser App.

[PhillyGilly]

This looks very interesting. Could I suggest that we also include Last Profile sensor? My current test case is what to do with my Heatmiser Controls when the Octopus Agile price is 0p or below 0p? If this occurs in winter getting a bit of free electric heating in the building (even in unused rooms) displaces some gas heating so it's worth doing even at 0p. Below that I'm getting paid! The latest NeoStat HW controls are great as you can turn them on even in standby, but it's much harder with the general room stats. My approach so far has been based on remembering the current temperature, setting the temperature to 35C, re-setting the temperature to previous value. However having a ZeroP profile that could be switched in and then revering to the previous profile would make life simple.

[ocrease]

Hi @PhillyGilly

• I don't think a Last Profile Sensor belongs in the integration. We should only provide things that the heatmiser API exposes, and the previous state of any of the properties is not exposed. However, I'm sure it would be straightforward to do with standard HA features. You could have an input_text that stores the previous profile name when it changes (or the automation that switches the profile could store it). You'll get other ideas by asking in the home assistant forums
• Could you expand on "it's much harder with the general room stats". I think everything you can do with a timer you can also do with a thermostat. If there is something you can't do, let me know and I'll try to help
• Do you ever use your thermostats when the price is not beneficial? If not, do you even need the ability to change profile? Just put them on standby when you don't want to use them and back on when the price is beneficial. Alternatively, I assume there are only two profiles involved? Your automation could have both profile names as parameters and it can switch between the two. No need to store the previous profile name.
• I don't follow your steps of remembering the temperature, setting to 35 and changing the temperature back. What is this trying to achieve? If you just want to return to the profile temperature you'll be able to use the new sensor for current profile temperature (no ready yet I'm still working on it). Or I think you can do this now by setting a hold to a high temperature and then removing the hold (or setting a hold duration of 1 minutes so it automatically stops). I think this returns the temperature to the profile temperature, not any manually set temperature that was there before the hold.

Just ask if any of that didn't make sense.

[PhillyGilly]

Thanks @ocrease.
The reason that I think the NeoStat HW is easier to use in this application is because you just switch it on and it starts using power, whereas the NeoStat E won't use power unless it's on and the measured temperature id below the setpoint.
My current approach involves using input helpers to store previous values, but I think I made it too complicated. If I store the the current profile, then switch to a new ZeroP profile (that has a setpoint equal to or above the floor temperature limit), and then revert to the stored value that will be pretty elegant.
I wouldn't need to adjust temperatures for this use case, although there are other possible use cases where I could exploit this and temperature hold might fit in too.
At the moment I have three modes of heating Bathrooms: Standby - when the associated Bedroom is unoccupied, Normal - when the associated Bedroom is occupied: cooler overnight, hotter in the morning and evening, and warm during the day, and Constant - like Normal but with the daytime hotter than Normal. That's two profiles, but to use profile switching I would have four: Standby (basically off!) Normal, Constant, and ZeroP. Sounds good.

[PhillyGilly]

Or??

alias: 17e. Negative price electricity
description: ""
triggers:
  - trigger: state
    entity_id:
      - sensor.octopus_energy_electricity_21l4045356_1170000688431_current_rate
    for:
      hours: 0
      minutes: 0
      seconds: 5
conditions:
  - condition: template
    value_template: >-
      {{states('sensor.octopus_energy_electricity_21l4045356_1170000688431_current_rate')|float<=0}}
actions:
  - action: heatmiserneo.timer_hold_on
    metadata: {}
    data:
      hold_duration:
        hours: 0
        minutes: 29
        seconds: 0
      hold_state: true
    target:
      entity_id:
        - select.towel_rail_1
        - select.towel_rail_2
        - select.towel_rail_3
  - action: heatmiserneo.hold_on
    data:
      hold_duration:
        hours: 0
        minutes: 29
        seconds: 0
      hold_temperature: 30
    target:
      entity_id:
        - climate.bathroom_1
        - climate.bathroom_2
        - climate.bathroom_3
        - climate.garden_studio
mode: single

[ocrease]

@PhillyGilly how do you currently switch between Standby/Normal/Constant? I assume manually in the heatmiser app? And how do you decide between Normal and Constant?

I would suggest this:

• put the thermostat on standby when not occupied. No need for a profile. You can do that either via the heatmiser app or by setting the hvac_mode to Off (via the HA gui or the climate.set hvac_mode action)
• if the bathroom is going to be occupied, turn off standby (via the heatmiser app or setting the HVAC mode to heat). This will use whatever profile is set up on the thermostat (Normal or Constant)

So far you probably don't need an automation.

Now to make use of the cheap electricity rate create an automation (I would create a blueprint instead and create multiple automations based on the blueprint) that does the following:

• Triggers
  • t1 - when the rate is beneficial (eg <= 0) for 5 minutes
  • t2 - when the rate is no longer beneficial
  • t3 - when hold is disabled on the thermostat
• conditions
  • the thermostat must not be on standby
• actions
  • if trigger is t1, set hold for 30 minutes (or longer). Temperature should be set at something sensible, unless you want a sauna :)
  • If trigger is t2, unset hold
  • If trigger is t3, if the rate is still beneficial, turn on hold for 30 minutes again

This automation will only take effect if the thermostat is not on standby (eg the bathroom is meant to be heated). It will boost for 30 minutes at a time. If the rate stops being beneficial it will cancel the boost. If the rate is still beneficial when the initial boost finishes, then it will start another boost period.

It looks like you have a towel rail and underfloor heating on each bathroom. The blueprint could control both (maybe towel rail is optional so you can do the garden room)

With this approach you only need 2 profiles and no helpers etc. You don't even need to wait for the feature in this ticket.

If you want feedback on your existing automation:

• looks like it boosts regardless of whether the room is occupied or not
• you can combine the trigger and condition. The trigger should say that the state is <=0 for 5 minutes
• It doesn't stop heating immediately when the rate stops being beneficial.
• why 29 minutes? Is that something to do the agile octopus periods being ~30minutes?

[ocrease]

Also you mention the floor limit, how does that come into it? I thought that's mainly a safety feature so you don't overheat the floor.

[ocrease]

Progress update:

I now have the profile current and next temperature and the next time. Profile 0 support is still outstanding.

For a timer:

[PhillyGilly]

Hi @ocrease, thanks again.
Yes I use the app to switch between standby, normal and constant. Standby is unoccupied, Normal is for adult visitors and Constant is for children visitors.
The electricity rate changes every 30 minutes, so the automation fires every 30 minutes and just a moment after the rate changes. I habitually check that the state change is real and not noise by looking for 5 seconds persistence, after all I don't want to accidentally start running if the price is actually 50p!
I treat each half hour block as a completely separate event and I definitely want to stop using electricity before the end of the block in case the rate goes up again. (This relates to my earlier request for the default switch override to be 30mins not 1hr.) Because each block is always 30mins, I let everything switch off before the block ends. In the event that another zero or negative price block follows, I start again.
I had an attempt at creating a blueprint following your earlier suggestion but wasn't successful, but I will pick that up again if I get a few hours. I gave up before as I didn't need it when I couldn't convert a working automation into a blueprint but it looks useful skill so I should try to master it. Thanks.
Few more points

• Yes, I could combine the state change and the condition into the trigger.
• I want to heat rooms even if they're not occupied as this is either free or I get paid for doing it when the price is negative.
• The floor heating limit is a safety feature which you can only set at the device. The default value is 28C which is below a hazard level. If this were some kind of industrial system, you would probably have the temperature on a PID controller and a separate safety switch. But here the floor limit is actually as part of the routine control as the electric heating in the floor is on/off depending on both the floor temperature and the air temperature i.e. power to the heating mat only when the floor temperature probe and the air temperature probe are in demand.

BTW I'm impressed with the progress. My pre-occupation over the last 24hr has been being ready for a power-cut, so you must have less wind where you are...

[ocrease]

@PhillyGilly I made an attempt at creating a blueprint you can use. You can find it here:

https://gist.github.com/ocrease/a290908fe6f2979fb38b2959bb1559ee

You should be able to import it directly from the Home Assistant UI. You'll probably have to make some small changes, but it should get you most of the way there.

[PhillyGilly]

That will be really helpful. I struggled a bit with on-line tutorials as the examples were trivial. Thanks.

[ocrease]

This is now available in the latest pre release version.

@PhillyGilly how did you get on with the blueprint?

[PhillyGilly]

This is now available in the latest pre release version.

@PhillyGilly how did you get on with the blueprint?

I commented on beta7 on issue #196
Sorry I haven't had time to look at the Blueprint - life getting in the way of interesting things - but I will and I'll show you my version.

[PhillyGilly]

@ocrease We had three free 30 minute slots last night. I haven't had a chance to work on the automation or blueprint, but I ran the automation (as above) it any case. At the time when I ran it Bathrooms 1 and 3 were unoccupied and in stand-by. All towel rails including the ones in stand-by came on but the results for the underfloor heating were not what I expected.

The Garden Studio and Bathroom 2 were running in auto and worked perfectly, but Bathrooms 1 & 3 didn't come on. I expected the hold function to change the set-point and over-ride the stand-by but that didn't happen, when I woke up at about 5, I checked what was happening and noticed that the "stand-by" bathrooms had the correct hold temperature but with zero hold duration, so I manually switched bathroom 1 into auto and it started heating following the required hold. I could change the automation to if-then based on stand-by with parallel legs but I feel it would be better if the functions for the two types of device were consistent.

[ocrease]

@PhillyGilly There are several points to make:

1. Check the automation trace to see what the automation actually did
2. You mention the hold temperature. The hold temperature is meaningless unless Hold Active is true. If the duration was 0, then I would assume Hold Active was false
3. Regarding the towel rails, @MindrustUK requested that setting hold on a timer automatically disables standby. We saw different behaviour between his devices and mine. My NeoStat in timer mode would quite happily turn on the output even when on standby, but his would not, so we made the decision to take the device out of standby before setting hold. The side effect of this (not sure if you have noticed yet) is that once the hold is over, the device returns to Auto rather than Standby (I assume you want them to go back to standby, so your automation will have to take care of that)
4. It might be that your devices behave more like @MindrustUK's devices. I suggest you pick one thermostat that didn't work (say Bathroom 1) and do the following:
   • Create a history chart and add the standby, hold active, the device itself, and optionally the hold temperature. Here is one for one of my thermostats when I did this test, You can see that the device is on standby, I turned on hold and short time later the thermostat started heating (target_temp/yellow line goes up and there is an orange shaded area)
     
   • From the thermostat itself or the heatmiser app, set the device to off/standby, then set a hold. What does it do? Check the history graph again. Yours are controlling electric underfloor heating so not sure if you have a physical way of checking if the underfloor heating came on or not (in my case, I can see that the boiler came on)
5. Even if your devices don't behave like mine, I don't think we should change the integration. For two reasons:
   • Unlike timers, the HA climate entities have separate controls for the hvac mode heat/off (eg standby) and the preset (home/boost/away). This means that you have a way to specify the behaviour exactly how you want
     
   • I don't like the automatic turning off of standby when setting hold because the device will not go back to standby at the end of the hold duration. This means you will have to remember the previous state anyway (using standard HA constructs), so there is little value in turning off standby automatically. It is better for your automation to be explicit and change the hvac_mode to heat before calling hold (if your devices definitely can't use hold in standby which hopefully you can confirm after doing point 4)

[MindrustUK]

@ocrease regarding profile controls. I'd suggest maybe doing a check for devices where profile numbers > 1 and enable profile controls based on this, I hand off all intelligence in the heating system to Home Assistant and as result these controls are effectively redundant for me. Not sure how many more would be in the same boat.

[ocrease]

@MindrustUK profile 0 is a valid profile, it just means that the profile is managed directly on the thermostat.

However in your case, you have the format set to non programmable, so we can skip the calculation of the entity values in this case. I will make a change later. The entities will still be created though, a user could change the format from non programmable to one of the other options. If the entities don't provide any value for your use case, you can easily disable them and you won't see them anymore. The other alternative is to have them disabled by default, but it will be harder to explain to a novice how to enable them rather than to explain to and advanced user how to disable them.

A better approach would be to dynamically change the disabled property based on the format, but this will require more investigation.

[MindrustUK]

@ocrease

A better approach would be to dynamically change the disabled property based on the format, but this will require more investigation.

This is what I intended to articulate. A thought occurs, this maybe a nice configuration option. I keep meaning to carve out some time to at least list the content of the setup and configuration flow. This maybe a good candidate for that, similar behavior for the 'disabled by default' underfloor temperature might be a win.

[ocrease]

@MindrustUK PR #226 makes a change so that profile entities are disabled by default if the hub is in non programmable mode. They should still be created though, a user could change their configuration to start using profiles. If they go from non-programmable to one of the other options, they would need to re-enable these entities manually if they are interested. Equally, if they switch to non-programmable, the entities will still be there so if they don't want to see them, they need to manually disable them. This is easy to do in Settings -> Devices & Services -> Entities and making use of the filters and bulk select

When I said "dynamic" I mean automatically change the enabled flag if the format changes, but that would very much be in nice to have territory. There is no need to have a config flow for this

Also, you refer to the underfloor temperature. This should already be intelligently added or not. Do you have an example where you see it and you don't expect it?

[MindrustUK]

Hi @ocrease Merged, seems to have addressed my concern with profiles.

RE: Underfloor temperature, both the bathroom and kitchen report this by default, they are electric underfloor mats with external temperature probes.

By default they appear as follows which is fine:

The default behavior is configured as follows:

This is also not any sort of a problem as I can manually enable current temperature and floor temperature sensors. However having a user specified configuration flag to enable these out of the box would be a nice thing to have so on a fresh install so I don't have to go and enable them. There could be a few options we wish to hand over to user preference but this is probably a conversation for another thread...

[ocrease]

@MindrustUK the reason current temperature and floor temperature are disabled by default is because these were existing attributes on the climate entity, so I didn't want to add duplicate data by default. But I can easily change the default if you prefer. Though of course its very easy to change the enabled flag in bulk with the method I described in my previous post.

While we are on the topic, are there any other entities you should be enabled/disabled by default? And do you want to move any to a different category (Sensors/Configuration/Diagnostic)?

[MindrustUK]

@ocrease understood that we can toggle things en masse, what I'm getting at is configuration options exist and we can use them (if they make sense of course). I think everything is fine as is IMO. As before, maybe for another thread if we want to maybe gather some feedback.

I can't see anything that 'jumps out' at me so far, everything looks good.

[PhillyGilly]

The thread is racing ahead and I trying to find time to address the earlier points :-)
So:

1. Check the automation trace to see what the automation actually did. My system only holds the last five traces and since the automation runs every time there is a new price slot (i.e. every 30 minutes) I can't review that trace. However I think it did what it should give-or-take my lack of understanding about stand-by and hold active.
2. You mention the hold temperature. The hold temperature is meaningless unless Hold Active is true. If the duration was 0, then I would assume Hold Active was false OK I get it now
3. Regarding the towel rails, @MindrustUK requested that setting hold on a timer automatically disables standby. We saw different behaviour between his devices and mine. My NeoStat in timer mode would quite happily turn on the output even when on standby, but his would not, so we made the decision to take the device out of standby before setting hold. The side effect of this (not sure if you have noticed yet) is that once the hold is over, the device returns to Auto rather than Standby (I assume you want them to go back to standby, so your automation will have to take care of that) I incorrectly thought that Hold would work during standby. What I have done now is create a new profiles that are in effect off for 23:55hr per day. Called Towel Rail agile and Bathrooms agile. If I use these profiles, I think I will be able to use HA to run Towel Rails and Bathroom UFH using cheap or free electricity which is what I would like to achieve.
4. It might be that your devices behave more like @MindrustUK's devices. I suggest you pick one thermostat that didn't work (say Bathroom 1) and do the following:

• Create a history chart and add the standby, hold active, the device itself, and optionally the hold temperature. Here is one for one of my thermostats when I did this test, You can see that the device is on standby, I turned on hold and short time later the thermostat started heating (target_temp/yellow line goes up and there is an orange shaded area)
  image
• From the thermostat itself or the heatmiser app, set the device to off/standby, then set a hold. What does it do? Check the history graph again. Yours are controlling electric underfloor heating so not sure if you have a physical way of checking if the underfloor heating came on or not (in my case, I can see that the boiler came on)
  All my Neostat E are reported as v1, two towel rail Neostat HW report as v1 and one as v2. I'm having trouble getting clean data as there's a bit of history which covers different releases in here but here is a trace.
  

I've switched Bathroom 2 from Bathrooms-Agile (set 16C) to Stand-by(set 7C) just after 13:50 the target temperature drops and the stand-by status changes.
Whilst in stand-by I have set a hold of 25C until 2pm.
Nothing changes and the house electrical load doesn't increase.
Back to Auto and then set up the same hold and it kicks in and household load jumps up.

So it looks like my v1 NeoStat E are like @MindrustUK
5. Even if your devices don't behave like mine, I don't think we should change the integration. For two reasons:

• Unlike timers, the HA climate entities have separate controls for the hvac mode heat/off (eg standby) and the preset (home/boost/away). This means that you have a way to specify the behaviour exactly how you want
  image. I agree
• I don't like the automatic turning off of standby when setting hold because the device will not go back to standby at the end of the hold duration. This means you will have to remember the previous state anyway (using standard HA constructs), so there is little value in turning off standby automatically. It is better for your automation to be explicit and change the hvac_mode to heat before calling hold (if your devices definitely can't use hold in standby which hopefully you can confirm after doing point 4) I understand this point now, so I will have to see if there is a better solution than my agile profiles.

[MindrustUK]

@PhillyGilly Thanks for the feedback, I also observed this behavior on a NeoStat V1 (Non E model) too so I think the hardware / firmware combination is probably the key to this (V1 vs V2).

[ocrease]

@MindrustUK that sounds very likely.

In any case I think the integration provides all the tools to do whatever you want, so I don't think we need to make any changes.

@PhillyGilly let us know if you need anything else.

Do we think this ticket can be closed now?

[ocrease]

@MindrustUK did you miss my previous comment on this thread? I think it can be closed now?

[PhillyGilly]

I'm happy 😌 Thank you.

[MindrustUK]

@ocrease think it just got lost in the inbox. Closing complete.