And hopefully soon there will be support to install transformation from the marketplace too. Core changes are done so we are just waiting on the UI to implement it.
2 Likes
Maybe interesting for somebody here:
There is already a spreadsheet-application, that imports openhab things, items and rules and let’s you manage them:
I just tried it (after years) and it’s still working with OH4.2.1.
1 Like
Will be great to have the option to click on the lock and transfer the file config to UI
I’ll definitely be trying this - for any items I wish to “re-create” I’ve been picking bits out piecemeal. I knew I could get it via the API, but the work seemed insurmountable. I’m happy enough with my Google Sheets templates, but populating it in bulk with anything pre-existing would help a lot.
Well I just found something interesting using the UI.
I have a rule that I wanted to call a scene from (rules.runRule(‘8061f1a352’);). In order for me to find it again in the rules listing so I can see the sysntax I used I thought I would tag it as a scene. BAD idea as it converts the rule to a scene and therefore I lost all of the rule.
In this scenario using files would have been good because I could just restore the lost rule.
Anyway I though OK I can restore from the json backups. Which worked as I was able to just copy the automatiion_rules.json back over the corrupted one.
Before I did this I made a full backup of openHab just in case that didn’t work.
I then started OpenHab and the rule was still missing. I didn’t go back to the backup before the corruption.
I though OK, no big deal I will stop openHab and go back one more backup to get the missing rule back again.
I did a list of the backup directory and there was nothing there. No backups! Guess what DON"T run a clean-cache because it deletes all the backups!
So, again, if I had files I could get the missing rule back very easily from my backups.
The way I managed to get my missing rule back was to start my test openHab and copy it from that system to the production system. Luckly I had a copy of that rule in the test system.
So many lessons learned today on what not to do.
My question:
Is there a way to only copy a single rule from the json backup files?
1 Like
When I make significant changes to a rule, I first crate a copy of it with simple clicks in the UI and disable the copy.
If my changes do not work, I can simply remove the broken rule and change the label of the copy.
Good idea.
I usually copy the text into a file and if the rule fails then I copy it back.
I usually run a full backup, but in this case the rule was destroyed when I made the tag scene.
Now I know DON’T tag a rule scene or the rule gets destroyed.
Versioning capabilities are a strong point for textual configuration.
I think in this discussion it’s well worth to distinguish between Thing and Items on one side and Rules on the other one. I also use the UI for the former but text for the latter.
2 Likes
Or copy back the code from the rule copy…
I sm using openHAB since 1.2 and even at that time, I never felt to need versioning.
Proper backup before changing something was always sufficient 
Well, depends on complexity of your rules, doesn’t it.
I know, real experts write code using “cat > myrules.rules<<EOF” and gurus even write compilers that way but I’m none of those so I’m happy there’s now stuff like git.
I automatically run a rolling backup twice a day and back that up using bareos to another server and can go back 12 months.
I always have at least 3 backups on different locations/servers.
I even have backups of the server and hardware, just to be sure.
1 Like
No, don‘t think so, just need to know what to backup and in case of the need, what to restore.
So you’re doing software development but don’t need versioning tools because you’re writing perfect code on any first attempt and code is self-documenting ? Congrats
I never said that, it was just about rules in my productive system.
Development runs on VM‘s where i take a snapshot before every session. Besides that, I use git for development versioning.
for the OP question.
I’m using text-based only setup.
It’s for me way more convenient to change something than it is in UI where it is usually a lot of clicking and so on.
I’m using UI mostly for verification of the naming on the channels or bindings configuration if they are not well-documented. But’s it’s not usually needed.
all things, items, rules I have as workspace in my VSCode with OH extension, works reliably for years
1 Like
There are a few tags you have to be careful of. “Scene” is one of them. “Script” is the other major one.
I wonder if there should be some protections or error checking built into MainUI to maybe ask “are you sure?” before letting you set those tags. Might be worth an issue on openhab-webuis.
By “lost all of the rule” do you mean that OH stripped off the scripts and triggers and stuff? Or just that the rule disappeared from the UI? If the latter, you could have stopped OH and removed the tag manually from that rule’s entry in the JSONDB manually. That would have been the least disruptive approach.
Hmmmm, it should not do that. Please file an issue on that on the GitHub - openhab/openhab-linuxpkg: Repo for Linux packages repo. Clearing the cache should under no circumstances delete the JSONDB backups.
The easiest would be to use the REST API. Copy the JSON of the rule (exclude the , after the last }) and paste that into the PUT rules/{rule UID} REST API endpoint in the API Explorer.
Of course you could also copy/paste/insert into the JSONDB file directly as well but using the API would provide some error checking.
This is a good practice I also use all the time. There’s an option to create a copy of a rule on the Rule’s page for those who don’t know.
There was work to add a “Copy” option to Things at some point too. I don’t know what happened to that PR though. I thought it got merged but I don’t see the option.
I had a few minutes so I ran a test. I created a new rule:
configuration: {}
triggers:
- id: "1"
configuration:
itemName: TestSwitch
type: core.ItemStateChangeTrigger
conditions:
- inputs: {}
id: "3"
configuration:
type: application/javascript
script: console.info('Test rule condition');
type: script.ScriptCondition
actions:
- inputs: {}
id: "2"
configuration:
type: application/javascript
script: console.info('Test Rule action');
type: script.ScriptAction
In the JSONDB it appears as:
"testRule": {
"class": "org.openhab.core.automation.dto.RuleDTO",
"value": {
"triggers": [
{
"id": "1",
"configuration": {
"itemName": "TestSwitch"
},
"type": "core.ItemStateChangeTrigger"
}
],
"conditions": [
{
"inputs": {},
"id": "3",
"configuration": {
"script": "console.info(\u0027Test rule condition\u0027);",
"type": "application/javascript"
},
"type": "script.ScriptCondition"
}
],
"actions": [
{
"inputs": {},
"id": "2",
"configuration": {
"script": "console.info(\u0027Test Rule action\u0027);",
"type": "application/javascript"
},
"type": "script.ScriptAction"
}
],
"configuration": {},
"configDescriptions": [],
"uid": "testRule",
"name": "Test Rule",
"tags": [],
"visibility": "VISIBLE",
"description": "A nonsense rule that to convert to a scene to see what happens."
}
}
You can see it has a trigger, action and condition.
I added “Scene” as a tag and as expected the rule disappeared from the Rules page but appears on the Scenes page.
Of course it’s not formatted as a scene so the page looks like nothing has been set.
Looking at the JSONDB though, I see that the contents of the rule are still there.
"testRule": {
"class": "org.openhab.core.automation.dto.RuleDTO",
"value": {
"triggers": [
{
"id": "1",
"configuration": {
"itemName": "TestSwitch"
},
"type": "core.ItemStateChangeTrigger"
}
],
"conditions": [
{
"inputs": {},
"id": "3",
"configuration": {
"script": "console.info(\u0027Test rule condition\u0027);",
"type": "application/javascript"
},
"type": "script.ScriptCondition"
}
],
"actions": [
{
"inputs": {},
"id": "2",
"configuration": {
"script": "console.info(\u0027Test Rule action\u0027);",
"type": "application/javascript"
},
"type": "script.ScriptAction"
}
],
"configuration": {},
"configDescriptions": [],
"uid": "testRule",
"name": "Test Rule",
"tags": [
"Scene"
],
"visibility": "VISIBLE",
"description": "A nonsense rule that to convert to a scene to see what happens."
}
}
Interestingly the action doesn’t appear on the Code tab in the UI.
items: {}
triggers:
- id: "1"
configuration:
itemName: TestSwitch
type: core.ItemStateChangeTrigger
conditions:
- inputs: {}
id: "3"
configuration:
type: application/javascript
script: console.info('Test rule condition');
type: script.ScriptCondition
So at this point you could simply stop OH and remove the “Scene” tag, or, what I did was query for the rule using the REST API and then put it back without the Scene tag.
That is usually faster than stopping OH and editing the JSONDB manually most of time.
And you can see the rule is back.
configuration: {}
triggers:
- id: "1"
configuration:
itemName: TestSwitch
type: core.ItemStateChangeTrigger
conditions:
- inputs: {}
id: "3"
configuration:
type: application/javascript
script: console.info('Test rule condition');
type: script.ScriptCondition
actions:
- inputs: {}
id: "2"
configuration:
type: application/javascript
script: console.info('Test Rule action');
type: script.ScriptAction
tl;dr, the rule does not get destroyed and can be recoverd with a quick trip to the REST API to get it back by removing the Scene tag.
I still think the UI should give a warning when applying “Scene”, “Script” , or “Schedule” as a tag to a rule. It’s not necessarily an error to do so, but it is surprising when the rule disappears from the Rules page.
I use git for my managed rules and have indeed had to restore from an earlier commit on occasion. It works nicely.
My most complex rules I’ve turned into rule templates which can only be published as managed rules. So I have been forced to figure out how to make that sort of thing work even with the JSONDB. My workflow would be much better if I had the ability to install and test out rule templates without needing to create an entry on the marketplace though. But even what I have now is managable.
5 Likes
I just checked and it DOESN’T delete the backups. That is good. I don’t know what happened when I did the listing. Maybe I wasn’t in the correct directory or a different terminal as I had a few open. I think I just got flustered and panicked 
Thanks for all the tips and hints about the REST API. I don’t use it much as I could never understand how it works. I am not a developer just a user who has a system that does what I need to do and I try to keep it simple.
I will continue to just use the UI though even though files would have saved me easier this time.
The rest API explorer has pretty good inline descriptions and explanations for what each end point does. And that’s the same calls that MainUI uses to do things. Anything you can do through the UI you can do through the API explorer. It’s definitely worth a browse through to see what’s there even if it’s not something you’d use very much.
1 Like
I think I will add a check inside the UI to disallow the addition of the Scene tag to rules and scripts as well as the Script tag to rules and scenes.
This way users should not be able to accidentally add these special tags.