This variable doesn’t seem to have any function…
I’m using it with the Generic Thermostat integration but apparently it’s similar with the Generic hygrostat.
At first I had used 5 as value but was doubting this might be seconds but even with 30 the switch is toggled immediately.
Am I missing something
Where is this setup? Through the ui? It takes the time in the form of hours, minutes, seconds.
In yaml you need to specify the units.
climate:
- platform: generic_thermostat
...
min_cycle_duration:
hours: 1
minutes: 20
seconds: 5
Hi Mike, thanks for helping!
Configuration was done in yaml (config file) but I assumed the number represents seconds and added the number behind the main variable.
Changing it to your example doesn’t seem to work either.
climate:
- platform: generic_thermostat
..
min_cycle_duration:
hours: 0
minutes: 0
seconds: 30
Switching happens instantly when the threshold is surpassed.
This option means that the switch would need to be on for 30 seconds, not 30 seconds after the temp is satisfied. Is it possible the switch is on for 30 seconds prior to the thermostat reaching temp?
I assumed this added a delay in both directions.
So, even changing the requested temp would not be affected by this setting?
I’m testing this by changing the thermostat above and below the measured temp.
That is the way I understand it, it only looks to see if the switch was on for the allotted amount of time.
I’m having the same issue - seems like this setting is ignored. I have mine configured via UI and min_cycle_duration set to 5 minutes. I am able to toggle my thermostat on/off like flicking a lightswitch as quick as I want. I tried toggling via set temp and heat/off setting and both allowed me to flip it on/off with no delay.
I was fully expecting that once it’s toggled, it has to wait the configured time delay before the actuator switch is toggled again. In my situation, this is for a gas fireplace, and I should not be randomly flicking the gas burner on/off… I feel like that’s just inviting disaster.
Ok, it’s not “broken”, but just very misleading. A maintainer explains its actual function here: Generic Thermostat Bug? · Issue #91201 · home-assistant/core · GitHub
Basically, min_cycle_duration only impacts on/off toggle events due to temperature change. This means that you can manually toggle the thermostat as much as you like using user intervention - the min_cycle_duration isn’t even factored in to those events. Only when the temperature changes and triggers an event, if it’s within the cycle limit, it will ignore that event.
I believe the docs should be clarified to state this, as it and the UI are written to sound like it causes it to ignore any event. Second, this feature is extremely limited and I believe it should be extended to act on any event, plus there should also be an additional setting introduced to allow people to set a max runtime so that a heating/cooling system doesn’t potentially run for extended periods (going designed duty cycle limits of the system, causing premature failure over time).
I would expect this for safety reasons. That any manual adjustment would override any keep alive setting. I tested the component and it does work as described. How I tested was to create a generic thermostat and then used a hair dryer to increase the temp. It stayed on for 5 minutes after reaching temp.
Yes and no - while I can understand that manual toggling should allow you to be able to turn it off, it should also allow us to define a time between toggles which is what I assumed this setting was for.
The use case for this would be if a device should remain active/inactive for a period of time to allow for a cool-down period (evacuation of heat or similar for an AC unit). Also, some heating/cooling units aren’t designed to be switched on/off quickly, and some may even need to “run a full cycle” before they should be shut down. In my case, I don’t want the gas valve to open/close too quickly, so I would define a minimum time between allowing the thermostat from being able to turn it on and off. I still have full manual control over the actual switch which would allow me, or an automation, to toggle my gas valve on command regardless of min_cycle_duration.
It would be no different than running a server. Yes, you can do an immediate forced shutdown, but you really shouldn’t do that all the time - and you can only imagine how that might impact HDD platters if you’ve got heads parking, then spinning back up to operation when you turn it back on right away. Normal operation would be to do a normal shutdown, let it properly exit apps, and then power down. then you’d give your system a minute to rest and drain power before powering it back on.
What you describe is duty cycle control which, to me, is different from minimum cycle duration. If I needed that type of control, I’d use a control system like esphome and have that separate from the thermostat control.
Basically this is what I have now. I use it for a large steam boiler. When I first started using ha, I noticed a lot of short cycles. First I had tried with a min runtime. Because this boiler heats a building with no zones, depending on the temp, complete cycles vary widely.
The boiler itself has safe guards for steam pressure. When the system hits a certain pressure, all the radiators are full. I had to do a lot of balancing to achieve this. With esphome and a ct clamp I can see when that pressure switch trips. Then finally end the heating cycle by opening a relay that overrides the the thermostat.
E.To expand further, in your example, the relay could then be locked out by the esp even if the thermostat makes a call again. Thermostat → relay → unit, so that the thermostat is not actually connected to the unit but an intermediate relay controller, that can have it’s own parameters.
Yes, duty cycle for sure and that’s what I was basically expecting from the setting.
Using ESPHome would definitely be way more effort than I feel is necessary. The switch I am using for my fireplace is just a Zigbee relay. I overrode the device type from a light to a switch and it just closes a circuit that turns on the gas valve. There’s a disconnected (from the control) blower that has its own temp sensor to run as needed - all I need to control is the gas valve.
Bringing ESPHome in to this would mean building my own little relay so I can have a custom firmware and built-in duty cycle management. Cool idea, but I’m not there yet - I was going for quick and easy (as quick as ordering a relay on AE is 
).
I honestly think that augmenting the generic thermostat integration with duty cycle features would be a far better use of my time (if I can; just learning Python) so that everyone could benefit. I don’t think it should be that overly complex to do either.