Config files will not be discontinued in OH4 and we are a lot to hope they will mever be discontinued at all.
There are pro UI and there are pro files.
One chance is that there are probably more fans of config file than UI in OH maintainers.
That being said, it is not impossible that one day the text file format is changed but not in OH4. When it will happen, you can expect a convert tool.
Both JS Scripting and jRuby have excellent documentation in the add-on readmes with full reference docs and lots of examples and explanations. The docs are really quite good for these two.
Everything you need to get started is there or linked to from there.
For JS Scripting, a good learning strategy is also to build something in Blockly and look at the code it generates. In OH 4 Blockly ācompilesā to GraalVM JS Scripting.
There is a little bit of JS Scripting on Rules - Advanced | openHAB.
Groovy uses the raw JS223 API and doesnāt have a library so JSR223 Scripting | openHAB is going to be your reference.
No.
But most MainUI stuff will not have a text file config equivalent (pages, custom widgets, rule templates, etc.).
If you are doing that you havenāt reviewed the Getting Started Docs. Any entity in OH (Items, Rules, Things) are searchable and navigable from the developer sidebar (alt-shift-d). Minimal clicking through is required.
Can do the same with managed stuff, itās just a different set of text files.
Thatās because, for most users in most cases, auto discovering the Things and using ācreate equipment from thingā in the UI is more straight forward and faster than defining them in text files and struggling to get the syntax right. You donāt need to do anything to define the Thing except accept it and you can create all the Items linked to the Channels of that thing and have them situated in the semantic model in one go.
All Things can be defined through .things files. I donāt know which two bindings you are referring to but in all likelihood itās just that the binding authors didnāt document the text file based parameters.
But, there are some things that cannot be done with text file based things. The big example Iām aware of is setting properties on devices in the Zwave binding.
There is no tension though. Except in rare cases where discovery isnāt possible, almost all Things are discoverable and generated automatically for you. But to continue to support those who remain on text based configs, many binding authors also document how to define Things in .things files too. But when using discovery the steps are:
- manually create the Bridge (if required)
- scan for new devices in the Inbox
- Accept those Things you want to include in OH
First, if your only experience with UI is PaperUI, you know nothing about what MainUI is capable of. Itās so much better they are not even in the same league.
Many of the maintainers and a large number of your fellow old timers (been using OH since 1.5) have moved to UI everything with OH 3 (and as stuff like transformations and hopefully soon persistence is available in the UI in Oh 4 Iāll have everything but ephemeris configured through the UI). At the risk of speaking for others, we would not have the patience to configure our OH if it took clicking through 7 UI pages to change something simple. There are limitations of course, but itās not that bad of an environment to work in. I certainly wouldnāt have the patience for it if it were.
Some of the things you might be giving up with text based configs:
- some stuff will be UI only (e.g. custom MainUI Widgets, setting properties on Zwave devices, etc.), no one is volunteering to invent a text file based representation for these or there are technical limitations
- rule templates (why code a rule when you can just install and configure it?)
- Blockly
- ability to see and modify your config from any client (phone apps, browser) from anywhere (through myopenhab.org)
- much easier to set up and work with the semantic model
- much easier to define custom default widget Item metadata
- mostly self documenting
- almost never have to fight syntax errors (except in rules and transformations of course, though with Blockly not even in then)
- no third party editor required (and there is intellisense and code completion in the editor for rules code)
- Marketplace add-ons can only be installed through the UI I think, youād have to download and drop the jar files into the addons folder instead of installing them like any other add-on.
One does not manually edit the JSONDB files. At least not in the same ways youād edit .items files (etc.). Thatās not their purpose and thatās not the most efficient way to do it anyway. To change things youāll do it through the Karaf console, REST API, or the UI.
Note, as youāve found, they are only loaded when OH first starts. And if you edit it and then modify something through the UI your changes will be overwritten.
Note on changing the names of Items. This does not happen. The Item name is the UUID of the Item. When using .items files what happens is all the Items defined in that file are destroyed on unload and created anew on reload. Youāve not changed the Item name, youāve created a new Item with a new name.
So to rename an Item in the UI you have to do the same thing. You have to delete the old Item and then recreate a new one with the new name.
In both cases, rules, ui widgets, and persistence knows nothing of the new Item and need to be updated.
But, youād find in the UI that the Item label is what gets shown and used almost everywhere. Itās only in rules and UI widgets where you hard code the name of an Item where the name really matters. So the need to rename Items is no where near as vital as it is in text based files. And even then, itās not something that needs to happen frequently.
You donāt have to but if you are creating new rules itās probably worth looking at the new options. They are more complete (I still think that Rules DSL cannot access Item metadata) and support a full programming environment so you can have libraries, functions, etc.
So it will be huge problem for probably hundreds of OH users. Most users are not programmers. For me Jython rules are simple to read and adopt to my needs. But with other java languages (or others) there may be a problem.
Just out of curiosity, which bindings?
Nest (I cannot seem to get the authorization codes to stick after reboot through the text files).
I think I had a problem with the MyQ binding when it was in beta, but I guess thatās been sorted out now. So maybe itās just the 1 binding I have an issue with.
Itās not like we want this to happen. Itās out of our control when/if it does happen. Thereās nothing I personally can do about it except to warn people not to depend on Jython expecting itās going to be there forever. Of all the parts of OH, it is the most at danger of just up and quitting on us.
Itās been more than five years. Thatās a pretty good run. But nothing lasts forever.
And even if we had a replacement, that replacement is going to be very different. Itāll be Python 3 and itāll likely be built on a new helper library so all your OH interactions will be different anyway.
But Iāll say again, if you like Python, there is already excellent support for Python based rules in HABApp.
I can say that jRuby and JS Scripting are equally and in some ways even simpler than Jython.
And if you are not a programmer Blockly is excellent because itās all done with visual building blocks.
And donāt forget almost everything your rules do is interact with openHAB. All of those interactions use the same concepts and approaches. Itās not like trying to translate Mandarin into Swahili. Itās more like trying to translate Spanish into Portuguese. The words and syntax will be different for sure but over all youāve already figured out the logic and there will be lots of similarities.
This works for me:
Bridge nest:wwn_account:account [ productId="xxx", productSecret="yyy", accessToken="zzz" ] {
wwn_smoke_detector hallway_smoke "Nest Protect hallway" [ deviceId="aaa" ]
wwn_smoke_detector familyroom_smoke "Nest Protect family room" [ deviceId="bbb" ]
}
I donāt mind using UI for aspects that are not covered in the text files I already know. So I do use the web interface (I think itās MainUI) for certain things. Just not for my bindings, things, items, rules, or sitemaps.
Youāre right, I wasnāt familiar with the sidebar. Itās a nice option, though still requires a bunch of extra clicking that I donāt have to do in a text file thatās sitting open on my desktop. Iām sure itās not as bad as I made it sound, but I donāt like to learn new things (<-- a lie).
I guess the problem is itās not as obvious or documented which those are. I presume they are the .json files in the userdata/jsondb folder?
With the text files, I know which files I edit. So I know which ones I need to back up to save what Iāve edited. If I edit something in the UI, I have to trust that Iāve picked the right file storing that something.
Yes I know it is not your fault and nobody wants it to happen
But as I said hundreds of people learned how to use Jython. Blockly is a joke for me. Not so intuitive as it should be and possibilities it gives are really limited like GUI rules. And rules are esentail for good home automation.
Maybe it would be good idea to start a thread with examples how to ātranslateā Jython to other java languages?
Yes, thatās it. Though if you want your addons.cfg backed up too youāll want to grab the userdata/config folder. But really, if you want to backup your config, you should be using the backup scripts that come with openHAB or openhab-cli if itās on Linux.
First, backups are taken of the JSONDB files automatically on every change. You can set how many backups are saved under Settings ā JSON Storage and you will find them under userdata/jsondb/backup.
So you donāt have to pick the right file or even worry over much about it if thatās all you are after.
But there are other tools available also including rsync, git, svn, etc. to handle version control automatically or semi-automatically. You shouldnāt be relying on your memory for this in the first place.
You can also just look at the timestamp on the files.
Maybe it depends on when you looked but a lot of work has been on on Blockly in the past couple of releases. There is almost nothing left OH wise that can be done in Jython (for example) that cannot be done in Blockly.
I use SDM, and it does not work right through the text config. The working json file created through the UI has blank pubsubAuthorizationCode and sdmAuthorizationCode. When I try to create a thing in a text file with the same blanks, it gives an offline error and demands an authorization code. When I go through the process to get authorization codes and enter them, it works until I reboot and then stops again. Thereās some voodoo that the UI does that I donāt know how to overcome.
The authorization code is usually used to acquire the first auth-token and refresh-token. It should be thrown away after that. Once itās working, try removing the authorization code from the Thing before restarting.
Well what do you know, this seems to have worked! Thanks!
Hello,
I put this into my openhab folder
rule "My Scene"
when
then
switch_mobilemichael_presence.sendCommand(OFF)
end
But in the log an error is recorded
Configuration model 'scenes.rules' has errors, therefore ignoring it: [3,1]: no viable alternative at input 'then'
The rule DSL parser does not expect then
right after when
: you forgot to add the when
clause which triggers rule execution. Otherwise openHAB has no clue on when this rule should run.
Nope, I am afraid, DSL rules do not support scenes, which do not require a trigger (when clause).
So what does it mean for the scene configuration in a file?
AFAIK, it is not possible.