Can't get rid of duplicate item

Setup, Configuration and Use Items & Sitemaps
1

I have been working with a single Thing, a Wemo mini switch defined in a .things file to have the name “Socket1”.

Thing wemo:socket:Switch1 "Wemo Mini" [udn="Socket-1_0-221732K01016D2"]

Since I had automatic (simple) linking turned on (paperUI) the system generated an item and gave it the name “wemo_socket_Socket1_state”. Everything worked as expected.

Now, I want to change the name of the item to “Socket1_state” so I added a .items file containing

Switch Switch1_state { channel="wemo:socket:Switch1:state" }

Now however 2 switch items appear for the same Thing. They have different names but are otherwise identical and remain synchronized.
I have tried many ways to try and get rid of the duplicate switch item. In particular, when I try and delete the item in paperUI Configuration the error message in my log file is:
Received HTTP DELETE request at ‘items/wemo_socket_Switch1_state’ for the unknown item ‘wemo_socket_Switch1_state’.
When I try and delete the Thing in paperUI Configuration error message is:
Received HTTP DELETE request for update at ‘things/wemo:socket:Switch1’ for an unmanaged thing ‘wemo:socket:Switch1’.

When I try and use the console: Smarthome:items clear" I get the response “2 items removed successfully” and no error is logged, but the items are still there next time I launch.

How can I get rid of this item?
Thanks in advance,
Joe

1 Like
2

I got rid of it-by 1st clearing all the links in the console. But I’m still confused-
I think of items as properties of some Thing. So, what’s the difference between a link and an item? Or, saying it another way, what is the meaning of an item without a link? I picture an item without a link as some kind of free-floating property? A property of what?
Regards,
Joe

3

This is not a good way to think of it.

Items are used to model your home automation. Items represent the current state of your home automation and those aspects of the automation that can be changed (i.e. actuators).

This model can include Items that represent physical devices, data obtained from a web API, triggers on Scripts, or just Items that store some important value (e.g. a Switch indicating someone is at home). As such, Items need not be linked to anything or bound to any thing to be useful. Roughly 20% of all my Items are “free-floating” as you put it. There is even a design pattern for this: Design Pattern: Unbound Item (aka Virtual Item). Furthermore Items can be linked to Channels from multiple Things from multiple bindings.

One can build an entire OH system that is not actually linked to anything physical or uses any Things for experimentation or testing. See the demo config for example.

Everything in OH outside of the bindings works with Items, not Things. The Items are what Rules operate on, persistence saves, and what you build your Sitemap/HABPanel to display and control. The Items are what you should be thinking about as you build up your home automation.

Things represent a device (physical or aspect of a software-based API). Channels represent each piece of data that device provides (e.g. sensor readings) or control points (e.g. relays or other actuators). One connects their model of their home automation to the devices by linking their Items to these Channels.

Given this, it would be closer to think of links as a property on the Item, not the Item as a property on the Thing.

To give an example:

One wants to control their living room lamp. They create an Item Livingroom_Lamp. At this point they can write Rules, set up persistence, experiment, test, whatever they want using Livingroom_Lamp. At some point, perhaps immeidately, they would link their Livingroom_Lamp to whatever Channel of whatever Thing controls the lamp. If for some reason, that changes in the future (e.g. move from zwave to Sonoff), just change the link but as far as your home automation model is concerned it is still the Livingroom_Lamp.

2 Likes
4

Thanks for the detailed and very clear explanation. It’s sinking in.
Regards,
Joe