Background – main RPi3 running OH2 (snapshot versions for many versions) and a z-stick Gen 5 with circa 45 items, second RPi2 with Razberry daughter board running z-wave with 8-10 items. OH2 discovers the Razberry devices via the z-way binding.
Everything works (including controlling the z-way discovered devices via Alexa thru OH and the Hue emulation binding)…
BUT, over time I renamed some OH things coming thru the Razberry and now, every 5 minutes I get log messages of the form:
[thome.io.rest.core.item.ItemResource] - Received HTTP PUT request at 'items/sw_siren_demo/state' for the unknown item 'sw_siren_demo'.
for ALL of the Razberry-connected devices.
These messages are reflecting the old OH names that I had used…(I changed all the names in Paper UI to be prefixed with zz_ so they sorted together) The NEW names work fine in OH (and with Alexa).
So I am guessing there is some JSONdb file which is still retaining these old items and some interface binding which is causing the HTTP PUT requests.
This is just annoying. At a practical level, everything works, BUT if someone knows a safe way to get rid of these messages (or the underlying cause), I’d like to know.
If they are still in your DB, you should be able to grep for them in the jsondb files. Something like:
grep -i item name /var/lib/openhab2/jsondb
But there was I read the wire is that there is something else that thinks these items exist and is trying to change then though the rest API and failing because the items don’t exist (I.e. not in the jsondb).
Perhaps Alexa still thinks they exist? Having no experience without these technologies I can only guess.
Just FYI, Alexa was added after this problem appeared–so definitely non-causal. It’s something about the renaming of things thru Paper UI that is causal. I’ll grep the jsondb and let you know. @rgerrans is probably right here. I’ll confirm when I try it.
I’ll admit this is a weird one. But it almost had to be something"external" making rest calls that is causing the problem. You don’t have these items lingering around in a sitemap or HABpanel do you?
Most everything else in OH will use the core API and bypass the rest API.
As @rgerrans mentioned, clearing the cache and tmp couldn’t hurt.
Then I’d try Plan B of emptying cache and remp plus look for old config files (I had that issue with another binding where the config file got left after I deleted the binding, just don’t remember which directory it was in)
No joy after clearing the cache and tmp prior to a restart.
I do have a theory now – I think the issue may be with the second RPi3 which is hosting the Razberry z-wave board. The Razberry board ships with its own (crude) automation software BUT (at the time) it was capable of discovering more zwave devices than OH was. I’m connecting to the second RPi3 via the z-way binding from my OH2 RPi3 (e.g.)
My theory is that the crude automation software on the Razberry RPi3 is generating (thru the z-way binding) the erroneous HTTP PUT requests. So the experimental test is to rectify the namespace in the Razberry automation software with my OH2 namespace for the mapped devices.
Make sense ?
The quick and dirty version would be to change one of my OH2 items back to the original name and see if that particular device no longer errors.
All right. Here’s what I did for quick and dirty test. In OH2 items file, created items which matched the “old names” with same channel parameters. e.g.
Notice I commented out the zz_ version of the item name. This construct successfully eliminates the error message for this device channel. If I keep BOTH items, I get an error on the zz_ version.
This seems to be holding true over the other items as well.
This seems to me to be an issue with the z-way binding — doing lookups by NAME instead of by channel address on both the z-way RPi3 side and the OH2 side.
