Found something in the logs
2023-10-20 18:11:05.025 [DEBUG] [org.openhab.core.model.core.internal.folder.FolderObserver ] - Adding files in '/etc/openhab/things' to the model
2023-10-20 18:11:05.029 [DEBUG] [org.openhab.core.model.core.internal.folder.FolderObserver ] - Missing parser for 'things' extension, added ignored path: /etc/openhab/things/mqtt.things
2023-10-20 18:11:05.034 [DEBUG] [org.openhab.core.model.core.internal.folder.FolderObserver ] - Missing parser for 'things' extension, added ignored path: /etc/openhab/things/gpstrackers.things
2023-10-20 18:11:05.037 [DEBUG] [org.openhab.core.model.core.internal.folder.FolderObserver ] - Missing parser for 'things' extension, added ignored path: /etc/openhab/things/things.things
2023-10-20 18:11:05.043 [DEBUG] [org.openhab.core.model.core.internal.folder.FolderObserver ] - Missing parser for 'things' extension, added ignored path: /etc/openhab/things/telegram.things
Above entries are way above the entry for parser invocation.
2023-10-20 18:11:09.012 [DEBUG] [org.openhab.core.model.core.internal.folder.FolderObserver ] - Adding parser for 'things' extension
So whats seems to be happening is that the by the time the parser is initialised various files have been added to the “ignored path”.
How does one fix the issue - seems parsers need to get loaded ahead in the startup sequence ?
wborn
(Wouter Born)
October 20, 2023, 1:23pm
16
It’s normal and it should process the ignored paths once the parser is added.
When the parser is added and it completes processing the ignored things paths it should log:
Finished processing ignored paths for ‘things’ extension. X ignored paths remain
wborn:
Finished processing ignored paths for ‘things’ extension. X ignored paths remain
Thanks, I get log entries for rules and scripts, but not for things. That probably explains why the others load but not things .
Final entry is
Finished processing ignored paths for ‘rules’ extension. 7 ignored paths remain
How to debug further ?
wborn
(Wouter Born)
October 20, 2023, 1:35pm
18
The easiest is if you post the complete logging so we can have a look.
done
I have enabled trace only on some components, please let me know if you need levels increased for others.
Logger │ Level
────────────────────────────────────────────────────────────────┼──────
* │ WARN
ROOT │ WARN
e.internal.SseItemStatesEventBuilder │ WARN
javax.jmdns │ WARN
javax.mail │ WARN
openhab.event │ WARN
openhab.event.AddonEvent │ WARN
openhab.event.ChannelDescriptionChangedEvent │ WARN
openhab.event.InboxUpdatedEvent │ WARN
openhab.event.ItemAddedEvent │ WARN
openhab.event.ItemChannelLinkAddedEvent │ WARN
openhab.event.ItemChannelLinkRemovedEvent │ WARN
openhab.event.ItemRemovedEvent │ WARN
openhab.event.ItemStateEvent │ WARN
openhab.event.RuleAddedEvent │ WARN
openhab.event.RuleRemovedEvent │ WARN
openhab.event.RuleStatusInfoEvent │ WARN
openhab.event.StartlevelEvent │ INFO
openhab.event.ThingAddedEvent │ INFO
openhab.event.ThingRemovedEvent │ INFO
openhab.event.ThingStatusInfoEvent │ INFO
openhab.event.ThingUpdatedEvent │ INFO
org.apache.cxf.jaxrs.sse.SseEventSinkImpl │ WARN
org.apache.karaf.jaas.modules.audit │ WARN
org.apache.karaf.kar.internal.KarServiceImpl │ WARN
org.apache.karaf.shell.ssh.SshUtils │ WARN
org.apache.karaf.shell.support │ WARN
org.apache.sshd │ WARN
org.eclipse.lsp4j │ WARN
org.jupnp │ WARN
org.openhab │ INFO
org.openhab.binding.generic │ WARN
org.openhab.binding.homeassistant │ WARN
org.openhab.binding.mqtt │ INFO
org.openhab.binding.mqtt.generic │ TRACE
org.openhab.binding.mqtt.homeassistant │ WARN
org.openhab.core.io.rest.sse.internal.SseItemStatesEventBuilder │ WARN
org.openhab.core.model.core.internal.ModelRepositoryImp │ TRACE
org.openhab.core.model.core.internal.folder.FolderObserver │ TRACE
org.ops4j.pax.url.mvn.internal.AetherBasedResolver │ WARN
org.ops4j.pax.web.pax-web-runtime │ WARN
penhab.event.ItemStateEvent │ WARN
openhab.log (137.4 KB)
1 Like
wborn
(Wouter Born)
October 20, 2023, 1:45pm
20
Thanks for the logging. It seems to confirm one hypothesis I had for why the issue might occur. I think what happens is that parsers are added by other threads during activation. In that case it doesn’t process the ignored paths so I’ll create a fix for that scenario. During my own testing this never happened… probably because I’ve tested using faster hardware.
Thanks , i suspected that might been an issue since am running on really old hw rpi2
Q: why do the other parsers get added and parse the backlog, but not things ?
Is there any “hack” I can deploy in the interim to mitigate the issue ?
wborn
(Wouter Born)
October 20, 2023, 1:52pm
22
It’s because those parsers are added after the component has been activated, i.e. after this log statement:
FolderObserver has been activated
After it happens you can move the files temporarily to another folder and then move them back. That should retrigger the logic for adding the files.
tiknx
(Thomas)
October 20, 2023, 2:16pm
23
wborn:
After it happens you can move the files temporarily to another folder and then move them back. That should retrigger the logic for adding the files.
I added the system info binding and the execute binding via gui. Then I added a rule, that moves all file from /etc/openhab/things to /tmp and move it back when system is up for 5minutes
I also use a raspberry pi. But a raspberry pi 4. So this ist still not a very fast hardware, but ways faster than rpi2
wborn:
It’s because those parsers are added after the component has been activated, i.e. after this log statement:
FolderObserver has been activated
i get that, my query is that once the parsers are activated they clear “ignored paths” except for things. Why would things related paths remain unprocessed when others seem to work fine in the same scenario.
In above ignored paths was 32 before parsers got loaded. thereafter rules and scripts parsing ran leaving behind 7 for things.
Processing 32 ignored paths for 'script' extension
Processing 32 ignored paths for 'rules' extension
Finished processing ignored paths for 'rules' extension. 7 ignored paths remain
wborn
(Wouter Born)
October 20, 2023, 3:23pm
25
It’s because in the other cases the parser was added before it starts processing files during activation.
1 Like
wborn:
It’s because in the other cases the parser was added before it starts processing files during activation.
Thanks. btw, when will the fix go in (appreciate there would be other with higher priority on the backlog) and how would I be able to apply it on my setup ?
Do you want me to open bug / issue ticket for tracking ?
wborn
(Wouter Born)
October 20, 2023, 4:34pm
27
We already have a few issues for this.
I just created a PR with a fix:
openhab:main
← wborn:improve-ignored-paths-handling
opened 04:32PM - 20 Oct 23 UTC
The FolderObserver needs to make sure that paths are properly handled for any pa… rsers that are added at any moment by other threads during activation.
Fixes #3784
Fixes #3793
Now I need to test it.
3 Likes
wborn
(Wouter Born)
October 20, 2023, 7:27pm
28
It still works fine for me but I still cannot reproduce that parsers are added by other threads.
To test the fix, update the bundle on the Karaf console using one of these commands and then restart openHAB.
OH 4.0.x
bundle:update org.openhab.core.model.core https://github.com/wborn/openhab-core/releases/download/folder-observer-20231020/org.openhab.core.model.core-4.0.4-SNAPSHOT.jar
Recent OH 4.1.0-SNAPSHOTs or OH 4.1.0.M2
bundle:update org.openhab.core.model.core https://github.com/wborn/openhab-core/releases/download/folder-observer-20231020/org.openhab.core.model.core-4.1.0-SNAPSHOT.jar
1 Like
wborn:
It still works fine for me but I still cannot reproduce that parsers are added by other threads.
To test the fix, update the bundle on the Karaf console using one of these commands and then restart openHAB.
Thanks - this seems to have solved the issue. Attaching log file after restart in case you want to review.
openhab.2.log (125.3 KB)
Query: I am not able to find the bundle using bundle:list | grep org
. is that expected behaviour or is something awry ?
1 Like
, am waiting for the rpi5 to be available.
wborn
(Wouter Born)
October 21, 2023, 6:27am
31
Try using bundle:list -s | grep ...
instead.
wborn:
Try using bundle:list -s | grep ...
instead.
Thanks - that worked
188 x Active x 80 x 4.1.0.202310201909 x org.openhab.core.model.core
one related question - should all bundles be at 4.1.0 or can they be at different level / numbers. I have many at 1.xx , 2.xx, 3.xx as well?
wborn
(Wouter Born)
October 22, 2023, 8:52am
33
It should use the same version for all the org.openhab
bundles except for org.openhab.base-fixes
.
The other bundles are third party dependencies which have their own versioning and release cycle.
If you use a SNAPSHOT build it is expected for the timestamp parts (202310211708 in 4.1.0.202310211708) to be different because the bundles are produced by different build jobs.
Issue resurfaced in a different way. The parser loads followed by the .thing files but they don’t get added to the model. Touching file causes them to be added, however non file based things remain un-initialised.
The bundle reverted to the org version
188 x Active x 80 x 4.1.0.M2 x org.openhab.core.model.core
thats strange since i havent run any updates on the system…