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
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.
foo? Do you mean true?
Not all… I use the paperUI exclusively to manage my things. It’s pretty much error proof and you can’t mess up the syntax. Once a thing is created and online there is no need to fiddle with it so it’s a one time job.
I, of course use text for items and rules because there are no real alternatives yet.
In every thread about UI there are users with many items which ask for textual configuration.
So let’s just be different just for the sake of being different?
I would have at least expected some logical or technical reasons.
Because our documentation ONLY shows textual configuration because Paper UI was a total mess. If there’s a actual good UI nobody will ever ask for textual files again. Pretty sure.
No you misunderstood. OH decided to do it like it is doing it now, and it would be a huge effort to turn that around. And just for the sake of HA uses it that we should use YAML as well is also not exactly fruitful. They have their own problems with YAML if you skim through the developer forum.
If you have to manage multiple openhab instances and have transfer things/items from one to another without transferring the whole config textual is still the way to go.
Textual configuration provides flexibility because it can be distributed and modified very easy.
Everything can created without the need for the openhab instance.
That was never the reason nor the intention. It is a possible (future) solution to the given problem and I think a good one. It provides flexibility and everything discussed so far can achieved with it.
Except new users are demanding it. Despite the “Experimental” in the name, new users are using it. The demand for this is high.
But it won’t be fine at the expense of JSR223. It will become the new default replacement for Rules DSL.
We already have this and it is used by some. OpenHABian will install NodeRed and there is a fully functional NodeRed node for openHAB. But I think outsourcing something as vital as Rules would be very much to the detriment of OH. We’re I starting fresh, I pick something else besides OH if it required instalation and configuration of since other service to implement automatons.
If you read the thread I linked to above you will see that is pretty much the consensus. Except instead of watching the file have a manual trigger to import or export so we have more contril over how they get loaded.
Also don’t forget that we need a migration path so users can switch from GUI to text and back without starting over.
Right, for now we have PaperUI for configuration and administration and for display we have sitemap based UIs, habpanal, and Habot. It sounds like you are proposing what we already have.
So e should ignore me users and less technically skilled users?
I can concur. Many of not most of the most active contrubutors on the forum use the UIs almost exclusively due Things. I’d use it for Items too if the UI were complete. And when the NGRE matures I’ll use the UIs for Rules.
But nowhere are we saying that we don’t want to accomodate those who prefer text.
I don’t know about that much. There are reasons such as source control that will make some users airways want the option. As discussed on that other thread, if the db file changes the order when it saves things the history will become mangled and unusable.
Yeah true. I came to the conclusion that the internal JsonDB is not suitable for backups. I imagine to have a backup service in OH3 that exports to yaml (or whatever we have settled for by then) with a stable order, suitable for revision control. And that is also used for to trigger imports and restores.
No - since there is no possibility to freely create complex layouts in the sitemaps and there is no possibility to create custom widgets. This is what I was trying to say with my HomeAssistant example:
Users can create, use and configure widgets using the existing configuration syntax.
It may not be intentionally but It sure feels that way since openhab2.
I never said that. I acknowledge and support gui based configuration if everything that is available in the gui is possible through some clean, textual configuration.
So why the need for the import/export and not serialize directly from/into the files?
I had two far openhab instances running which synced their configuration through my cloud service. It was nice and easy to configure and run them from my machine at home. I hat no access to the gui or the machine but once it was set up it still worked flawlessly. There should be at least the option to watch for file changes (and may it only be in the central config file).
Really? Could we at least agree to disagree?
Hm, why do you need textual files? I mean real files on a filesystem. You probably have seen the Paper UI design study already. If you assume that would be the status quo.
Because openHAB internally uses a json based database and that is not going away any soon as it is not even two years old by now. And people don’t like that json file at all, why do you think they like yaml better. There is a longer heated discussion about this topic existing.
Please see that mentioned discussion with a lot of technical background why that is a bad idea.
I’ll chime in here…
In my case, I have multiple openHAB installations that share some of the same technologies. As a consequence, I often copy snippets of things, items, rules, sitemaps, services, transforms, etc. files between the installations. And, I like the fact that I can track/manage all my changes using VS Code and Git.
But you have read about the import/export functionality that I mentioned above? In contrast to the status quo you would need to trigger an import/export, everything else is really like now. Please also read the mentioned discussion, because we are repeating ourselves here.
Sorry, I was simply responding to your recent post that suggests you still don’t see value in textual files.
Yes, I did. From my perspective, those are just extra steps that I don’t have today.
But when do you push your changed item/thing files? Isn’t that done manually or by a cron trigger or so. You would just need to add a openhab-cli export command. Is that really much more?