Heaty will die, Schedy be born!

@Jokerigno This for sure never worked without a rule querying the window sensor. Please follow the guide in the tips and tricks section in docs and set up your schedule_prepend and customize.yaml accordingly.

Hi @magicdude4eva

The question is: Why does it switch to auto in the first place? As documented in the thermostat actor docs, Schedy needs to know exactly one HVAC mode it treats as “thermostat in operation” (“heat” by default) and one it considers as “thermostat is turned off” (“off” by default).

If you aren’t happy with this limitation, disable HVAC mode support in Schedy, but then you won’t be able to turn it off completely any longer.

You are right schedule_prepend was commented. I changed it and now it works properly.

Can I ask you something more?

I noticed that my rooms are often more hot that I requested. I think it’s because my radiator are quite old so even if the valve is closed when they reach the desired tempereature they are so hot that they will increase the temperature.

There’s something that schedy can do about it?

Thank you

Thanks, when reading Eurotronic SPZB0001 control via MQTT | Zigbee2MQTT it states:

The system mode will be either off , auto , or heat . When set to heat the boost host flags will be set, when using off the window_open host flag will be set (and off will be displayed on the display).

I read that “heat” actually means “boost” - i.e. max heat. Should I then not set?

  supports_hvac_modes: false
  off_temp: "OFF"
  hvac_mode_on: "auto"
  hvac_mode_off: "off"

No one using Eurotronic SPZB0001 with Schedy?

Yes i like that. Its totally useless to measure room temperature directly on the radiator. I like to have a specific temperature in the room so the radiator should heat as long the temperature is reached.

I do not use just one sensor. I have multipe in the room. On the ceiling, plant sensors, mutlisensor etc. That gives me a quite good median of the correct room temperature.

@magicdude4eva That sounds like you actually want it to be in either auto or off mode. If you set supports_hvac_modes: false, Schedy won’t care about the HVAC mode at all and hence the hvac_mode_* settings would have no effect. Why not just set hvac_mode_on: "auto"?

@teqqy But then I don’t know how to help with that. A climate entity in HA basically supports setting a target temperature and that’s it. If you can determine a target temperature to send to the thermostat based on your room sensors, then you could express that logic and use it in a schedule in Schedy.

Thanks for help - I did this but am still unsure why I get “Unknown HVAC mode 'auto'” error with these settings:

  supports_hvac_modes: true

  hvac_mode_on: "auto"
  hvac_mode_off: "OFF"

Logfile:

2020-10-09 19:10:39.967474 INFO schedy_heating: --- [R:bathroom] Unchanged HA state: state='OFF', attributes={'actor_wanted_values': {'climate.thermostat_downstairs_bathroom_climate': 'OFF'}, 'scheduled_value': 'OFF', 'rescheduling_time': None, 'overlay_active': False}
2020-10-09 19:10:41.396595 INFO schedy_heating: --> [R:bathroom] [A:climate.thermostat_downstairs_bathroom_climate] Attribute 'state' is 'auto'.
2020-10-09 19:10:41.401282 ERROR schedy_heating: !!! [R:bathroom] [A:climate.thermostat_downstairs_bathroom_climate] Unknown HVAC mode 'auto', ignoring thermostat.

You know that these settings are actor-specific and thus have to be configured on the individual actors, right? If you want to set it for all actors, use the default actor template (just search for actor_templates).

EDIT: And you really shouldn’t fiddle with the other settings. The only thing you need is hvac_mode_on: "auto".

Is there a way to have a “tiered” heating system with schedy? What i a mean is that i have a heat pump (climate actor 1), and some electric ovens (climate actor 2).

I want to have a system where

1, just before i get home, the heat pump runs at fill speed.
2. When getting home, it has the the same temp, but now runs in silent mode
3. In some instances (for instance, temperature is low and the visitor mode is on) I only want to use the electric ovens, since they are totally silent.

Is this something that is somewhat manageable to do in schedy?

Hi @roschi,

I searched for a feature request section but didn’t found anything so I put my suggestion here.

I think it would be great if schedule_prepend would have a “delay” of 5 min for exable because I noticed that for example in my doors-windows triggers valves many many times each days after each status change.

Do you found this intresting?

@Jokerigno See this existing issue for a way to achieve delayed responses.

1 Like

Thank you :slight_smile:

Hi @roschi – I am trying to build an automation system for my HVAC system; I have 12 thermostats, 8 are heat/cool and 4 are heat-only that I want to program, and Schedy looks like the right tool, maybe. It sounds like I need the generic2 for the 8 heat/cool thermostats, which is fine. I definitely want to set them up into rooms, and then have probably 4 time-windows per weekday/weekend plus a vacation mode.

Here’s where I want to do something different: I want to be able to control the temp settings from the thermostats themselves. If I put the temp up a degree in a room, I want the schedule to get updated to reflect that. I know how to do that, but what I need are:

  1. A way to determine what Schedy room a thermostat is in, and
  2. A way to determinate which schedule-bucket I am in

I can do #2 from the HA side (as I plan to have those settings in HA), but #1 i there a way to do #2? Is there a way HA can query Schedy to ask what room a thermostat entity belongs to?

Thanks!

Hi @warlord

Have you seen the replicate_changes room setting (docs). It is enabled by default and seems to do what you want without any manual automation work.

Hi @roschi
I’m not sure that really does what I want. The docs say it will replicate changes from one actor to other actors in a room:

      # This setting controls whether changes reported by one actor
      # should automatically be replicated to the other ones in this
      # particular room.
      #replicate_changes: true

But that’s not what I want. I have two thermostats tied to my Master, a heat/cool MasterBR, and a Heat-only MasterBath. Let’s say it’s 7am on Monday and it’s cold in the room, so my wife increases the BR thermostat setting from 68 to 69 (at the thermostat controller on the wall, not in HA). I want that change to be “permanent” for the 7am time-bucket on weekdays. I don’t necessarily want the Master Bath changed – that’s set to something different (and needs to remain different). Then as the temp changes throughout the day from the schedule, each time-bucket for the room adjusts the thermostats (this would be Schedy doing its thing). Then at the 7am bucket the next morning it would be 69, instead of the previously-set 68.

But as the time-buckets are room-related and not thermostat-related, I need to be able to query Schedy to determine the room a thermostat is in so I know which time-bucket settings to query to determine which setting(s) to manipulate.

I do agree that Schedy would be a “better” place to do this, IF Schedy had a lovelace integration that would allow me to control the times and temp settings from the HA UI.

I admit that I’m new here, I’ve only spent an hour or so reading through the docs, so I’m sure there’s a lot that I am missing. And it’s clear that Schedy will do all the “take my stored settings and set my thermostats at the right times” work. If I didn’t want to allow saving local changes then it would completely solve my problem :slight_smile:

Thanks!

@warlord I see, you really meant what you wrote. :slight_smile:

First you have to keep in mind that you will need two instances of Schedy, one for the heat/cool thermostats and one for the heat-only ones. This is because each Schedy instance will use the same actor type for all its rooms. You could probably get away with just a single instance if you’re using generic2 for everything, but that could get a bit fiddly considering that you need different schedules for the two thermostat types.

Regarding the updating of schedules, I would use the schedy_room.<app-name>_<room-name> entities, which Schedy stores the current state of a room in. From these entities, you can get the currently wanted temperature (state). Right now, the actual room name is not available as an attribute of these entities, but if you set a room’s friendly_name to the same value as the room name itself, that will be available as an attribute on these entities and you can use it to index your schedule storage by rooms. Of course this is a workaround, but for now it should be fine. I could add app_name and room_name attributes which provide the particular values directly in next release.

I do agree that Schedy would be a “better” place to do this, IF Schedy had a lovelace integration that would allow me to control the times and temp settings from the HA UI.

I’m afraid this won’t happen any time soon, maybe not even at all. Schedy schedules are more of a scripting language than plain time/weekday scheduling, thus I don’t think there’s an intuitive GUI-based way to configure it without ending up with some text input for code again after all. Of course one could build a GUI for classic weekday scheduling which uses Schedy under the hood, but if that’s all you want you don’t really need Schedy.

The supposed way of making Schedy configurable from HA is to create use case-specific input_* entities which are referenced from the fixed Schedy schedules and control Schedy’s behavior that way. Then you can organize these entities in cards however you think it best reflects your use case.

HTH

1 Like

I do want something a little more complicated than just time + weekday/weekend scheduling – I do want to add vacation mode, too. Because I have so many rooms to keep track of, and no way to build a macro in HA, I was thinking it would be nice to put it elsewhere. (Write Once, Use Many). Being able to use schedy_room.<app_name>_<room_name> might be able to help…

Thanks!

@roschi, is it possible to use sunrise or sunset directly in a rule? It seems to not parse correctly as an end value.