@clau-bucur If i understand your time scheme correctly:
from 00:00 to 06:00 heater at 20.5C
from 06:00 to 06:30 heater at 22C
from 06:30 to 15:00 heater at 20.5C
And time slot 2 is missed you say.
To troubleshoot this, please share:
The attributes of this schedule entity
History graph of the schedule entity (should show the ‘triggered’ minutes)
History graph of the climate entity
Another good clue would be to create a template sensor that stores the next_trigger property of the schedule. Same for the climate setpoint (theoretically it could be a problem of this entity as well)
But then we would have to wait for the next night where the problem occurs.
Ofcourse the behaviour of the scheduler-component should be the same for each timeslot (no matter how short). So I don’t see a straight-forward cause for this.
Hello, moved my support request here
I have implemented my own “turn off” function and for that, I need to define the list of actions on my own. My code is below and issue is explained below the code:
type: 'custom:scheduler-card'
title: false
discover_existing: false
standard_configuration: false
include:
- '[[my_climate_entity]]'
customize:
'[[my_climate_entity]]':
actions:
- service: climate.set_preset_mode
name: Turn AC Off
icon: 'mdi:hvac-off'
service_data:
preset_mode: timeroff
- service: climate.set_hvac_mode
name: Set mode
icon: 'mdi:cog-outline'
variable:
field: hvac_mode
name: Operation mode
options:
- value: heat
icon: fire
- value: cool
icon: snowflake
- service: climate.set_temperature
name: Set Temperature
icon: 'mdi:coolant-temperature'
variable:
field: temperature
name: Temperature
min: 16
max: 30
My questions:
Is that the correct way (and actions definitions) to define this?
I set some timers using that setup and the list of times is displayed not formatted correctly:
See how the mode/temp settings are displayed (not in separate lines as they should)
Thanks for your help!
This is how it should look. I decided to combine entity + action in one line, because I received a lot of requests to make the overview page more compact.
Your code looks fine, but I don’t recommend disabling the standard_configuration.
The actions that you use should be available for selecting when using the standard configuration (so only including your climate entity should be sufficient!).
If you have a problem with additional actions/options showing up in the card, perhaps I could add a feature to hide unwanted stuff.
Personally it doesn’t bother me, but if you have reasons for it, there is always a way.
I think the code should become more easy this way.
Indeed, time slot 2 was missed.
I’m attaching the schedule attributes and climate graph. I don’t have history for the schedule as it was not included in the recorder.
I have created now those two new sensors, and included the schedules and these sensors in recorder. Will monitor them in the upcoming days, and get back.
Without using the “standard_configuration: false”, I get all possible actions listed but I only want part of them (would like to remove “set preset” and “turn off”) displayed for selection.
In addition, after selecting “set mode”, the possible hvac modes are listed for selection but I do not want to display all of them (I want to remove the “off” option).
BTW, the reason for taking all this effort was due to the reason that I need the “off” command coming from the timer to be different than the “off” command coming from the climate device UI (I am using Simple Thermostat). Only way I found to support that is to use your suggestion and add an “hold” command to my device (I called it “timeroff”) and it works but then, the “turn off” action option and the “off” option in the hvac commands list should be removed so that the user will only use the new “turn ac off” command that I created through the preset action option.
If instead of taking this route you can add config options to select what actions will be displayed and select what hvac operation modes will be displayed, this will be great, thanks!
@Motti_Bazar
By adding your timeroff option to the hold modes, it should show up as an extra preset, and the action you need to use is set preset mode. This is HA behaviour.
Ofcourse you could rename set preset mode to whatever name you want to give to the action, but that will always remain customization (its a matter of taste).
If I understand you correctly you want to:
hide all options from set preset mode except for timeroff and have it selected by default (such that this set preset mode becomes your new turn off action)
you want off to be removed from set hvac mode options.
And then you want the turn off action to be removed as well.
It sounds like a lot of trouble to go through
You’re not the first person who asked for hiding actions from an entity, so maybe I will add some easy way to configure this. But for you, it would only solve item 3.
Items 1+2 require functionality for hiding items from the action variables list. I wonder if this has added value for other users as well. I don’t know yet how to make this easy to configure this in the card.
Maybe its better to keep using it as it is now (if I understand you correctly, you know have it configured in the way you want it, right?).
Hi, using “standard_configuration: false”, I was able to configure what I need (I did not yet test if it actually works, only what is displayed). But, you recommend not using this setup parameter
What is needed:
Ability to configure/define the list of action options
Ability to display a preset mode as one of the actions (instead of asking the user to select the “preset” option and then the required operation)
Ability to configure/define the list of hvac modes to display (following selection of “set mode”)
Will this be possible?
What am I losing by using “standard_configuration: false”? Any risk?
for three days I have been trying to adjust my Danfoss LC13 (Z-wave) thermostats. They work well with the basic “thermostat” board in Lovelace. They are recognized in “Scheduler Card” but do not trigger when I set a schedule.
When I program my Qubino (Z-Wave) in “Scheduler Card” they are ordered correctly and it works.
I reinstalled “Scheduler component” and reintégrated a Dansfoss LC13 thermostat but still nothing.
Could you help me please ?
Thank you
Je continue en Français alors…
Je viens de tester mon thermostat Danfoss LC13 dans “outil de développement” puis appel de service avec :
entity_id: climate.danfoss_z_thermostat_014g0013_heating_1_2
temperature: 21
Mon thermostat est bien sur 21°C mais je ne sais pas pourquoi sur Scheduler Component ça ne fonctionne pas.
C’est comme si dans Scheduler Component le service n’était pas appelé ou pas de lien entre Scheduler Component et Scheduler Card.
Auriez-vous une idée.
Merci.
I removed the scheduler component and the card. I then looked at both /config/.storage/core.config_entries, /config/.storage/core.entity_registry and /config/.storage/core.device_registry and can’t find anything for a search on “scheduler”.
Update: In fact, even after I remove both the scheduler component and card, then restart HA, and reinstall both, there are no matches for “scheduler” in any of the 3 above files either. However, I do see them listed as installed in HACS after I install them.
I don’t know the answer to @Xavier_Pous’s issue, but I did just do a google translate of his post in case it helps someone else answer
I have just tested my Danfoss LC13 thermostat in “development tool” then a service call with:
entity_id: climate.danfoss_z_thermostat_014g0013_heating_1_2
temperature: 21
My thermostat is of course 21 ° C but I don’t know why on Scheduler Component it does not work.
It is as if in Scheduler Component the service is not called or no link between Scheduler Component and Scheduler Card.
Do you have an idea.
Thank you.
HACS only takes care of storing the files.
So if it is installed according to HACS, this doesn’t say much.
If all traces of the component are removed as you say, the next step is to add the ‘scheduler integration’ in HA → Configuration → Integrations.
If it doesn’t show up here, it is due to browser caching. So do a hard refresh or open private tab.
If it does show up and its added to your integrations, there should be services ‘scheduler/add’ and ‘scheduler/edit’ etc. (see developer tools → services).
If the last step failed, the component has crashed, and this will be in the error log.
I really cannot think of another scenario, but then again, HA is full of surprises
Please keep the discussion in English. Else we cannot help you.
How did you configure the card? Are you using YAML mode or UI mode?
Can you share your card configuration?
It should be enough to just include all climate devices.
Your thermostat should show up and all available actions will be shown based on the capabilities of the device.
Simple test would be to just schedule a ‘set temperature’ action for 10 minutes from now.
You should see in the card when it will trigger, and on the display of the thermostat you should see the increased temperature.
Perhaps you need to change the operation mode of the device before it allows you to send a temperature setpoint command?
Ok, I reinstalled both then checked HA → Configuration → Integrations and it’s not listed. I even checked in an Incognito chrome window.
In my home-assistant.log, I searched for scheduler and found this single entry which I think is just the standard warning.
2020-10-09 20:11:13 WARNING (MainThread) [homeassistant.loader] You are using a custom integration for scheduler which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant.
I also checked services, and there’s not scheduler/add nor scheduler/edit services in Developer Tools → Services.
I have no idea what’s going on and if it was indeed crashing, I would expect to see something mentioned in logs.
No. It’s a EQ3 Bluetooth radiator thermostat to which I’ve attached an external temperature sensor.
I’ve modified the built-in HA integration and added support for an external sensor. Will make a pull request once I’m confident the changes work ok.
