Nah I think it is not really missing those. You can toggle between things and they are still all applied.
Your page lists some common settings, but not all possible ways.
For example: “On the last day of the month” and similar. You can actually specify as many recurring days of a month as you want, they will be comma separated in the cron expression. If you want to be nice to the parser, you can use ranges for consecutive values.
But yeah cron expressions are super powerful and I’m struggling with the interface. Nevertheless, I will publish the Paper UI NG design study link in a moment with some initial words.
I’ll second Scott. Is this a case where it can make sense to provide a UI that covers most of the cases and provides a more free-form raw cron entry to cover the more complex cases like “third Thursday of the month”? We still have access to external cron builder tools that can help users figure those out.
I’d hate to see the UI mangled in the name of completeness to support 1%-2% of use cases. Though, if it can be done so much the better.
Although I have googled and the original cron syntax does not support “last sunday” and “last workday”, must be an extension that you are using. You can express “every 4th sunday” or “every 4th saturday&sunday”.
Quartz has L and W flags additionally, true. Puh. How does a user interface look like to support all those features. I really think that we provide only a simple cron expression enter box and a utility below to help with the most common cases.
That is what I was proposing. Handle the most common options and for the exotic cases provide a way to enter a raw cron exptession built by hand or using some cron exhortation building tool. I don’t think we can afford not to support the L and W flags in a home automation context because at least in the US, many important days like holidays, such to/from DST, trash pickups, etc are driven by “the xth day of the week of the month.” But I think I’m OK with support for that beimg an advanced thing instead of something natively supported by the OH UI.
I agree with this. 90% of my cron rules are simple rules like every day at 9:00, every day at 18:00, every weekday (MON-FRI) at 7:30, and so on.
I do actually have a few more exotic cron rules like every first Monday of the month, every last weekday of the month, and every last Sunday, for things related for example to garbage collection.
So I would really like to have some way to incorporate those rules into a new rules system whenever that becomes the main system.
If instead of the horizontal list of days, it was a vertical list with a grid of checkboxes to the right labeled, 1,2,3,4,L, it would be visually trivial to select nth weekdays of the month. It takes up some real estate and might need some rlimits so the rules can be created, but it should be easy enough for anyone to figure out.
This is my greatest struggle with openhab2 and probably why I want textual config back so much.
Items and rules are textual files so the need to configure one kind in the gui and the other in the files is so counter intuitive. Also when working with multiple openhab instances sharing part of the configuration is much easier.
The cron discussion should be postponed. I see little benefit in making creation of rules available through the UI. The actually trivial example of the cron-expressions and the already arising difficulties show, that rules are a way too complex topic to tackle alone. A proper (optional) integration of third-party rule engines like Node-Red would be less difficult and less time consuming.
I’d rather see time invested to make the openhab gui prettier and more flexible because that is what I see and use every day. Home Assistant took a really good approach with the lovelace ui. People share custom elements and their configuration in the forums and including them is really easy. But this requires a possibility to configure previously unknown value-structures and this will never be possible through the gui.
As for other configuration:
Why not serialize configurations through the gui into one big yaml file (e.g. openhab.yml) and just watch this file for changes but also provide the possibility to merge and load values from other files.
This way everyone should be happy:
Gui users can do some simple setup and have a functioning configuration in a central place (!).
Power-Users can still make use of things as auto discovery but have the possibility to split the configuration across files or even folders. Also there is now a single source of truth.
The workflow would be to do auto-discovery and then move parts of the created information to another file.
e.g the openhab.yml would then look like:
But you know that we are talking about Cron expressions because of a new UI, do you?
HA is currently in the lead, I second that. The hopefully changes this year, there is a lot happening.
Node red is a competitor, if you want. They are fully self-contained, have their own add-on eco system, inputs and outputs. Some people here do this, using openhab only for their add-ons and relaying all events do node red. And the goal should be to make OH so good that you don’t want to and don’t need to include a 3rd party app.
There is a huge discussion from just recently about this. Please have at least a look at the new paper UI design study if that is what you imagine.
And no, I don’t think we want to mimic homeassistant here, because that is your proposal, basically.
Yes - I was talking about the gui that is used to display values and interact with openhab. For me configuration and display/using are two different things. On the Tablet in the living room I don’t need to configure my instance - there I want a nice, fancy layout I can configure to my needs.
Tbh there are couple of users just sticking with openhab because the z-wave binding is so good.
Poweruses will always have the need for textual configuration for various reasons (has been discussed extensively) and these are the users that drive developement and contribute to the project.
Why not use a similar configuration system? It’s a nice and simple solution to the problem.
Just because another tool uses it doesn’t mean it’s forbidden for openhab.