Does this mean you haven’t published it pending figuring out the configuration page? Or am I missing where to look. I’m excited to see what’s in it.
1 Like
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 think having the most common options as selections in the UI is good to have, but I also like the idea of having a raw data field to manually enter a cron expression.
4 Likes
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.
1 Like
My proposal is online: Next generation design: A Paper UI replacement proposal
But why. We can integrate or replicate the best tool in our UI. The one that I linked can express 100% of cron expressions, it is just not intuitive.
We maybe go with something like @vzorglub has linked above and provide only some options. And yes of course, the raw cron expression input will be there as well.
1 Like
I am sorry but I couldn’t for the life of me make “On the last Sunday of March at 02:30” for example which is something use for dealing with summer/winter time changes with your cron builder
1 Like
Challenge accepted, let me try…
Edit: Ok it is easy to do “At 02:30 AM, only on Sunday, only in March”.
They are missing the “every” part for the right select bar. Ok, need to find another page then, sigh.
Yes, that’s easy
It’s missing the Last part, or even the 2nd or/and 3rd Sunday
Or things like last working day of x month…
I still believe that the link I posted provides most if not all the cron options
1 Like
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”.
I use the Quartz cron, the one that OH uses:
0 30 2 ? * 1L * = At 02:30:00am, the last Sunday of the month, in March
0 0 7 LW * ? * = At 07:00:00am, on the last weekday of the month, every month
From:https://www.freeformatter.com/cron-expression-generator-quartz.html
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.
1 Like
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.
For me it would be fine to have the most common expressions at hand for configuring quick rules and an raw input for uncommon expressions with a link to freeformater for example.
No need to reinvent the wheel here.
If freeformatter (or whatever page will be used) closes, we will find a replacement and simply fix the url in that info field.
- No develoment knowledge needed
- Easily maintainable
- Third list point because 2 look weird.
1 Like
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.
Ira
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:
openhab:
- zwave: !!load_from_file zwave.yml
- items: !!load_from_dir items/
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.
Cheers, David
1 Like
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.
Clearly … no. Speak for yourself, but it’s foo nonsense that power-users=text-users.
Diversity. Nobody stops you from leaving openHAB and start using Home Assistant 
You are really here just because of ZWave. Sigh.
Now I get you. Please use proper terms. I was talking about Next generation design: A Paper UI replacement proposal, so the maintenance GUI. And you are talking about Habpanel. Please contribute to Habpanel then with your ideas, this is the wrong topic.