Hi, since updating to Openhab 1.8.3 I have an intersting behaviour for my rules. If i start openhab i get the below error. The error remains up until I open the *.rules file in Openhab Designer each *.rules file and save it again. After i do this its fine. I have a total of 13 rules files. I cannot imagine this being the issue. By the way, to make it even more interesting some rules files (randomly) load without troubles after restarting openhab.
Anyone the same issue or an idea?
I found in the forums and with google the same issue for some older versions of openhab, but no solution.
2016-06-24 22:07:20.586 [INFO ] [c.internal.ModelRepositoryImpl] - Refreshing model 'storen-sued-herunter-weekend.rules' 2016-06-24 22:07:20.640 [ERROR] [.o.m.c.i.folder.FolderObserver] - An unexpected exception has occured java.lang.NullPointerException: null at org.eclipse.emf.ecore.util.EcoreUtil.getAdapter(EcoreUtil.java:148) ~[na:na] at org.eclipse.xtext.xbase.jvmmodel.JvmModelAssociator.getOrInstall(JvmModelAssociator.java:90) ~[na:na] at org.eclipse.xtext.xbase.jvmmodel.JvmModelAssociator.sourceToTargetMap(JvmModelAssociator.java:165) ~[na:na] at org.eclipse.xtext.xbase.jvmmodel.JvmModelAssociator.cleanAssociationState(JvmModelAssociator.java:253) ~[na:na] at org.eclipse.xtext.xbase.jvmmodel.JvmModelAssociator.discardDerivedState(JvmModelAssociator.java:241) ~[na:na] at org.eclipse.xtext.resource.DerivedStateAwareResource.discardDerivedState(DerivedStateAwareResource.java:111) ~[na:na] at org.eclipse.xtext.resource.DerivedStateAwareResource.updateInternalState(DerivedStateAwareResource.java:59) ~[na:na] at org.eclipse.xtext.resource.XtextResource.doLoad(XtextResource.java:160) ~[na:na] at org.eclipse.xtext.linking.lazy.LazyLinkingResource.doLoad(LazyLinkingResource.java:75) ~[na:na] at org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1505) ~[na:na] at org.openhab.model.core.internal.ModelRepositoryImpl.addOrRefreshModel(ModelRepositoryImpl.java:99) ~[na:na] at org.openhab.model.core.internal.folder.FolderObserver.checkFolder(FolderObserver.java:142) ~[na:na] at org.openhab.model.core.internal.folder.FolderObserver.run(FolderObserver.java:99) ~[na:na]'
I’m replying to stay in the loop. I have the same issue but it started for me before moving to 1.8. After several attempts on google I’ve come to the following work around based on what was described as the cause of the problem.
1st:
I changed the timing for the file update detection in the openhab.cfg file. This helped out a lot but didn’t fix it completely.
2nd:
I read something about it’s the rules that are triggered at system start that’s the problem. I changed as much of these as I could but i think the results were inconclusive. However I still have a few startup rules that I can’t change. I read that someone took all their rules that trigger at startup and put it in one file to solve the issue. If this works for you great, but personally I think it will make a mess for organization. The only how I see this being acceptable is to create a startup.rules then create new rules that is triggered at startup and have it update proxy items, the proxy items will trigger the actual rules that needs to execute at startup. Not sure if this will actually work as now there are two rules for every one firing at startup and i haven’t had to time to test this as for me it involves a lot of changes for something i’m not sure would work. .
3rd:
This one eliminated the issue for me but introduced another issues and future issues. In my research someone mentioned that they moved their openhab instance to a new system for testing and the issue got worst. Turns out the new system was more powerful than the old. That got me thinking that my openhab is a dual core VM with essentially dual xeon 2.9g cores on a SSD raid. Fairly powerful for what openhab actually does. I changed the VM config to a single core and the problem went away. Unfortunately, being that openhab is running on windows there is a noticeable impact on performance at boot on a single core VM. Since OH starts with windows this would cause openhab to hang during startup (usually around the time it loads the zwave stuff) or not start at all. I added a timeout of 30 seconds to the beginning of the startup batch file and that fixed that. Next step is to streamline windows to get rid off all the non-essential crap that comes with windows so maybe I can get rid of the timeout. Under full load, with everyone home and doing things around the house, with rules firing off every second or two that single core is around 10% usage. It’s almost like openhab is not multi-thread aware?.. It’s as if it’s trying to do to much to fast during startup and that is when it trips up on the rules.
In any event, i’m not happy with the work around but they’re working at the moment and openhab is the best free automation system I’ve found so although i’d like to resolve this I’ve been living with it.
Very, very interesting! I had some other ideas to test the issue. One of which allowed me to at least successfully isolate the issue a bit more.
If i empty my *.items file, means no items in it, but just an empty file, than i do not face this issue anymore. As soon as I put items into the items file, I face the issue again. I can reproduce this error / issue as many times i want.
The items file itself seems OK. It does load and after changes re-load without any issue. Also, as described above, if i have openhab re-started and than i save the *.rules without any changes, it loads it without any issue/error.
Anyone an idea?
I am not sure about the openhab architecture, but could it be the case, that if you have many items > 100 and if you use in the same times many of these items for rules >10, that the items file is not fully loaded before the rules file start to load and that this then causes the issue? If this the case, than it would explain, why sc1982 in the above achieved some level of success by tuning the file update section. Not sure if anyone of the developers can say anything to this…
As soon as i have this in my items file, than the above described errors occure (even the item is not used at all in any rules). As soon as I remove it, i do not face the error. No idea why this item is destabilizing my system so much.
