Current behavior is even worse:
When deleting an item that is currently linked, openhab will automatically create a new item that can not be deleted any more and automatically link it accordingly.
How about metadata of an item?
Because currently metadata does not get deleted when you delete an item and without an item you can’t delete the metadata any more.
Checking if an item has metadata before deletion does also not work so inherently you end up with metadata polluting your installation.
Which seems to be a workaround, not a solution 
As I said above - the word “binding” was misused here. Binding is often used (incorrectly) to mean a link to a thing, or something along those lines. Clearly removing the binding itself should not remove all items / things etc. This is what I already said though -:
Fine - but that’s a different issue. The system supports a UI to do all this stuff, and that should work properly. We shouldn’t just say that people need to use text files as the UI doesn’t work.
For me, as I think I said in the original issue, if you delete an item, or a thing, then it’s gone, and all configuration associated with it should probably be removed or it is orphaned.
That would be the behavior anyone would intuitively expect and one thing I really hoped would be tackled with OH3.
E.g.:
Deleting a thing should delete all the channels pointing to it
Deleting an item should delete the channel pointing to it and the metadata associated with it.
Edit:
Also Metadata should be part of an item.
There should be a warning message that needs to be acknowledged though.
I think junk metadata is less of a problem because it is ignored. It doesn’t generate errors like the OP points out. Ideally I think the metadata should be deleted. Over all, the REST APIs around metadata need a lot of work IMO to handle stuff like this and management of metadata through the UI. But since it doesn’t really cause any problems beyond a tiny amount of extra entries in the metadata JSONDB file I would treat that as less of a problem.
While looking for something entirely unrelated in the code last night, I discovered that Orphaned Link Management exists in the CLI.
Specifically openhab:links orphan list and openhab:links orphan purge
openhab> help
openhab> openhab:links
Usage: openhab:links list - lists all links
Usage: openhab:links addChannelLink <itemName> <channelUID> - links an item with a channel
Usage: openhab:links removeChannelLink <itemName> <thingUID> - unlinks an item with a channel
Usage: openhab:links clear - removes all managed links
Usage: openhab:links orphan - <list|purge> lists/purges all links with one missing element
openhab> openhab:links orphan --help
Specify action 'list' or 'purge' to be executed: orphan <list|purge>
openhab> openhab:links orphan list
Thing channel missing: JVCRS3000Projector_Power -> jvcProjector:rs3000:63d811e9db:lamp
openhab> openhab:links orphan purge
Thing channel missing: JVCRS3000Projector_Power -> jvcProjector:rs3000:63d811e9db:lamp
Link JVCRS3000Projector_Power -> jvcProjector:rs3000:63d811e9db:lampsuccessfully removed.
openhab> openhab:links orphan list
openhab>
So, my 3rd bullet is of lower priority than the other two given it’s at least been addressed already in the CLI… and I’m no longer ignorant of that fact.
Yep - that’s what I posted earlier -:
I think junk metadata is less of a problem because it is ignored. It doesn’t generate errors like the orphaned links. Orphaned links generate other problems as well.
Ideally I think the metadata should be deleted. Over all, the REST APIs around metadata need a lot of work IMO to handle stuff like this and management of metadata through the UI. But since it doesn’t really cause any problems beyond a tiny amount of extra entries in the metadata JSONDB file I would treat cleaning metadata as a lower priority.
As a general rule you should never ever violate referential integrity. That means that when you delete an object, all descendants (child objects) go with it. However, by saying that I’m not really saying what it sounds like I’m saying. Because, if the children are really that important, then you probably should not be deleting the parent either, you should be transforming the parent to a different state and/or moving it to a different store so that you have a clear context while it continues to exist; i.e. only Active Links should subscribe to messages, only Items with Active Links should be available for placement in the UI. only Inactive Links should be available to utilities that do cleanup and merging, and so forth. Not following that discipline often leads to endless debate over how to handle all the cases that arise as a result.
Another issue can be the data model. When object relationships aren’t modeled correctly it can feel very unnatural. For example, the Item’s and Channels - technically ThingChannels - are set up with a bridge table between them, and bridge tables imply a many to many relationship - although the bridge schema is setup with the ThingChannel being the parent of an Item. While I think it makes sense that multiple Items can subscribe to a single channel I don’t know that it makes sense that one Item can subscribe to multiple ThingChannels, thus a bridge table might not be the correct way to model it. Mind you, I do not know what the design says about relationships and cardinality, so I’m not judging the implementation in any way, because I don’t have sufficient information to do so. But I am saying that when something doesn’t feel right the implementation should be judged to see if it’s the best fit.
This is absolutely allowed and an important use case. One can have a case where there is logically one thing in the real world (e.g. a lamp with multiple bulbs) and therefore is modeled using one Item. However, there may actually be multiple Things to represent that (e.g. each bulb is a Hue bulb). By linking all the bulb’s Channels to a single Item you can command all of the bulbs as if they were one device.
It gets more useful when you bring in Profiles, in particular the follow profile. I just now replaced a rather complicated rule in this way. In my case I’m using the OpenWeatherMap binding. There is a Channel on this binding that stores the current conditions icon image in an Image file as Base64. I want to extract that Base64 and turn it back into a binary which is done through some command line programs.
So I created an Exec binding Thing with a command of:
bash -c 'echo %2$s | /bin/dd bs=22 skip=1 | /usr/bin/base64 -d > /openhab/conf/icons/classic/weather.png'
The %2$s gets replaced with the value of the Input Channel on the Exec Thing.
Now I link that Input Channel to the same Item linked to the Current Conditions Icon Channel on the OWM Thing with the follow profile. Consequently when ever the icon changes the new value will be sent to both the Image Item and the Exec Thing’s Input Channel which will kick off my command line to save the new icon to a png file. Now I can use the current conditions as an icon on my Sitemap and elsewhere, no rules required.
(NOTE: I’m still testing the above and I’m using OH 3)
This seems a bit strange to me to be honest. Aren’t you better off to have a single item per channel, and then use a group item to combine them? (and I’m sure you’ll have a good reason that this is the best way to group items/channels/functionality Rich 
).
This is one of the problems with openHAB (or maybe someone will say it’s an advantage) - there are a lot of ways to do the same thing, but because of that the system ends up being overly complex, and we see the sort of problems we have here.
I don’t actually use this myself except in the sort of case I mentioned above with the follow profiles. I tend to use Groups and separate Items when this occurs. But I know this approach is relatively commonly in use by other users. It seems to be most common when using MQTT and HTTP binding based on what I’ve seen posted. And it is usually a mix of bindings that get linked to the same Item, like an MQTT Channel and Hue Channel on the same Item.
Absolutely a valid use case, at it’s simplest Item commands are destined for one channel and Item state taken from a different channel.
In Javascript the functions atob() and btoa() will do base64 encoding and decoding, and as long as you use the correct Mime tag the browser should do the work for you.
<img src="data:image/png;base64, iVBORw0KGgoAAAANSUhEUgAAAAUA
AAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO
9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot" />
See it in action in this fiddle
The simplest use case represents no contention because you’re really talking about two unidirectional channels. It gets trickier when two channels are sending potentially conflicting status to an Item.
Not using JavaScript for this yet. And I need a png on the file system, not to convert it in a browser.
I’ll have to say I was tempted at some point to offer a UI solution in the form of “developer tools” for all these cases where the backend doesn’t do a “cascade delete” when objects still have references to stuff that don’t exist anymore. I’m very flexible to add pages in this menu. A “cleanup” screen could do some sanity checks and identify such things as:
and offer to delete/fix what’s wrong (when possible).
What about a daily cron job to clean up orphans?
I like the sanity check. I do not like daily automation - why would this stuff change daily, ordinarily? I can see that hiding the evidence of some bugs, and making them worse.
hashtag Yannick for president of earth!!! 