I appreciate your idea, but I see a big limitation: it is not mobile-friendly.
Hover events only apply to mouse.
My card is intended to be used on mobile devices, so I don’t see this a good compromise.
Many users have trouble understanding the editor.
The impression is that when defining a lamp to turn on from say 08:00-15:00, the lamp would be automatically turned off outside of this interval.
But, as you hopefully know, timeslots have no action defined to the end of the timeslot.
I am planning to change the editor quite a bit, in a way that the different editors will be united and the behaviour will be more clear. But this is for later…
Understood.
That would have at least helped those of us that work with it (or at least set it up, as you also recommend in the docs) on PC.
Yep, I know that, and it makes sense, of course.
We can wait for that, sure. It’s not like you can’t use the card as it is.
It’s, anyway, I think the most useful card (along with the back scheduler) I’ve used for HA. So, thank you!
I noticed that if I’m using a scheme and have the same event covering a period of time that straddles midnight, at midnight the event is called even if it’s the same state as prior to midnight.
When it hits midnight, the fan.turn_off is called for my fan. In this case, this even is actually a power toggle so if it’s off at 11:59, calling fan.turn_off again at 12:00am will turn it on.
This seems unexpected as I would think that as long as it’s the same state through the entire period, it should be called again at midnight.
Also related, is then on the card summary, i would expect to see the next “real” state change so in my case above it should be 4:40am, not midnight as it currently is shown:
Yeah… this is a limitation I don’t know how to fix.
Time schemes have a window of 24 hours.
So the schedule of the next day is glued after the current one.
I can’t/won’t make some intelligence to detect that the next timeslot has the same action and thus it can be skipped.
Normally it is completely harmless. And you can do as @KTibow says to avoid the extra triggering.
IMHO the real problem is that your fan ‘turn off’ action is actually a ‘toggle’. What’s up with that? Is this a limitation of the device itself?
Weird limitation of the device itself, but IMHO it’s not the problem. Because even if it did stay off when fan.turn_off was called, the device has an audible beep when receiving a command, so it would be beeping for no reason at a time there is actually no state change.
And i agree with proposition of Canaletto to have an option to display Friendly Name first.
As you can see, it’s not easy to find instantly the right schedule to check or modify between the 2 “thermostat zone nuit”.
One is set for week-end and 1 is set for workday.
A little game : Which one for week-end ? for workday ?
Just to chime in on the many updates recently. I noticed @neliss has worked hard and tirelessly to make this component+card bettter for everyone. I do hope at some point you decide to draw a line. HA already has great automation options built in (and 3rd party like AppDaemon and Node-RED). I sincerely hope schedular card lives up to it potential, but remains exactly what it’s intended for: schedules.
Seeing as how Custom Header’s biggest strength became it’s downfall. I would hate to see this amazing component disappear in a few months because maintenance will be too hard and too many breaking issues with future HA updates…
Anyway, keep up the good work and I’m convinced you know what’s best yourself.
To add to the statement of @ASNNetworks (thanks for your support )
Some of you seem to focus on features which are missing, rather than the features that are already there.
For me this is just a little after hours project…
And I’m having a difficult time to keep everyone happy.
I must say is not very motivating if people keep complaining and asking for more and more.
In HA it took several years before the GUI got to the level that it is now.
And creating an automation in HA is still not very intuitive if you ask me (that’s why you guys are here right?)
In other words: please have some patience, things will get better.
Its not like I don’t see the limitations that you are pointing out.
But I didn’t say I was finished yet, did I?
In my option, this Lovelace card is by far the most advanced card you have ever used (please prove me otherwise…).
Its been quite a struggle to squeeze all the functionality in this little card.
And I think its turning out pretty good.
Don’t get me wrong here: I do appreciate your feedback and feature requests!
It helped me to make this card to what it is now. Credits go to you guys!
But try to prioritize between essential problems and minor issues.
Help me a bit defining the next steps…
Create feature requests in GitHub, and don’t forget to vote on existing FRs. Create a poll if you think you have a good idea. (this is a community after all)
And sorry for all the bugs along the way.
Truth is that I am not a software expert (I have very little programming experience).
Just thought HA needed something like this… But I guess were are in the same team here.
I absolutely agree. The card should serve the purpose for which it is built and that is planning. Adding more and more code becomes unsustainable and disappears. Therefore, it must be maintained in stability, simplicity and error-free functionality.
Do I get it wrong? I have a Tado thermal warhead and hvac modes are the pictures below. They are divided into separate cards. Shouldn’t they be on one tab, set the mode? Everything I set on the individual cards works properly.
It looks like the scheduler-component doesn’t play nice with changes in daylight saving time.
I discovered this morning that in my home devices were triggered at the old time, although the time changed from 3:00 to 2:00 last night.
It could be that the scheduler-card will give the correct (new) time, while the schedules still fire (for once) at the old time.
I recommend users to disable+enable their schedules or restart HA to have the timers recalculate.
Unfortunately I don’t know yet how to fix this. The timers of the scheduler-component are managed by the HA core, and return a trigger (callback) to the scheduler, when the time is due.
A while ago I investigated this scenario, but I couldn’t find any documentation or example on how to account for time shifts (and test this!)
Thanks for the reminder. I restarted HA and tested just to be safe. All fine
One other thing I noticed after updating. I was still om 1.75 and noticed on of the recent updates changed how icons work. The schedule card now shows the icon of the action instead of the entity. Not the icons of entities when setting up a schedule (those are fine) but when you have set a schedule. The icon on the left of the schedule now shows the action icon instead of entity.
I liked having the icon of the entity because it was a lot easier to spot the devices (especially with input_booleans I use for scene automations). Now all my input_booleans have the same icon. Is there a way I can set this myself?
Yes, I changed this in the last major update.
The reason behind it is that an entity always has the same icon, an action not.
So for climate you would see a flame / snowflake or standby icon, depending on the action.
Which is more insightful / descriptive for the upcoming event, than just a thermostat icon.
For switches and input_booleans, the same logic applies. As long as there are separate icons for on/off actions, the icon would be more descriptive.
If you have a lot of the same entity types and you have custom icons assigned to identify each, the story becomes a bit more difficult.
Ideally for those icons there should be an on and off version available, but I can imagine this is not the case.
Perhaps I should add an exception for cases where a custom icon is selected, and prioritize it over the built-in on/off icons. On the other hand, it would result in inconsistency: the icon sometimes corresponds to the action, sometimes to the entity. Not sure yet what would be best here.
For the time being: you could assign icons to the ‘turn on’ and ‘turn off’ icons through customization. But this is not ideal, since you have to add quite some yaml for a simple change…
That’s too bad, but not that of an issue if I can at least change the action icons like you said. I just hate all the bolt/electric icons before all my input_booleans (which I use as scenes). I’ll just change those and play with the action icons for all groups.
Working on a fix for the next release.
Icon assigned to an entity through customize will get higher priority than the action icon from standard configuration.
Hope it makes sense for everyone.
The next revision will address plenty more of the issues mentioned here.
Mostly translations will be improved a lot (it’s about time too)
Had a good discussion with Balloob and other developers today.
Big ideas for the future
Hi! I see that conditions is still a WIP, still I see the option is already on the card. On mine, it only shows switches as conditions. Is there any way to add persons as conditions?
)
