I have deleted some items recently (Z_Watervalve_Num), but this one still shows up in logs:
2018-09-23 09:05:18.056 [ERROR] [jdbc.internal.JdbcPersistenceService] - JDBC::query: unable to get item for itemName: 'Z_Watervalve_Num'. Ignore and give up!
Actually after deleting them I created a brand new mariaDB, cleared the cache and tmp folder:
sudo rm -R /var/lib/openhab2/tmp/*
sudo rm -R /var/lib/openhab2/cache/*
So I am a little surprised thate the item still shows up.
Did I miss something?
Did you stop OH before clearing the cache and restart afterwards?
I even did reboot the system
Did you create this Item in PaperUI? Have you ever linked this Item to a Channel through PaperUI? I’ve found that if you delete an Item that has been linked through PaperUI, the Link remains and some parts of OH apparently look to this Link. Look in /var/lib/openhab2/jsondb/org.eclipse.smarthome.core.thing.link.ItemChannelLink.json and make sure there isn’t a Link hanging around.
Thanks for the hint.
I will check it.
Items are in my item file and i usually check the link in PaperUI but don’t link them with PaperUI.
Again, thanks for your help.
I had simular problem once. Though this was mainly due to havning links in PaperUI as well as in items files.
I couldn´t remove the link via PaperUI, so I had to use Karaf consol and do some trick, (which I cant seem to remeber right now). It´s something about deleting all items, and then restart (reboot). OpenHab will read the items files and create the links again on the next boot.
I´m pretty sure @vzorglub or @rlkoshak can remeber the console command or perhaps make a search for it.
I’ll recommend that step
Open the file as a text file and do a search for the items that are hanging around and remove the entries.
Save and check with a tools like VSCode or jsonpath.com that your json syntax is correct BEFORE restarting OH
Actually I need to revive this thread…
I found again some of the items in my log:
2018-11-24 08:01:59.043 [ERROR] [jdbc.internal.JdbcPersistenceService] - JDBC::query: unable to get item for itemName: 'WWOnOFF_Num'. Ignore and give up!
2018-11-24 08:01:59.572 [ERROR] [jdbc.internal.JdbcPersistenceService] - JDBC::query: unable to get item for itemName: 'Heat_HzDN_Num'. Ignore and give up!
Before a restart yesterday I did:
- Stopped OH
- Deleted all logs in /var/log/openhab2
- deleted files in cache and temp
- deleted the sqlite DB /var/lib/openhab2/persistence/sqlite-jdbc.db
Right now I juste checked the file mentioned above:
and no xxx_Num item can be found.
It does not hurt, but I would like to know what’s wrong.
Any other idea?
By the way: I kept my mapdb, but as this log entry above is related to jdbc, I guess it shouldn’t make a difference.
Check the Item.json file as well. Then check your .items files.
Thanks for your help again.
You mean this one:
and of course my items config file is clean
Are these Items mentioned by name in any of your .persist files?
No, just groups from my items file.
Next thing to look at. Open https://ohserver:8080/rest/items?recursive=true and look through the returned JSON for these Items.
If they are not there I don’t know where else to look. It is pretty odd.
That’s a very helpful url.
Thanks für your endurance.
But unfortunately none of the two items show up here either.
Never mind. Maybe it’s not worth putting more effort into this, because I don’t see any side effects.
It would be interesting just out of curiosity.
Well, I think we have pretty definitively discovered that the two Items are gone. But something in the persistence config thinks they are still there.
Maybe there is a bug in the jdbc add-on that causes it to not forget Items that have been deleted.
You might be right, but it’s not critical (for me).
Thanks again for your help!
By the way, I very much like your dash button thread and just implemented 3 of them.
My wife loves the one at the entrance door to trigger her heater in the car .
This increased the WAF and her acknowledgement of OH significantly.
Just an update about my latest findings (maybe it helps someone):
I recently changed item names (again) and got the same problem.
(jdbc looking for the old items).
Furthermore I got the same item showing up in the openhab.log referring to a rule using the old item name.
Actually this was not the case as I have replaced all ocurrences of the old item name with the new name.
Even stopping and starting OH and deleting cache / tmp did not help.
What solved the problem was:
I deleted the rules file containing the problematic rule and copied it back under a new name.
So everything was reloaded / refreshed and obviously cleaned up.
(even though I did just change this single rules file, all persistence files and rules have been automatically reloaded.)
I don’t know if this is normal, that the entire rules structure and persistence is reloaded, if a singles rules file is added?!
This is normal. But it should have happened when you changed the .items file too. Also, stopping and starting OH should have reloaded everything as well.
The behavior described is truly bizzar.
The files have been reloaded after the restart, (at least according to the openhab.log) but obviously from somewhere else.
Just renaming the problematic rule fixed it.
At least I know a workaround
Of course you know what this sounds like? Whenever you have weirdness with files like this, it is often caused by a failing SD card. I once discovered a failing SD card because openhab.log wouldn’t rotate and just kept getting bigger and bigger. I would delete it and everything would be fine until I rebooted and the big log file would come back!