When 25% of a 200 post thread is about one particular issue its probably time to separate that into a dedicated thread. That’s not de-legitimizing it, that’s just because its overwhelming. There’s a lot of folks (like me for example) who simply could not care less about minor changes in the UI (borders, colors, etc.) There’s also plenty of folks that care a great deal (clearly by the discussion here).
So when an important but broad thread like this one becomes about a single topic then this becomes a problem. Other users with unrelated problems to that subtopic get drowned out and the people trying to help folks miss their posts. And users who simply don’t care about the problem under discussion ignore it and assume everything is about that one subtopic.
Hence the split. Doesn’t mean its not an issue or unimportant.
I don’t want to replace my google calendar. Definitely not with a local on in HA.
But in my view the local calendar ist primarily useful as a task planner. For chores, maintenance etc.
Since the calendar has no way of informing me, it has little use. I might as well use one of the blueprints for todos/chores/reminders/task planners.
But okay, I thought it was supposed to be useful in an HA frame. Simply having a local calendar with no useful features apart from an “entry”, you might as well add that extra tiny bit of info directly in all your manually created automations.
Sorry, seems just as superfluous as the color changes to me right now.
Agreed, but NOT to a “Social” section and not some separate posts.
And, most of the posts about color were rather polite - and ignoring them does not look good for a person who was addressed.
Dude, the tools that we use to move posts allow us to select a post and it auto selects the replies. Everyone who is upset literally replied to each other, it’s just a coincidence.
As I said before, flag the posts you want moved into that thread and I’ll gladly do it.
I mean just to clarify, if you want a chores calendar that notifies you about the chore that needs to be done now that can be done with a single automation.
Can obviously pack a lot more info into these notifications if you want, can use any info from the event. Look here to see how to get to the other metadata.
Even if the HA team wanted to do more then this it would take a while. It’s not actually possible right now because there is no notify selector. So there is no way for a user to simply select the notify service to send the reminder too from the GUI, something that would have to be done before building a feature that allows the user to choose when and where to send reminders for events.
But in general HA wants automation logic in automations. Whether that means sending a notification or automatically changing your lights, blinds, thermostat, etc. when the calendar event pops up.
With that little to go on, there is not much anyone can do I am afraid.
Have you checked the logs? Have you enabled the debug protocol for that integration (can now be done from the integration config screen) to see if that provides an explanation? If you have collected that and were not able to resolve it, please open a bug ticket.
Yes, and that is nice, but the question was: why not add one more dropdown to the integration where you can select who or what to notify? Rather than having to create an automation manually, implement it in the calender UI.
Otherwise it is nothing more than one step saved in a multy step task (where the name and frequency is the least of the problems).
Maybe to make it clearer:
you used to do everything in automations or scripts.
No you do 10% in calendar and 90% in automations or scripts. So you shifted the smallest part (name and date) into a dedicated integration and the user essentially saves no time and no work. But actually loses time by using two separate UI components.
A calendar without a reminder or notification implemented is nothing more than a post-it note.
You dropped a really key part of that sentence, the “while”. The implication being that YAML will be supported while there are still things that can only be done in YAML. You should not expect the YAML to go away at least until the GUI reaches parity. Once that happens then perhaps it will become deprecated, most likely accompanied by an automatic migration unless that poses some unexpected challenge.
Why add a dropdown when you can utilize the automation engine and do whatever you want? I currently use it to schedule heating on/off. Should we add a dropdown for that as well? Where do we draw the line? Then it begs to ask the question: Why even have an automation engine if we can just add dropdowns that do small functions everywhere?
Then why even create a calendar if it has absolutley no function except hold a name and date. It is then merely a toy with no real use.
Sure, you can create whatever integration you want. but it must be allowed to ask if it will ever receive any functionality.
Basically a post-it integration with a nice UI but no Home Automation functionality what so ever.
If you need the advanced scheduling out of the GUI look at HACS Scheduler Integration and Scheduler card. It has very nice ui that would do most likely 90% of what you are asking for. Actually the new Local Calendar has some features that the HACS integration does not have e.g. to have schedule every 2nd week and so on.
I could also do it manually. I am just saying, we now have multiple integrations with similar features and non have all the basics of a modern calendar.
Look at your Android phone. You can have all infos plus a repeat function (set to days, weeks, months, years with freely definable x) and you have alarms & reminders.
How is that different from any other helper? Input text, input button, input select, input boolean, input number, counter, etc. All the helpers do absolutely nothing by default. In fact could go further, template integration, derivative, min/max, etc. they all do nothing by default. Their value is entirely in how you use them within automations (sending notifications, changing the state of physical devices, etc.) or how you choose to present them in the UI (dashboards, graphs, etc.)
Local calendar is essentially just a new kind of helper. It allows you to make a schedule. How you choose to use that schedule (notify someone, change lights, change thermostats, change blinds, interface with some other IOT device, etc.) is completely up to you and what you put in your automations.
I get that we’re used to notification options with calendars because pretty much all the personal calendar tools people have used have options like that. But this is really more of a schedule helper. And like all helpers, they do nothing until automations add that functionality.
I really like the Scheduler Integration and it will probably be perfect within a few iterations and I can deprecate my manual json calendar with the corresponding sensors in config. Good Job!
Then why even bother giving it an entire dashboard? Why not just add it to helpers if it has no more use than the basic helpers?
Either it is a very simple helper or it is a full calendar integration. Right now it is the first, not the latter.
