That’s basic Home Assistant functionality, you should be able to figure this out without my help…
Just create an automation, have it trigger on a certain time or an input_boolean or something, and assign the two actions like this:
Sorry about that and thanks for taking the time to explain, I misunderstood you originally.
I tried that and it worked. This is how I had to set the automation (my page is different than yours, maybe that’s a start?):
alias: New Automation
description: ''
trigger:
- platform: time
at: '17:31'
condition: []
action:
- service: climate.set_hvac_mode
data:
hvac_mode: cool
entity_id: climate.master_bedroom
- service: climate.set_temperature
data:
temperature: 24
entity_id: climate.master_bedroom
mode: single
I’m actually having the same problem as @atrupo where the scheduled event only performs the set_hvac_mode and not the set_temperature.
Though if I set the automation as you asked the task completes as expected (this is where the 62 came from above. I did this automation prior, then set back to cool and used the scheduler card:
Also, is it not possible to set the mode within the set_temperature call? I guess that is not supported in all thermostats? It does work for mine in the developer console.
I’m pretty sure at one time this card did work with both mode and temperature for my device. I have to admit I don’t use it that much and “usually” the “previous” temperature is what I need anyways. However every so often we adjust it by a degree or so from the last time and that’s when I notice it’s not working with set_temperature.
My devices are integrated via the SmartThings integration. They are not zigbee2Mqtt which you mention earlier has the back to back commands issue.
I created PR that allows changing HVAC mode when setting the temperature (https://github.com/home-assistant/core/pull/43308) but no one reviewed it and it got closed. If it would get merged then other integrations (SmartThings) could do the same change.
But we must have at least one working integration with code approved by the team.
@atrupo @jalsing
I’m quite sure that the issues you are having are related to the specific climate devices you are using.
If it works OK with an automation, there is a good chance I could get it working with scheduler as well.
Unfortunately I have no way to troubleshoot this case.
I like to ask you to create an issue in GitHub for follow-up discussion.
Initially scheduler worked like that, but I received a TON of complaints from users that had devices which did not support the property (it would simply be ignored).
Since scheduler is unable to detect whether your integration supports this, I settled for the workaround thats now in place (which calls the two services in a sequence)
1 Like
Perhaps this is when I recall it working correctly. Like I said, I typically only need the hvac_mode anyways as the set_temperature is usually already set from the previous heating/cooling point. But I’ve opened a new issue anyways.
I’ve opened another one, even though our issues are probably related, mine is that a wrong hvac_mode is set.
Is there any roadmap for making this an official part of Home Assistant? A good scheduling UI is a must for a smart home product.
2 Likes
The code probably needs to be cleaned up first. It might also need to be configured somewhere else than a scheduler card.
1 Like
A scheduler card is a perfect place for it imho
I got this working easily. Thank you. But now I find I’m the only user who can set schedules. Is there a procedure required to allow non-admin users to set the schedule?
No, there’s an open issue about this, the code of HA itself needs to change in order to do this.
1 Like
Since the last DST update a few weeks ago I can no longer use or create sunrise/sunset related schedules.
Old schedules sun related are marked as “Defective Schedule” and if I try to create a new one I get the same result. This was previously working fine and I can create other schedules or schemes with the same devices.
Running HA 2021.5.0dev202 in Container mode on a RPi4
Any thoughts?
- Having noticed what I wrote, I was curious as to why I was on a ‘dev’ version of HA. As I run it through docker it seems this relates to the docker image that’s used if you apply the ‘latest’ tag to your image. In my case this was “homeassistant/raspberrypi4-64-homeassistant:latest”, if I omit the latest tag I end up with HA version 2021.4.0b6 - guess what, scheduler works as expected now.
Coincidentally DST changes here were also the same day I updated the image… probably a cautionary tale for all here.
As you were!
There is some PR for a input_timetable integration. Maybe this could be combined.
After the DST change of last week I got pissed off at my own scheduler and did a complete rewrite of the timekeeping part. The new code should be robust for handling corner cases (such as DST change).
There’s a new version committed in my scheduler-component repo, but I have been holding off from releasing it for the public since it might contain some Easter eggs still.
Feel free to install it (by cloning the repo, overwriting your local custom_components/scheduler folder), there’s a good chance it might revive your broken schedules. Actually it would help me if people are willing to test it, since it would help build the confidence level and hence speed up the release.
Please share your experiences (use GitHub issues for reporting problems) if you decide to test it.
I took a look at this integration.
Interesting approach, code looks to be written quite well.
But to me it seems to cover only a very small part of the puzzle, as it still requires automations to handle the actions, and it is not very easy to manage by the limited GUI (though definitely a big step forward compared to having separate helper entities per time segment!).
Also it doesn’t seem to handle sunrise/sunset, days of the week, time slots etc, …
I’d say there are more differences than similarities between this project and mine, so I don’t see an added value in (and a way to) combining it.
The focus of scheduler is on the GUI actually, the data storage / timekeeping part (scheduler-component) is not very complicated.
Just wanted to post a big THANK YOU!!!
I wanted to read my way through the whole thread before posting my query and although I had a couple of hiccups getting started they were answered in the thread so I am now up and running.
I went with manual install as I am not keen on adding HACS. the process was simple enough but I did get caught out on step 3 adding the integration and after numerous restarts and clearing of the browser cache I could not get the integration to show up but I then used the private browsing mode which let it show as you suggested earlier in the thread.
I also had a problem with the card not existing when using :
- url: /local/scheduler-card/scheduler-card.js?v=0
but it worked with the current version number - v=2.0.5 not sure why as I have now changed it back to v=0 and it has remained working
my last piece to do is more meaningful names for each schedule I have renamed the card but can I rename each schedule? it looks like I can and if I understand it needs to be done in the code but as I have created my schedules from the UI where is the code to edit? I fear this will be a woods for the trees and I will kick myself for missing it but at the moment it is eluding me. I think I may need to recreate the schedules starting from the code to add rather than using the add button on the UI but since its not broken… hope to understand before I mess up trying something
again my thanks for this as it has suddenly made HA far more usable 
Why?
Yes, there’s a “more” option or something while you edit each schedule from the card.
Don’t mean to offend, but “opentoideas” and “not keen on HACS” seems a bit ironic.
Seriously, HACS is awesome and simple.
1 Like
doh - thanks I had clicked through and somehow missed it - obvious now i know where to look 
hmm still no joy though. I have changed the name in options restarted HA and cleared browser cache and the schedule entities still show as generic “downstairs:heat to18c”
I am still figuring out HA so simplicity is the reason for not using HACS - yet…
I only have a couple of custom components and tried HACS on the first one but then realised it was a simple copy operation.
I know it sounds counter intuitive to be messing with HA yet also desire simplicity but the main starting point for me is my heating and for that HA needs to be both robust and easily recoverable from faults.
so far the main way HA has let me down was messing up the installation trying new things. while i have no doubt that is entirely my own fault its also a reality so I have backups and since my installation is minimal I can be up and running again with a fresh load in minutes.
if and when my installation gets more complicated I may get to the point where HACS brings something to the table but for the moment its something else to go wrong that I don’t need.
Richard, don’t misinterpret “not keen” as “don’t like” - I can see that HACS may be useful and may simplify certain aspects but while I am still getting my head around the basics it just seems like an unnecessary complication - I can tie myself in knots fine without any help 
1 Like