Yea, I’ll keep digging. The state of the zwave devices themselves seems to be reasonable (changing between sleeping and ready) but their climate entity remains at “unavailable/unknown”. (Even manually changing the state to something else will have it change back to unavailable the next minute.)
I’m also still on the old zwave integration which seems to be a sinking ship atm.
My Climates are KNX Climates and do not show as unknown or unavailable. Any other idea?
How/where can I see logs of the scheduler component?
You could change the log level for scheduler to debug by adding this to configuration.yaml:
logger:
default: warning
logs:
custom_components.scheduler: debug
If you leave it running for a day with those logs enabled, I’m pretty sure we can figure out what’s going wrong for you.
Hello,
Thanks for your work, it’s very cool to use the programming card to control my thermostats but I have a question. I use the conditions inside the component (UI) with the person entity (at home: Yes/No).
I work with the single condition (ex: Toto is at home), but I try to run with the :
- Toto is at home
- Tata is at home
in the selector at the top of the map, I have options (any/all), I don’t understand how to use them. Whether I choose “Any” or “All” I get the same result.
I’m trying to make this condition :
(Algorithm)
if (Tata is at home OR Toto is at home) {
Turn on my thermostat
} else {
Turn off my thermostat
}
Is it “Any” that should be checked?
Thank you for your answer and sorry if the question has already been asked, it’s not easy to read the whole discussion even with a “ctrl + F” on my problem.
FYI, I reverted to 2020.12.0 and the climate entities had status “unknown” back then too, but this obviously never prevented the scheduler from changing their set_points.
Now I just have to figure out what is actually causing the status to be unknown.
I suspect that status is “unknown” simply because it is not possible to know the status of the hvac. It doesn’t have any hvac_modes since it only takes a setpoint and has a thermometer sensor. I would actually say that status “unknown” isn’t at all an unreasonable status. The problem is more that the scheduler interprets this as meaning “unavailable”, that there is something wrong with the climate entity itself, which there isn’t.
As it turns out… now that I understand the issue, there is already a bug reported on this problem a long time ago. https://github.com/home-assistant/core/issues/28834
So, that should at least clear up any confusion regarding the scheduler not caring about the state “unknown” before v3 came out.
The state of a climate entity is defined as its hvac_mode.
There’s a list of valid hvac_modes documented.
“on” is not a valid state for a climate entity (since a climate entiy can be an A/C system with heating/cooling capabilites etc.)
“Any” is equal to logic OR and “All” is equal to logic AND.
I just thought these words would be more understable for non-programmer users 
If it doesn’t work as such, you may have found a bug. Please report this if this is the case.
Yes.
The schedules does not feature IF … ELSE … logic so you will have to create 2 schedules with opposite conditions to do this.
A lot of users also choose to create only a schedule for the heating program, and disable the schedule by automation if no one is home.
If you use a time scheme, the scheduler will automatically turn on the heat (depending on the current timeslot) if you turn it on as soon as someone enters the house:
If you enable a disabled time scheme: the schedule will determine which timeslot is active, and trigger this action immediately.
See docs.
1 Like
I clarified my statement in the post above. Not sure what the proper solution should be but until there is a proper status for hvac devices that have no hvac_modes the workaround to be able to use the scheduler again after upgrading to v3, is to comment out the check for state “unknown”
or state.state == “unknown”
in the check_entity_availability function in scheduler/switch.py
I would expect an hvac device to have at least 1 hvac mode: heat (or cool).
Else its not a climate entity 
I recommend you to open a ticket in the integration which you’re using for this device, perhaps things can be improved on that side.
As I mentioned a couple of posts before, this feature was not added in v3.
This check has been in place since 4 months ago.
Downgrading to an other version will not make much of a difference I’m afraid.
The workaround you did seems like an OK solution for me 
Most scheduler updates affect the card only, so I don’t think it will give you much trouble.
As I mentioned a couple of posts before, this feature was not added in v3.
This check has been in place since 4 months ago.
My problem with this is that it’s contradicted by these thermostats (with no hvac_modes) have been known to have state “unknown” since late 2019. See Danfoss Z-Wave radiator thermostat does not have HVAC modes · Issue #28834 · home-assistant/core · GitHub
So, whatever checks against state “unknown” were present in the code before v3 they did not prevent me or others from using the scheduler to schedule set_point changes. I imagine this is a case of two bugs cancelling each other out.
My devolo thermostat surely do “heat”, but you can only interact with it as a thermostat, so the proper mode would be “heat when you need to, to maintain the set_point”. It does not report when it is actually heating though, this fact remains unknown to HA. No currently existing hvac_mode (in HA) describe this behavior.
@wraakh not sure if this is the same issue, but I have some Danfoss eTRV with deconz / conbee and they are seen in HA as hvac capable of all mode whereas in fact they are only auto and only temperature can be set.
So in order to give the right direction to the Scheduler and make it only use set_temperature and never set heat I added this config in customize.yml
climate.thermostat_35:
hvac_modes:
- auto
Customization is really handy when you want to correct some attributes of your devices.
I see, maybe it was my misunderstanding of what the mode “auto” was intended for. My interpretation was that the device was basically “minding it’s own business” and not even accepting a set point. Thank you for clarifying this, I think “auto” might describe the function of my thermostats. This probably means also that the change can be made to the zwcfg xml file itself.
I ended up copying the behavior of my thermostats into the zwave climate.py implementation instead so that it now correctly represents when it is actually heating or is off. I just need to put my changes back after each update.
You’re not mistaken.
hvac_mode auto is intended for situation where a thermostat is running an internal programme or similar. It could indeed ignore an external setpoint command.
IMO the minimum configuration for ALL thermostats would include hvac_modes “heat” and “off”, where in “heat” mode the thermostat regulates to a given setpoint (so it might be idle at times).
These statements are based on the HA climate entity definition.
I’m getting a lot of questions/issues lately from users who cannot get scheduler to work with their thermostats/TRVs.
Unfortunately these problems are caused by inconsistencies in the integrations (mostly z-wave), so they are out of my hands.
I hope that you can report these issues in the right place, such that HA can be improved eventually.
zigbee devices have the same kind of issues, the more middleman you had, the more issues it brings 
Most TRVs only accept temperature, so they should be set to mode auto (and yes it means they will mind their own business ). There is no sense to set them to heat mode, it is the equivalent to set a high temperature, and it will force to embed a second algorithm / mode (more dev, more cost, …)
But air conditioner or such can be set to heat or cold and they will do the job by themself.
From what I understand of the issue it was reported back in 2019 here https://github.com/home-assistant/core/issues/28834
I guess I could provide more information to the issue, but I am not at all clear on what should be changed.
Either it is an issue with each and every hvac device that today have no hvac_modes and instead should be given the mode “auto” (or invent a new mode that just means they have no modes). I see no obvious “one location” to make this change in the code though.
Or, the solution is that state “unknown” should not be treated as “unavailable” by for example the scheduler.
The workaround/solution that has already been made to OpenZWaveBeta is to always return hvac_mode “heat” for a device that have no hvac_modes. But if the issue is with more integrations this seems like a solution equal to saying “unknown” is a valid mode.
Bottom line, the problem a design flaw that wasn’t important to solve until the scheduler actually (as intended) started ignoring devices without hvac_modes.
I just installed the Scheduler components with HACS and everything did work fine. But I’m not able to get the card working in lovelace. I did manually add:
resources:
- url: /local/scheduler-card/scheduler-card.js?v=2.0.5
type: module
into configuration.yaml. But after a restart I get a block error. Without resourses: it is not a correct yaml file.
Error loading /config/configuration.yaml: while parsing a block mapping in "/config/configuration.yaml", line 2, column 1 expected <block end>, but found '<block sequence start>' in "/config/configuration.yaml", line 16, column 3
Component error: resources - Integration 'resources' not found.
BTW. I only have one file for the Scheduler card component:
/config/www/community/scheduler-card/scheduler-card.js
The HA version is core-2021.1.4. Scheduler is 2.0.5.
I’m still a newby in HA, so I ev. missed some usually natural stuff.
PS. As both HQ and this components are evolving so fast I would appreciate to start one or two new threads (one for install issues, one for the usecases), starting with the current version. I was deeply troubled by the early posts in this thread.
If you’re using yaml mode for lovelace, you should put those configuration under lovelace section in configuration.yaml, just like below:
lovelace:
mode: yaml
resources:
- url: /hacsfiles/scheduler-card/scheduler-card.js
type: module
This is what I’m setting, this resource has been loaded correctly.
Is your format correct Jason? I did get an error on the sections # mode and # resources when I restart. I changed it to the following one to be able to restart, but nothing happens in Lovelace.
lovelace:
mode: yaml
resources:
- url: /hacsfiles/scheduler-card/scheduler-card.js
type: module
Ok. got it, the way above is not the recommended way to do it, instead you can use the UI to add the resource.
I couldn’t find that page so far. You need to go to Configuration -> Lovelace UI: Tab Resources. There you can add a custom resource. After that I did create a new Scheduler card and can start to control my thermostats.
OK, glad you figure out, and sorry for not pasting with a right format. Before I started to try HACS, i already used yaml mode to create lovelace view, definitely will try the UI mode.
I am still fighting with getting my schedules for my KNX Climates back to work (they worked perfectly fine). They have HVAC modes [“heat”] and Preset Modes [“comfort”,“away”,“sleep”,“eco”]. I try to just set the preset modes by the scheduler and this used to work fine until a few scheduler and HA versions ago. There is nothing in the debug logs that would indicate an issue. Any idea? Any more logs that I could provide?
I can open a ticket but no idea what other details to provide…