That’s a good point, not everyone wants a row of buttons. I have noticed that all scheduler entries have a separate background (when you hold/press it you see a slightly border around it). So I’d guess that is also themable?
I’ve created a mix with basically the same card format of your card to mee Lovelace standard, but it can appear as button purely by allowing theming of all colors/elements and setting border-radius. It shows easily which schedules are on/off. By theming (and allowing to sort by group, domain etc) you can create a clean look. Give each group/domain its own color and you have grouped schedules. Of course: this is just an example how theming can look like. People can get wild with this. You provide a framework en let others create different themes/layouts and worry about that.
This is a rough draft of what I meant. I also shuffled around the details, which gives space at the right side to use for other functions you might want to implement, see red boxes.
On thing to keep in mind with this: the name needs to have either 2 rows room, or a max character count. In order not the exceed the box (like on the PlayStation 4 in the example).
Anyway, this is just an idea, of course it’s up to you (and feedback of others) which way you want to take this card up !
Hi,
First, I would really like to say how much I appreciate the effort you are putting into this amazing add-on card. This is absolutely amazing!!!
Second, I am using it with the ac controller that I developed (I am an embedded guy) and I created the following display for that which is based on a few components:
I am using your card as a pop-up card for the device so that I am using minimal screen space on the main screen. When I push the Timers button, the schedule card pops up to enable defining timers for that ac device.
I am using the “standard_configuration: false” so that I get initially the following window when clicking the “add item”:
As you can see there, the “set temperature” and “set mode” are as they are but there is the added “turn ac off” which is a preset/hold command that using “customize” I am showing it on the same level,
Then, when I click on “set mode”, my customize code enables showing that:
As you can see, I enables only “cool” and “heat”.
I was able to do all the above only by using “standard_configuration: false”.
Third, yes, I asked for a way to have a way to define a group of climate devices to have the same timer operation attached to them
Thanks again for all your effort! I wish that I could also contribute to the card but I am not a Python or JS programmer
In my general HA config, I have 3 switches, grouped as group.lights_outside so I could do automation to turn them all on/off more easily since I don’t ever need to automate just one of them.
In my Scheduler Card, I’ve tried to include it in the config by manually going into the code editor and adding in group.lights_outside but it doesn’t show.
Is this not possible? Or is there some type of setup I didn’t do correclty with my group?
Is there a way to get an entity included in one of the default domains groups?
E.g. I want to include my ceiling fan into the “Climate” group as it logically fits in that category to me. However, this fails if I include it in this config:
This results in an error about not being able to create a custom group with same name as a default one. Makes sense I guess?
Instead, of this, it would actually be better to not have to redefine a built in group, and instead just customize an entity and state what built in group it should belong to.
I will see what I can do, will let you know when I found the time to simplify things for you.
Truth is I am not a programmer either. This is my first experience with Python and Javascript Typescript. Hell of a learning curve. But slowly improving (hope you guys notice this as well).
group entities are a difficult case. Because the actions you can do will depend on the entities that you fill in the group (you can put light but also cover or climate entities in it).
If you would have chosen a light group instead, all would have worked as you want.
If you really want to have support for scheduling group entities, please make a FR on GitHub.
Currently all HA domain types are considered reserved group names and will be filled with the included entities of that type (unless you assign the entities to your own defined groups).
Customization of the reserved groups is not supported currently.
I recommend you to create your own group and include the fan + climate domains to it. Reserved groups will automatically disappear if there are no entities in them.
Unfortunately you will have to give it a name other than ‘climate’ .
This:
Is not going to happen.
Groups have their own way of assigning entities to them (through include/exclude).
It would be super confusing (and completely unnecessary) to introduce an alternative way.
As far as I know friendly name is only used for display (so treated similar as icon).
Perhaps you could make some jinja template to search HA entities for a matching name, but I don’t want you to go through this trouble.
It would be better to add functionality for updating the entity ID to match your custom assigned friendly name instead.
May I ask what your use-case is for this template sensor?
Be aware that next_trigger attribute disappears when the timer is not running.
Well, a schedule is a switch, so if all switch entities are exposed to Alexa, that’s what you will get…
I guess you could better ask this question to the maintainers of the Alexa integration instead.
I cannot make them magically be filtered out
As far as I know most of these integrations use a include/exclude mechanism for whitelisting entities, so I would assume you could create a list of switches you want to expose.
If I could simplify things by introducing some kind of attribute to the entities to distinguish them, I’d be happy to…
As for my use case:
I have 4 different cards showing information on 4 irrigation zones. In each I would like to show when the next watering is scheduled for that zone. If the next trigger attribute was not there I would simply report that no watering is scheduled for that zone.
I then will have a separate card to handle setting the schedules.
I have some issues setting climate temperature trough this card, it works for another climate entity however i can’t get it to work for 4 climate entities I have in my configuration.
Manually editting with service climate.set_temperature works though…
I tried it by using the scheme editor, and trough a ‘normal’ time trigger. Reinstalled the card and also the scheduler itself without result.
What i found out is that the service being used is “set_temperature”? Shouldn’t that be climate.set_temperature?
@Bart1992 I think your climate situation is a very good use-case for scheduler.
Let’s start by agreeing that we should get this to work fine in other words: don’t give up yet.
You say 1 climate entity is controlled fine, the other 4 don’t respond. Right?
How are you concluding this?
Are all 5 of the same type? Or are the 4 not working ones TRVs (like Tado valves)?
If you go to developer tools -> services and execute a ‘set temperature’ service for a climate entity, does this work?
If not, then it’s likely a problem outside of scheduler. Maybe your climate entities need to be set with a ‘hvac_mode’ before they will listen to a setpoint command.
I mean, if your climate is in mode off it makes sense that it doesn’t do anything with a temperature setpoint.
If this is your problem, perhaps it’s good to keep your climate entities in a ‘manual mode’, so you can always control them with temperature setpoint.
I’m planning on adding support for changing the mode together with temperature.
@neliss thanks for your support! For sure I don’t give up ;)! This integration/card is a MUST, it’s just perfect and something I was really missing in HA for the last years!!
1 Climate entity is working, and which is indeed from an other type ( ESPHOME climate entity ).
When publishing a manual temperature trough the service component ( eg; check image ) it does work, and sets the temperature( regardless which mode/preset is active )
These valves work by changing the ‘preset_modes’, and not the Hvac_mode’s ( because there are alot of different functions in these valves ( see image )–> mode’s only allow 4 types? ( auto, heat, idle, cool? )
!
in other words: don’t give up yet.
