I hadnât tried that before but just did it now after reading your post. However this also does not resolve the issue: the item is still shown in the semantic model under window_livingleft (yes this group still has an equipment tag) even when the item is no longer part of that group.
What does it show on the Item page (not the Item edit page). Does it show the Item in the semantic model? Does it show anything under metadata?
If you look at the model, where does it sit? Is it inside the semantic model? Switch on non-semantic Items. Can you drag and drop it out of the semantic model?
I am curious why it does what it does. If you create an issue, we probably may have to get hold of the json db to be able to reproduce it. So make a copy and keep it before you experiment too much.
@DrRSatzteil One more thing to check: Can you have a look in Developer Tools â Semantic Tags? Are your old tags still there? Where are they in the semantic tag hierarchy?
No they are not there. I get warning messages during startup that they cannot be loaded:
2026-02-15 01:41:16.452 [WARN ] [ore.common.registry.AbstractRegistry] - Cannot add "SemanticTagImpl" with key "Equipment_CoffeeMaker": Failed to create semantic tag 'Equipment_CoffeeMaker': tag 'Equipment_WhiteGood_CoffeeMaker' already exists.
2026-02-15 01:41:16.455 [WARN ] [ore.common.registry.AbstractRegistry] - Cannot add "SemanticTagImpl" with key "Equipment_Thermostat": Failed to create semantic tag 'Equipment_Thermostat': tag 'Equipment_HVAC_Thermostat' already exists.
2026-02-15 01:41:16.455 [WARN ] [ore.common.registry.AbstractRegistry] - Cannot add "SemanticTagImpl" with key "Equipment_UPS": Failed to create semantic tag 'Equipment_UPS': tag 'Equipment_PowerSupply_UPS' already exists.
2026-02-15 01:41:16.459 [WARN ] [ore.common.registry.AbstractRegistry] - Cannot add "SemanticTagImpl" with key "Point_Status_OpenState_DoorOpenState": Failed to create semantic tag 'Point_Status_OpenState_DoorOpenState': no existing parent tag with id Point_Status_OpenState
2026-02-15 01:41:16.460 [WARN ] [ore.common.registry.AbstractRegistry] - Cannot add "SemanticTagImpl" with key "Point_Status_OpenState_WindowOpenState": Failed to create semantic tag 'Point_Status_OpenState_WindowOpenState': no existing parent tag with id Point_Status_OpenState
After updating to 5.1.2, the entire user marketplace has disappeared for me. Only the bindings included in the core distribution are available. Marketplace access is enabled everywhere.
The forum software was updated a couple of days ago and apparently the API OH uses to pull the marketplace postings changed. Itâs broken for everyone.
In the short term, you can download the jar or kar file from the marketplace posting and drop that into your addons folder.
If you need to remove an add-on, look in $OH_USERDATA/jsondb/org.openhab.marketpalce.json to find the UID of the add-on you want to remove (it will be something like marketpalce:XXXXXXX). Then use the API Explorer to remove the add-on.
This reminds me of the links that were broken for many moons⊠Is there a backup of all the stuff thatâs pulled from the forum somewhere? Because it would be very unfortunate that that all disappears if something happens to the forumâŠ
Maybe it would be better to pull it from the forum every night, and have OH call that remote backup location?
The problem now is that the JSON that the forum returns has changed:
However, this means that all existing/older versions will be forever broken. Iâve long been saying that there should be a âproxyâ between the forum and the OH clients. The proxy would have to run on some server, basically a script that gathers some data and then hands them out when OH clients ask.
This would make it possible to control the exact syntax and make sure that it doesnât change. It could also be versioned, so that itâs possible to add more functionality to the format without breaking existing clients. It would also solve the significant load on the forum from all the installations querying the forum, and a lot of information could be dropped. The forum always returns the whole thread, while the OH client is only interested in the first post. The âproxyâ could throw away all the other posts before storing, meaning that the data exchange between the OH clients and âthe marketplaceâ would be significantly smaller.
It would also allow relaxing the cache time in OH (I think itâs 15 minutes now) so that the marketplace could be ârefreshedâ more often. If the proxy did one request every.. 5 minutes, it would still be an âequivalent loadâ on the forum of only 3 OH clients running today.
I also thing it would be a good idea if the âcommunity marketplace URLâ wasnât hardcoded, but existe in some settings file. That way, it would be possible to ârerouteâ older clients if things have to change in the future (be informing users that they need to change this setting). Itâs best if this is never needed, but nevertheless, when the URL is hardcoded, there is nothing that can be done to make it work again, should a change be necessary.
Probably not, I would think that it would âsave resourcesâ by relieving the forum. But, somebody with access to that would need to make the âproxyâ/cache. I could update the âclient codeâ that fetches it, Iâm relatively familiar with that code, but that would have to come after the âproxyâ/cache.
I think anyone could implement a cache. Of course someone needs to host it (the foundation). Discourse has an OpenAPI spec for its API, and for openHAB, weâd define our own format. If I were to implement this my language would very likely be TypeScript, super quick to build and coding agents are really good at it.
Yes, thatâs correct I guess - but since I donât know anything about the infrastructure thatâs there, itâs hard to judge how to best implement it. Also, ideally, it should probably either be a part of the âwebpageâ repo or have its own repo. Iâm just not good with web infrastructure, but really ideal would be if it could be hosted, but also be run locally for testing.
It seems like JavaScript/TypeScript or Python are the most obvious choices. Itâs also a question if this is small enough to just cache in memory, or if it needs to be backed by storage. I would guess that it would be fine to do it in memory.
If anybody wants to explore this further, please ping me. I donât have anything more to add at the moment, as I have no idea how something like this should be organized (neither technically nor organizationally).
Hi All i created an issue but forgot to mention the fact here apologies
I am on 5.1.2 and on one or two of my items created via dsl definitions i get the Item window open but no details are displayed just a blank screen and if followed through the network console a jeyyy error. I cannot find a pattern as to which items currently appears it could be items created under 5.1.1 or 5.1.2
First, to be clear, I am not going to work on this. But I do think that some hosted caching would be useful to shield installations from changes like this.
I just want to throw one more thing into the equation. We already support 3rd-party JSON add-on services, and have done that for a long time. A caching platform could provide a minimal API exposing the marketplace addons as a 3rd-party JSON add-on service. That could potentially make it instantly compatible with many older versions without having to backport anything.
Ultimately, why not look into extending that and making sure the API for the 3rd-party add-services covers all we now get from the marketplace. It could potentially make our core code less complex.
I bring it up as an immediate reaction here, but I think it would be worth creating an issue for it.
I get the idea, but the JSON add-on service is quite limited in what information it can communicate, and it has âspecial rulesâ of its own (donât remember the details, but I think thereâs something with lacking âpublishedâ status and using something else âinsteadâ).
Making a âstandardâ that could apply to the community marketplace as well as external marketplaces might be a good idea, but I donât think that standard can be the existing JSON add-on syntax. Iâm pretty sure that you canât make the existing community marketplace available that way because of lack of functionality. As far as I remember, the JSON add-on store only handle KARs (and potentially JARs), I donât think it can handle all the other things like widgets, transformations, rule templates etc at all.
I could do many of these things, since Iâve already spent considerable time with âthis materialâ and donât have to start from scratch, but it all is halted until I get some âhelpâ getting a cache solution into existence, because without it, all we have to work with is what Discourse itself offers - which isnât exactly flexible.
