Yep - that’s what I posted earlier 
-:
2 Likes
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.
1 Like
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.
1 Like
Absolutely a valid use case, at it’s simplest Item commands are destined for one channel and Item state taken from a different channel.
3 Likes
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:
- things related to a uninstalled binding;
- links where the channel or item is gone;
- metadata without the item;
- member items of missing groups;
- …
and offer to delete/fix what’s wrong (when possible).
6 Likes
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.
2 Likes
hashtag Yannick for president of earth!!! 
While that may be useful, it again is a workaround. If we want OH to be usable, simple and stable, IMHO we shouldn’t really require these sort of things - we should solve the issues “properly” in the core as far as possible.
4 Likes
Sure, but there’s lots to do.
Rules may trigger on channel events. Should these be deleted too, when a channel is removed? Similarly, rules may examine Things in various ways.
Example, if a binding update changes the nature of channels for a given Thing type. Pre-existing Things no longer “fit properly”. The user must delete the old broken Thing and make new. At the moment the pain of doing this manually is reduced because we can create a new Thing with “old” UID, and all the old dangling channels/Items/rule events etc.hook up again.
Auto-destruction of orphaned links destroys that ability too; the “benefit” causes user pain. That’s okay, there should be a way to deal with Thing updates non-destructively, but it needs making too. That’s not quite as simple as replacement, because after all something changed - channel added, removed, type change - there are decisions to make.
3 Likes
But piling one workaround over the next is lots of work to do, too.
But this is something that is solvable.
Imho a good compromise could be to automatically delete stuff that has been linked/created automatically.
E.g. item that has been automatically linked, so delete the channel when the thing will be deleted. An item that has been defined manually (e.g. items file) will keep the links because there are explicitly defined.
I am not saying this is a good concept or the way to go, just that it should possible to find a good concept and provide consistent behavior.
Absolutely - by implementing workarounds, people are spending time to bodge things together rather than tacking the real issue.
Personally I wouldn’t delete the rules. Rules are a different issue in my view - they are manually configured and people can go in and rewrite them. They wrote them initially, so hopefully they understand that.
The case with links, and metadata etc is different - it’s basically internal working of OH - people shouldn’t need to know that they have to go and mess with these sorts of things manually. They configured the metadata, they set a link, they then deleted the item/thing so they should expect it’s gone - along with any internal information that the system may have stored. These are all effectively part of the same entity - even if under the hood OH treats them separately.
1 Like
Hopefully. Many here want somebody else to write the rule so they just copy and have no idea how it works.
Seems perfectly reasonable. Decisions to make about auto-created stuff that has been manually edited.
The upshot of that is that sometimes deletion will leave dangly bits and sometimes it won’t. Maybe there are linked rules you forgot about, maybe there aren’t.
Seems like a sanity check or audit, with or without “do you want to fix this?” actions,would be really helpful, whether or not any automated tidy-up is developed for deletions.
2 Likes