Creating/editing Items (including Groups) from PaperUI invokes different mechanisms to creating from xxx.items files, and subsequently editing them.
The end product is the same - an openHAB Item - but the processing is different, so don’t be too alarmed about different behaviour while editing.
Be aware the methods, while they happily co-exist, are essentially incompatible - you cannot edit a file-created Item using PaperUI for example.
Hummmm, rebooted and it’s still the same, I can only add items to groups from the paper ui.
I upgraded from 2.4 to 2.5.4 last week…wonder if there are some settings that I need to change / update…
Simple mode is off on paper ui, but I did notice some errors in the logs on startup regarding my influxdb and a few other bits that weren’t there last reboot, (that I noticed)…
I’ll go and read through the release notes, does any of that make any possible sense as to what has been happening?
It seems unlikely to be anything to do with versions, this stuff hasn’t changed since OH1.
There is no special trick about placing file-based definitions in any order, or even in the same file.
People have run foul of weirdness originating around PaperUI / xxx.items file based Items conflicts, and ended up with a stubborn duff Item lodged in the behind-the-scenes JSONDB. Simple Mode has been at work here too.
Satisfy yourself the process works with brand-new Items created alongside your old ones.
Group:Switch groupFred "group"
Switch Fred1 "gog" (groupFred)
Switch Fred2 "magog" (groupFred)
command ON to group, hover in VSC to see membership, etc.
Yup, that worked like a charm…ok, so it’s looking like the items for the spotlights I have created have all gone a bit funky, I might need to remove all the items relating to the spotlights, ensure they are gone from Paper UI too and then redo the items, but give them new names I suppose???
I would do the removals, reboot, and try again with adding the same names that you prefer. It might still mess up, but then you can just press ahead with new names.
If I recall the underlying problem is about “hanging” links e.g. an Item has been deleted but a channel link to it still exists. I think you’re still fighting a legacy of Simple Mode here.
@rlkoshak I think may be able to tell you how to sort it with manual edits to JSONDB,
I haven’t read the whole thread so if I miss some important detail let me know.
Based on @rossko57’s reply it sounds like you had Simple Mode enabled, you’ve now disabled it, and are having problems deleting the automatically created Items.
Sometimes, when you delete an Item using PaperUI without first deleting the Link the Link to the Item remains. Links are stored in a separate place from the Items. If that Link hangs around, PaperUI will see that the Item still exists, but it will exist in a broken way.
To see if you have zombie Links, take the name of an Item (let’s call it Foo) that you think should be gone but is still showing up in PaperUI. Then run the following command:
grep Foo /var/lib/openhab2/jsondb/*.json
If it returns nothing that means Foo does not exist in the JSONDB at all.
If it appears in org.eclipse.smarthome.core.items.Item.json it means that the Item has not been deleted at all and it still exists.
If it only appears in org.eclipse.smarthome.core.thing.link.ItemChannelLink.json that means the Item is a zombie. The Item is gone but the Link remains. Stop openHAB, open that file for editing, search down for the entry that includes "itemName": "Foo". The entry will look something like:
"mg_Test -\u003e mqtt:topic:test:test": {
"class": "org.eclipse.smarthome.core.thing.link.ItemChannelLink",
"value": {
"channelUID": {
"segments": [
"mqtt",
"topic",
"test",
"test"
]
},
"configuration": {
"properties": {
"profile": "system:default"
}
},
"itemName": "mg_Test"
}
}
Delete the whole thing. Be careful not to leave a trailing comma if it happens to be the last entry in the file.
Restart OH and watch for errors in openhab.log.
Hi, thanks for the info…
I didn’t have simple mode on but my system seems to be acting like I have…the only way to add an item to a group is by doing it in the item edit screen on Paper UI, if I add it to a .items file the group has no members and doesn’t work in rules.
I deleted all offending items from both my .items files and also manually from Paper UI and then rebooted.
I found the items back in my inbox, (as expected), but when I added the item the channels linked items were already populated in Paper UI, despite me not adding them yet in a .items file.
I then deleted them all again, rebooted and added the thing from the inbox again, this time giving it a different name. This time the linked items weren’t inked already, great, but did not become linked in Paper UI once I added them to a .items file and, again, if I create a group and try to add these items to it, the group remains without members…
I seem to be stuck in a loop of the system thinking I’m in simple mode when the option is unchecked in Paper UI…
I tried the above on one item and it appears here:
/var/lib/openhab2/jsondb/org.eclipse.smarthome.core.thing.link.ItemChannelLink.json:
I’m going to go into the file and delete the offending entries, is there a special way to do that?
Also, going forward, should this fix the issues regarding linking / groups for all items or do I have an underlying issue that also needs fixing before I add new things???
But you told us you’d performed the little xx.items file test satisfactorily.
Have a look in your /services/runtime.cfg for parameters about package and about autolink
Items do not appear in the Inbox, Things appear in the Inbox. I don’t want to be pedantic but it helps us all when the right terminology is used to avoid confusion. If Things are appearing in the Inbox, it is because the binding is rediscovering them. There are lots of reasons why that may be the case, but essentially if the binding discovers a device and thinks the device does not yet have a Thing to represent it, the binding will put a new Thing into the Inbox.
This is all completely independent of Items.
If you have Simple Mode (aka autolinking) turned ON, there will be no Items entry in PaperUI at all. You will just see Things and for each Channel on a Thing an Item will be created.
You imply the Items that you do have defined are defined in .items files. Do these have a Link defined in the .items file? For example { channel="blah:blah:blah" }. If so than whether or not the Thing exists, the Link is there, defined in the .items file. So if you delete the Thing, the Link remains. When you recreate the Thing (or accept it from the inbox) if it has the same Thing ID, those Items will become relinked to that Thing. This is a good thing.
Similarly, if you Link the Item to a Channel in PaperUI and then delete the Thing (or the Item), that Link may remain, this time in the JSONDB. Again, if you delete the Thing and then recreate it or accept it from the Inbox, those Links still exist so the Items will be linked right back to those Thing’s Channels.
A “zombie” Item is a case where the Thing still exists, the Link still exists, but the Item does not exist. In this case, PaperUI get’s confused and will show that the Item still exists when in fact it has been deleted.
If you have zombie Items, you need to manually delete the entries from the ItemChannelLink file, while openHAB is not running. That will eliminate the zombie Items.
To eliminate a Link for an Item defined in the .items file, simply delete the { channel="blah:blah:blah" } for that Item in the .items file.
Looking back at the earlier posts, the Items you are working with are not named hue_blah_brightness so you are not dealing with Simple Mode. So what is likely happening is you delete the Thing but not the Links that are defined in the .items file, reaccept it with the same Thing ID and therefore the Link defined in the .items file becomes valid again.
It’s a really bad idea to mix .items files and PaperUI in this way. It’s very easy to end up in an inconsistent or inexplicable state.
Yes, sorry, I should have been more specific, groups work for all but these GF_LR_HueLight items that I am having problems with.
This file is all commented except the ephemeris section which has the weekend / weekday set
Sorry, yes the things reappeared in the inbox as expected.
That’s how I know simple mode / autolinking is off; the thing appears in the inbox, I accept it, ie tick it in the inbox, it then appears in my ‘things’ section on paper UI, in here it has unlinked channels as I’d expect.
Yes, they all have a channel.
But I have deleted the items in the .items file as well as the thing in Paper UI. So I suppose in this case this is where the zombie Items come into it…I’m going to go and remove them now, is there a reason why this happens or is it just ‘because’ and I’m unlucky
I know, I was just getting desperate to see what worked and what didn’t.
Hi all,
Update if I may…
Next Step
Dimmer GL_LR_HueSpot1_Brightness "GF LR Spot1 Brightness" (gSpots_LR_All) {channel="hue:0220:00178877b4a1:5:brightness"}
Group:Dimmer gSpots_LR_All "Living Room Spots All"
All other items have a value and all other groups have members in my .items files.
So, I’m thinking there are now 'uber’zombies hiding somewhere in the system 
so I will go and remove this item / things etc and start again…but this time give it a completely new name…hopefully this will work…although if it does it will be a shame as I’ll be breaking my naming convention…
Ok, added the thing in with a different name, Spot_GF_LR_1, and then followed the steps:
Added item in my lights.item file with correct channel, VSCode isn’t showing any value to the item, added a group and added the Spot_GF_LR_1 item to it but VS Code shows the group with no members.
So, exactly the same thing is happening with a different thing naming convention.
As an aside, these are, I think, the first items I have added since upgrading to 2.5.4…not sure if that’s relevant, (ie a config file hasn’t upgraded properly perhaps???)
Any ideas anyone? Please…
May we see screenshots and file contents related to any of that?
Yup, Paper UI showing thing and channels, (note nothing linked despite Brightness channel being in the .items file below.)
lights.items file
Dimmer Spot_GF_LR_1_Brightness "Spot GF LR Brightness" {Channel="hue:0220:00178877b4a1:5:brightness"}
Groups.items file
Group:Dimmer gSpots_LR_All "Living Room Spots All"
Dummy Variable used to trigger rule
Switch vSpotTest "Spot Test"
Rule to trigger item
rule "Spot Test"
when
Item vSpotTest changed
then
if(vSpotTest.state == ON)
{
logInfo(logName,"Spot Test")
Spot_GF_LR_1_Brightness.sendCommand("100")
}
end
LOG when triggering vSpotTest rule
2020-04-28 15:48:24.561 [INFO ] [clipse.smarthome.model.script.lights] - Spot Test
2020-04-28 15:48:24.569 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Spot Test': The name 'Spot_GF_LR_1_Brightness' cannot be resolved to an item or type; line 71, column 13, length 23
Touch the item file that has Spot_GF_LR_1_Brightness e.g. just use text editor and add a space to the end then save.
and then by group
Rule
rule "Spot Test"
when
Item vSpotTest changed
then
if(vSpotTest.state == ON)
{
logInfo(logName,"Spot Test")
gSpots_LR_All.sendCommand("100")
}
end
LOG
2020-04-28 15:52:35.486 [INFO ] [clipse.smarthome.model.script.lights] - Spot Test
No change, same result 
What does openhab.log say about lights.items when you touch it?
Only one line…no errors…
2020-04-28 15:52:32.508 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'lights.rules'