thanks for the solution!
Just be aware that this will no longer work the next time you upgrade due to the change detailed in the post I linked to.
Thank you will look into it when i upgrade
Is there any new work-around to initialize the rules on start up? I’m using version 2.4 and with the work-around from this thread 90% of the rules are initialized on start up, but a couple of them do not work anymore neither if I try to initialize them manually…
I’m not a big expert so maybe I’m messing with something…
Which type of rule (DSL, Paper UI, Jython, JS, etc.)? If you’re initializing them, then probably Paper UI. And which workaround helped? 
TMK, there hasn’t been any change since 2.4 in this area. Post the rules that aren’t working, and people in the forum may be able to help sort them out.
Sorry, Paper UI
I’m using Rule Engine (Experimental) misc-ruleengine - 2.4.0
As work-around I’m using the script “InitializeExperimentalRules”, the fact is that the two experimental rules that aren’t working now, were working before.
So these rules will not initialize manually? Do you see any errors logged when you try? You can find the JSON for these rules in your jsondb folder… maybe posting them will help.
I’m looking right now in the JSON file, I just realized that old experimental rules are still in this file…
1 Like
"a5d7d9c5-72d8-41a5-af8b-b8c986409756": {
"class": "org.eclipse.smarthome.automation.dto.RuleDTO",
"value": {
"triggers": [
{
"id": "1",
"label": "an item state is updated",
"description": "This triggers the rule if an item state is updated (even if it does not change).",
"configuration": {
"itemName": "Kitchen_Temperature"
},
"type": "core.ItemStateUpdateTrigger"
}
],
"conditions": [
{
"inputs": {},
"id": "3",
"label": "an item has a given state",
"description": "Compares the item state with the given value",
"configuration": {
"itemName": "AqaraWindowKitchen",
"state": "CLOSED",
"operator": "\u003d"
},
"type": "core.ItemStateCondition"
},
{
"inputs": {},
"id": "4",
"label": "an item has a given state",
"description": "Compares the item state with the given value",
"configuration": {
"itemName": "Kitchen_Temperature",
"state": "19",
"operator": "\u003c\u003d"
},
"type": "core.ItemStateCondition"
}
],
"actions": [
{
"inputs": {},
"id": "2",
"label": "send a command",
"description": "Sends a command to a specified item.",
"configuration": {
"itemName": "Heating",
"command": "ON"
},
"type": "core.ItemCommandAction"
}
],
"configuration": {},
"configDescriptions": [],
"uid": "a5d7d9c5-72d8-41a5-af8b-b8c986409756",
"name": "Temperature \u003c19°C",
"tags": [],
"visibility": "VISIBLE",
"description": "Window closed"
}
},
When posting something like this, or a log, it is very helpful to use code fences so that the formatting is preserved… and readable.
Everything looks OK. The only thing I could not recreate is the name of your rule. I’m not sure if the forum did something odd without formatting, or if there might be a strange character. When I use the degree symbol in a rule name, it shows as a degree symbol in the JSON, and the rule still works. If that’s not it, have you tried recreating the rule, and do you have the same issue?
1 Like
Sorry you’re right, now is really better
About the degree symbol is like that also in the json, I double checked, but I think that is the problem, a few days ago I added in the item dimension “temperature” just 'cause I wanted to display °C after the value… so it’s probably just a problem with rules with temperature item…
1 Like
Thank you, in the end I was able to solve the problem, using the temperature group item that doesn’t have the °C symbol in the value.
Thanks again for your tips, now everything is working like a charm and I have a clean json rules file 
Hold up a sec. I’d like to see if the problem is reproducible. In your JSON, I only saw a degree symbol in the name of the rule. Are you saying you were trying use a Condition to compare the state of a Number:Temperature Item? I haven’t tried that in Paper UI.
OK… I’ve tested this, but not with the same results as you. It looks like Conditions are not working if they contain an Item with a dimension. I’ve tried comparing the state to just a number, and to a number with a unit. More testing needed, but I’ll open an issue if I can confirm. The rule always initialized after saving or disabling/enabling.
That is my experience as well. Conditions using UoM defined Items do not appear to work in PaperUI. It’s one of the many things on my list to circle back on and look more into. But it has popped up on the forum more than once over the past couple of months.
1 Like
Thank you for confirming… I was hoping you’d jump in here!
In my case, the item gTemperature is a number based on AVG function
If I use directly the item linked to the temperature sensor, I have to select the blank option in the dimension field of the item.
I’m just starting to figure out UoM stuff myself so I wasn’t sure whether it was an ID-10-T problem or something real. But when I read your response I’d say for once it wasn’t a self inflicted problem.
I should also mention that I don’t think UoM works with Actions either, unless you happen to be using the same units as the default. But I’ve not played with that much either. I do remember though trying to use “send command to an Item” for a Number:Temperature that I think uses degrees C as the default using an F and it not working. But I did so much that day, I can’t remember if it errored out or I got the wrong result. My main focus was on exploring the possible so I let a lot of that sort of thing slide.
I could be wrong, but I kind of remember seeing ConfigOptions for UoM Items, but now I’m not. This is Firefox and a Number:Temperature Item…
Pushing an update through the console, the rule triggered, but the Action did not fire. The same occurs if a unit is used in the Condition.
openhab> smarthome:update US_AnyaBathroom_Motion_Temperature 75 °F
2019-02-08 15:41:56.240 [DEBUG] [org.eclipse.smarthome.automation.core.internal.RuleEngineImpl] - The trigger '4' of rule '03706a59-b008-45c2-b13e-da32efdd8bd6' is triggered.
2019-02-08 15:41:56.241 [INFO ] [smarthome.event.ItemStateEvent] - US_AnyaBathroom_Motion_Temperature updated to 75
2019-02-08 15:41:56.241 [DEBUG] [org.eclipse.smarthome.automation.module.core.handler.ItemStateConditionHandler] - ItemStateCondition '5'checking if US_AnyaBathroom_Motion_Temperature (State=73.0 °F) < 80.0
2019-02-08 15:41:56.241 [DEBUG] [org.eclipse.smarthome.automation.core.internal.RuleEngineImpl] - The condition '5' of rule '03706a59-b008-45c2-b13e-da32efdd8bd6' is unsatisfied.
2019-02-08 15:41:56.241 [DEBUG] [org.eclipse.smarthome.automation.core.internal.RuleEngineImpl] - The rule '03706a59-b008-45c2-b13e-da32efdd8bd6' is NOT executed, since it has unsatisfied conditions.
2019-02-08 15:41:56.243 [INFO ] [smarthome.event.RuleStatusInfoEvent] - 03706a59-b008-45c2-b13e-da32efdd8bd6 updated: RUNNING
2019-02-08 15:41:56.244 [INFO ] [smarthome.event.RuleStatusInfoEvent] - 03706a59-b008-45c2-b13e-da32efdd8bd6 updated: IDLE
2019-02-08 15:41:56.248 [INFO ] [smarthome.event.ItemStateChangedEvent] - US_AnyaBathroom_Motion_Temperature changed from 73.0 °F to 75.0 °FI’ve always felt that support for UoM in Rules was always a little under documented. Perhaps no one has even looked at UoM in relation to the JSONDB Rules. They are working in JSR223 though, right?
The Scripted Automation default scope has what most people will need. But you can also directly use the libraries.