remove the file openhab2-userdata\jsondb\org.eclipse.smarthome.config.discovery.DiscoveryResult.json (so the jsondb is empty again)
sudo systemctl start openhab2.service
After that all seems to work but only for about half an hour. I donât know how to handle that problem.
Maybe itâs the right time to switch to the Next-Gen Rule engine.
Is it recommended to start with the version in the latest stable openhab release (2.5.1-2) or should I use a other version?
Thereâs nothing wrong with the âoldâ rules engine. It works for everyone else - the problem lies in your system.
You might circumvent it by redesigning your rules into a new form - or you might just reproduce the same design flaws.
From your description. youâve got a rule(s) that is hogging rule execution threads.
Iâm basing that on -
Cron triggered rules use threads from a different pool, so theyâre independent.
Some kind of general system seizure would also be affecting events.log etc.
How many rules have you got? What can you temporarily comment out to reduce the suspects? Consider adding a logInfo() at the beginning of suspect rules to see when it starts, and another at the end to see when it exits.
Have you many modbus Items? Do you poll them fast? There is a change in default behaviour from v1 to v2 Modbus bindings that can hammer large configurations.
If you have rules triggering on modbus Item updates they can get hammered.
Yes, the version in the stable release is what you should use. For installing Jython, I recommend this bundle, which currently includes the helper librariesâŠ
Iâd be curious about your results, but I doubt changing the rule engine will change anything. And if everything worked properly, there would still be an underlying issue that was not understood. Chances are it is a configuration issue, but there could also be a bug. At the same time though, the new rule engine will be what is used in OH 3.0, so now is a good time to migrate.
That doesnât seem like a âlargeâ network for our purposes.
You might review for performance, but I doubt it is has a bearing here.
Unless you are triggering immense rules from updates! There are notes on rules design.
Also, SLF4J allows you to use parameterized logging, where the log entries that do not fit in the current logging level will not be processed. Meaning, you can put really complicated stuff in your debug log entry, but it wonât be processed when logging is set to INFO. However, the + operator will always be processed, so best not to use it.
/* *** Debug *** */
rule D2N_OG_Bad_HK_Stellgroesse_Ist
when
Item OG_Bad_HK_Stellgroesse_Ist changed
then
val String sRuleName = "D2N_OG_Bad_HK_Stellgroesse_Ist"
logDebug("Rule", "Start: {}", sRuleName)
[..]
logDebug("Rule", "Ende: {}", sRuleName)
end
the item changes doesnât stop. One of the three items I picked outâŠ
2020-02-13 22:57:09.990 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from NULL to 3.8
2020-02-13 23:17:22.190 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 3.80000000 to 3.90000000
2020-02-13 23:41:59.739 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 3.90000000 to 4.00000000
2020-02-13 23:54:06.375 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 4.00000000 to 4.10000000
2020-02-14 00:10:08.052 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 4.10000000 to 4.20000000
2020-02-14 00:22:10.325 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 4.20000000 to 4.30000000
2020-02-14 01:11:23.548 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 4.30000000 to 4.40000000
2020-02-14 01:31:28.793 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 4.40000000 to 4.50000000
2020-02-14 01:43:31.774 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 4.50000000 to 4.60000000
2020-02-14 02:12:39.363 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 4.60000000 to 4.70000000
2020-02-14 03:12:54.142 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 4.70000000 to 4.80000000
2020-02-14 03:54:06.535 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 4.80000000 to 4.70000000
2020-02-14 04:02:08.511 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 4.70000000 to 4.60000000
2020-02-14 04:10:11.521 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 4.60000000 to 4.50000000
2020-02-14 04:18:14.898 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 4.50000000 to 4.40000000
2020-02-14 04:26:17.071 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 4.40000000 to 4.30000000
2020-02-14 04:30:38.061 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 4.30000000 to 4.20000000
2020-02-14 04:38:20.101 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 4.20000000 to 4.10000000
2020-02-14 04:47:22.481 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 4.10000000 to 4.00000000
2020-02-14 04:59:25.475 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 4.00000000 to 3.90000000
2020-02-14 05:15:29.791 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 3.90000000 to 3.80000000
2020-02-14 05:51:38.810 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 3.80000000 to 3.90000000
2020-02-14 06:08:42.946 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 3.90000000 to 4.00000000
2020-02-14 06:20:47.181 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 4.00000000 to 4.10000000
2020-02-14 06:32:50.227 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 4.10000000 to 4.20000000
2020-02-14 06:44:53.206 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 4.20000000 to 4.30000000
2020-02-14 07:03:00.021 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 4.30000000 to 4.40000000
2020-02-14 07:13:00.019 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 4.40000000 to 4.50000000
2020-02-14 08:03:00.044 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 4.50000000 to 4.40000000
2020-02-14 08:33:00.024 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 4.40000000 to 4.30000000
2020-02-14 09:13:00.038 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 4.30000000 to 4.40000000
2020-02-14 09:23:00.055 [vent.ItemStateChangedEvent] - UG_TECHNIK_FW_Aussentemperatur_C changed from 4.40000000 to 4.50000000
âŠI will put this rules to time triggered rules and than switch step by step to the next-rule gen engine.
Note that a rule that âstopsâ is not necessarily any kind of problem. Some other rule may have gobbled up all the available threads, meaning others cannot start.
Looks like a big clue. âThat canâ't happenâ of course, because the variable is defined as the rules file is initialised. Except it is happening - so it tells us your rule file(s) is reloading.
Whatâs going on in your openhab.log, is that a filtered view we are looking at?
I suspect one of two things that seem to afflict some 2.5 users - one has to do with a messed up addons.config, the other is to do with Things changing and causing âsystem startedâ events.
No, I running on an HDD over the USB3-Port. I think that should be fine.
Yes, but I donât now why the error occurs. In the openhab.log I donât see any reloading files outside I restart openhab or change the rules manually.
I started the next-gen rule engine ⊠and it seems to work
2020-02-14 22:07:36.263 [DEBUG] [ipt.internal.ScriptEngineManagerImpl] - Added ScriptEngine for language 'py' with identifier: file:/etc/openhab2/automation/jsr223/python/personal/hello_world.py
2020-02-14 22:07:39.520 [DEBUG] [jsr223.jython.core.triggers ] - when: target=[Time cron 0/10 * * * * ?], target_type=Time, trigger_target=cron, trigger_type=0/10 * * * * ?, old_state=None, new_state=None
2020-02-14 22:07:40.237 [DEBUG] [jsr223.jython.core.triggers ] - when: Created cron_trigger: [Time_cron_0_10_0884a8cf4f6e11eaa917dca6320af300]
2020-02-14 22:07:40.244 [DEBUG] [jsr223.jython.core.rules ] - Added rule [Jython Hello World (cron decorators)]
2020-02-14 22:07:40.317 [DEBUG] [le.handler.GenericCronTriggerHandler] - Scheduled cron job '0/10 * * * * ?' for trigger 'Time_cron_0_10_0884a8cf4f6e11eaa917dca6320af300_08e20b0f4f6e11ea94a9dca6320af300'.
2020-02-14 22:07:50.316 [DEBUG] [e.automation.internal.RuleEngineImpl] - The trigger 'Time_cron_0_10_0884a8cf4f6e11eaa917dca6320af300_08e20b0f4f6e11ea94a9dca6320af300' of rule 'c8f3842a-22e4-4f4b-9337-8a608b86073d' is triggered.
2020-02-14 22:07:50.335 [INFO ] [Jython Hello World (cron decorators)] - Hello World!
2020-02-14 22:07:50.338 [DEBUG] [e.automation.internal.RuleEngineImpl] - The rule 'c8f3842a-22e4-4f4b-9337-8a608b86073d' is executed.
Yesterday I had the time to go on a step. I also update the openhab.
Now the version openHAB 2.5.3-1 (Release Build) is running
âŠbut when I start openhab I got following error message
2020-04-12 10:33:28.250 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.core.automation.module.script.scriptenginefactory.jython-2.5.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.core.automation.module.script.scriptenginefactory.jython [203]
Unresolved requirement: Import-Package: org.openhab.core.automation.module.script; version="[2.5.0,3.0.0)"
I tried following but without success:
Is there a new org.openhab.core.automation.module.script.scriptenginefactory.jython-2.5.0-SNAPSHOT.jar or ``org.openhab.core.model.script-2.5.0-SNAPSHOT.jar` to download?
Why are you trying to install that jar? Do you need the headers for the http actions? Thatâs the only reason to install it.
Anyway, what do you see when you list the bundles on the console?
bundle:list -s | grep script
I have:
173 x Active x 80 x 2.5.0 x org.openhab.core.model.script.ide
174 x Active x 80 x 2.5.0 x org.openhab.core.model.script.runtime
203 x Active x 80 x 2.5.0.202001221001 x org.openhab.core.automation.module.script.scriptenginefactory.jython
260 x Active x 80 x 2.5.0 x org.openhab.core.automation.module.script
261 x Active x 80 x 2.5.0 x org.openhab.core.automation.module.script.rulesupport
276 x Active x 75 x 2.5.3 x org.openhab.transform.javascript
289 x Active x 80 x 2.5.0.201912191214 x org.openhab.core.model.script
If you have the beta Jython bundle in addons, this is normal after the cache has been cleared⊠just wait a minute and the dependencies should be resolved and everything will work. If not, restart OH again.
The org.openhab.core.model.script-2.5.0-SNAPSHOT.jar is no longer needed after 2.5.0 stable and has been removed from the Google Drive link. There have been a few updates to the org.openhab.core.automation.module.script.scriptenginefactory.jython-2.5.0-SNAPSHOT.jar, but nothing really important unless you use third party modules.
it doesnât solve the problem. It only delayed it bevor the rules stopps working.
I wished I had done it already
I changed a