Amazing progress! This new time schedule is exactly what I was looking for!
I have a couple of doubts/suggestions.
Would it make sense to only accept a ‘time scheme’ only if all slots have a value? Or at least have an option to enforce that? Currently, it accepts a schedule with say 4 slots, where only 3 or them have a set value.
I would like to enforce this new mode, I find it much more convenient and self-explanatory!
@neliss can you comment on this one please? It is flooding the HA logs and the debug logs in the browser. I had to completely remove the card to stop it. (I don’t know if it only logged this continuously when I tried to change the time, or all the time while the card was added)
TouchInput constructor is only defined in Firefox if you are using a touchscreen?
Maybe use PointerInput which is said to be working with touch AND mouse too.
The touch events are used for supporting mobile devices. With only listening for mouse events the dragging does not work on a phone.
I did not test with Firefox specifically. But in chrome and safari (windows/android/iOS) all works OK for me.
I could try to see if I could catch the errors you are seeing. But I’m not sure if I can reproduce them here.
For me it’s fine if you remove the card (or avoid using it with Firefox) in the meantime.
Its a work in progress, so your experience is useful feedback.
Can you open an issue on GitHub for follow-up on this? Also provide details for reproducing and error logs if you can.
@LeadUr Never mind the Github issue, I made a v1.7.1 release which should fix your problem.
I installed Firefox to test and had the same problem.
But the errors only occur when you start dragging, so I don’t really get what the fuss was all about.
It remains an experimental feature, hence the big disclaimer on the page
The new scheme option is fantastic! One thing to note with the update: language is not correct. It’s a mix of Dutch and English right now. Not a huge issue, so I understand if you work on that once the new scheme option is final. But wanted to let you know.
Thanks! It wasn’t a fuss. I just checked the HA logs and saw the TON of errors I showed to you. (Ton meaning hundreds of lines)
I really wanted to try out this feature (since I was the first one mentioning that a schedule is needed to fire even if HA is restarted or it is turned on and the time already passed).
It is indeed working now for me in Firefox! Thanks again!
Now the only question remains is how @KTibow was able to modify the time on the Time Scheme in Firefox if it really needed a fix, and was not working for you either?
@KTibow did you try this on a device which has touch input?
I am very much aware of the mess that you will get with long list of schedules.
Currently I am a bit struggling with a good solution for this.
The problem is:
Some users want to be able to combine multiple actions in a schedule (this is partly in place, since the time scheme allows this)
Some users want to be able to combine multiple entities in a schedule (for example, switching on 3 lamps)
Some users want to be able to combine multiple schemes (like one for workdays, one for weekends) in a schedule
I don’t have any problem with adding all of these features (in fact: the scheduler_component already supports it), but I want the card to remain easy to use.
You are proposing to group the overview by entities. Which I think, is an excellent idea
The problem is: what if schedules contain multiple entities?
Would you like to see these schedule being ‘ripped apart’ and listed multiple times, with a duplicate for each entity?
Or would you bundle these entities in the overview as a single group?
Or something else?
Yeah I know. Translations are getting a bit messy.
The real problem is that drastic changes are needed.
In English you would say: ‘On Wednesday’ and ‘Every day’ (or ‘Daily’), but ‘In the weekend’.
And ‘at 12:00’ or ‘from 12:00 to 16:00’ .
But some languages work completely different. In Spanish for example: ‘a las 12:00’ but ‘a la 01:00’ , and also female/male differences in some words.
I really don’t know how to make this universal.
Plenty of work for improvement here
Hope it doesn’t bother too much.
I personally don’t think you should add too many features like this, because the card can get too bloated, confusing and hard to manage. Having ‘one card to do all’ is not something maintainable. Also, where does it stop. Next thing you now, it’s an automation wizard and defeats the purpose: fast and easy way to setup simple schedules. There are other cards people can use in conjunction with this card to sort stuff, like swiper card and state-switch.
You have added the feature to create separate schedular cards already. This should be enough honestly, because now people can use your card inside other cards to manage their schedules. But people need to get creative and use the possibilities that lay in front of them.
For instance: you want separate schedules for each room or entity type? Simple: use state-switch card and button-card and setup multiple schedule cards inside. Then just switch between schedules with an icon.
No work needs to be done by you for this and people can get creative and use a kinda of solutions.
I’ll create a short example of what I mean later today, to give a practical example.
Well, I think you will get disappointed honestly.
I am noticing that at HA startup it is really unpredictable in which order devices are waking up.
It’s not that easy to make the scheduler wait until HA is fully started and all devices are operational, since the ‘home assistant started’ event is fired way before that.
I am noticing this already with native HA integrations, including the weekday sensor, but also MQTT devices.
Also listening for state changes in devices doesn’t really work, because the unavailable->available transition does not seem to fire any event in HA. At least not at startup.
This is a work in progress, because I agree with you that it I really important that you can rely on the time slots doing what they should do.
Yeah… HA always have had these problems with startup unfortunately.
For me, it would be a good enough implementation if you just do something like this when you try to run the action of a schedule:
multiplier = 1
action_confirmed = false
while (multiplier < 5 and !action_confirmed) do
{
do action
action_confirmed = get confirmation of the action (like: is the temperature really set?)
if (!action_confirmed)
wait 10 * multiplier
multiplier++
}
if (!action_confirmed)
show a warning, or send notification to let the user know, that you could not do the action for some reason.
Of course this is just an example. What I’m saying is it does not have to be perfect. It just have to be good enough
That is the most beautiful piece of python I have ever seen!
But I get the point, exponential backoff could be a good way.
I was hoping to be able to just register a callback for when the device comes back alive, rather then polling it.
But documentation of the HA functions is really poor, don’t know yet if this is doable…
This is what I meant. Using button-card and state-switch in conjunction with schedular-card.
Ofcourse this is just an example, but this gives an idea why it’s unnessecary for schedular-card to have this built in and become too bloated. There are already other ways to organize this since schedular-card has the discover_existing variable. Swiper card is also a nice solution instead of state-switch
If people are interested how to recreate this, code below. Ofcourse don’t copy/paste since I use my own stylings and entities. But it’s very simple if you take the time to understand how state-switch works (which is simple to use).
One thing to keep in mind with swipe card: using sliders withing swipe card doesn’t work nice (since you are moving a slider and the swipe card itself). But you can also just press spots inside a slider (like I did in the video).
Ahh… that’s the solution then. The former implementation was working with Touch Interfaces on Firefox, but not where Touch input is non-existent. Although it is already fixed, so everything is in order