Hi,
I currently use UI based scripting (python)
I have seen many posts about file based scripts.
What is the community’s thoughts about UI versus file based?
What is better in the long run?
I think about back up, source control and so on.
Another wondering is Things and Items, pros/cons between UI and file based…
Has there been a discussion about this topic?
I currently run 5.1.* in docker (linux)
I think the difference is less dramatic than some make it sound. It’s a tradeoff really:
For UI based rules (and Things, Items etc.), you have the convenience of editing them in the UI. File based entities are read-only, so you can view them in the UI, but not change them.
In return, you get more “control” when things are file based. Nothing will change unless you do so, there will be no surprises because you happen to change something you didn’t mean to when you operate the UI, there will be no potential bugs that “corrupt” your data, and upgrade scripts won’t be able to “help you” convert stuff when you upgrade. You also have the benefit of being able to organize and back up the files exactly as you wish, using Git for example, and have the file (and the back-up itself) be in a format that is easily readable. You can also change the files while OH is running, and they will be reparsed and things updated in OH.
UI based entities are all stored in the JSONDB. It, too, can be backed up, but it will all be in a somewhat less readable format (JSON), and you can’t make changes to them while OH is running. If you want to change UI based entities while OH is running, you must do it using the UI.
The perhaps biggest advantage with file based rules in particular, is that you can use the scripting languages themselves to create the rules (this is easiest in the languages that have helper libraries that aid you, like JavaScript, Python, Ruby, Java223). These rules have some drawbacks in that they can’t do everything other rules can do, but they can usually do what most people need, and when you create the rules this way, you can make them in your favorite IDE or editor, with syntax highlighting, suggestions, automatic lookup and all those things that makes writing correct syntax much easier.
New in 5.2 is that also rules can be YAML, which is a kind of “file-based variant of UI rules”. You don’t get syntax highlighting and all that, but you get the “control” over changes, back-ups etc. that you get from other file-based variants. You can even export your existing UI rules to YAML from the UI, so you don’t have to create the files yourself. But, this requires 5.2.
In the end, it’s all up to you and what you prefer. Any solution is “as valid” as any other as I see it.
What can’t file-based rules do that the UI can?
Many many many topics. It comes up about once every six months. And the discussion always devoles into a religeous war.
Neither approach is going to go away. There isn’t a whole lot that one can do that can’t be done in the other. So use which ever one is best for your perferred way of developing.
Use which ever you prefer. Neither one is better or worse. Either one can be configuration controlled in git and backed up.
And with the new translators in 5.2, you can export your UI configs to file based configs and paste your file based configs into a UI config from the code tab. I hope at some point we get a proper import/export. But even now, you can experiment with file based and move back to UI if it doesn’t work out. You are not really stuck with either approach like we were in the past.
I’d only add that it is already automatically backed up on evey change. The number of backups is configurable in MainUI → Settings → Json Storage. The backups can be found in $OH_USERDATA/jsondb/backup.
YAML file support is there for widgets and pages now though right? Or did that not make it into 5.2?
That’s not to say there are not alternaitve ways to achieve these same things in a file based rule. But those would be alternative implementations. And I’m pretty sure these are things that few if any file based rules user even cares about.
We’ve been through this so many times. There’s nothing a file based rule can’t do, but when you say file-based rules, you usually don’t mean that. You mean SimpleRules. And they have restrictions, thus the name “Simple”. From the top of my head (I’m sure there are more restrictions), they cannot have more than one action. They cannot use conditions in some languages because the helper libraries don’t provide a way to create them. They can’t be “stored”, (JSONDB, YAML etc.), they must be regenerated every time OH starts. They can’t use rule templates. The whole idea with SimpleRule is to make a subset of Rule where things are “simplified” to the most common use cases, which make them easier to create from code.
The export is relatively “proper” already, at least for rules. You can select every rule if you so with, and export them all to one file (within the restrictions of what rules can be expressed in what format). Import isn’t as “streamlined”, but in most cases you can simply open the file-based rule in the UI and click “Duplicate rule”, and you get a “UI based” copy with a new UID, but which is otherwise identical. But, you must do that for each rule manually, so there’s no “bulk import”. Only Items have “bulk import” at the moment I believe.
It made it into 5.2, and so did support for block libraries. I think pretty much everything is there except transformations… and perhaps one more thing that I don’t remember.
You can store scenes in YAML, but they won’t “look like” a scene, but a rule. Once parsed by OH, they will show up like any other scene in the UI though. But, exporting them to YAML is quite “hidden” because they aren’t really supposed to be treated as rules, and nobody has defined a syntax for scenes. So, you must open the scene in the UI, edit the URL and replace “scenes” with “rules” in the address bar, and then export it to YAML from there.
Thanks all for the response.
I understand that there is no single “best practice”. There are many.
I will need to sit down, do some experiments and see where I land.
Thanks!