EDIT: in which case these tags would be like class:Equipment, name:Equipment, parent:null, label:Undefined Equipment, synonyms:Undefined .. (to use Equipment as an example)
My only goal is to avoid everyone like @uk59821 above from needing to manually review thousands of Items because they choose to use Point, Equipment, and Location to get their Items into the semantic model back when that was the only option to do so because one couldn’t create a custom tag.
If not having a parent, label, and synonyms lets these Items still appear in the semantic model without error I’m happy.
Eventually these users should move off of these tags, and we should encourage that in every way we can. But forcing it now as a breaking change is a pretty big deal for these users. Of all the breaking changes in OH 5 I know of, this one probably has as much impact on end users as the move to 64-bit only Java. If I were in the situation where I would have to manually review 1000 Items I probably wouldn’t move to OH 5 at all, at least not for many months or years.
Throwing a warning into the logs would be a good idea but not required. I’m not advocating for changing the docs to say these tags are available for use. I’m not advocating for changing MainUI so that these tags can be chosen (currently they cannot be chosen). I’m not advocating for never making this change.
I just don’t want to break the systems of people who were told to use these tags back in OH 3. It feels like a bait and switch. It makes the users mad.
Is it possible make a method (or is it a function 
) to the effect of addTags(…tagNames) or replaceTags(…tagNames, …tagNames)? Maybe that’s less work, and would make the change relatively easy for users?
You can easily add and remove tags from Items now. But change them to what? That’s where the work really is because you have to put in some thought. The Point tags should be specific and representative of what the Item means. For example, a smoke alarm Item would have “alarm” as the point tag but a light switch might have “control” as the point tag. It’s not as simple as just replacing all instances of Point with some other tag because they all have different meanings.
But in JS the Item has “tags”, “addTags()”, and “removeTags()” which can be used. A 'replaceTag()" function would look something like:
function replaceTag(itemName, oldTag, newTag) {
const i = items[itemName];
i.removeTag(oldTag);
i.addTag(newTag);
}
I’ve not tested the above code, but the idea should be clear. If the old tag is on the Item, remove it and then add the new tag. Note, if the old tag wasn’t there, the new tag will just be added.
But the work is in what to choose for that newTag which should be a different choice for different Items.
A similar approach should work for any rules language, including Rules DSL I don’t think Blockly has the right blocks though but if requested I can create a Block library with the above code easily enough.
I doubt you have to change anything. My statement was merely a reaction on your statement the tag Point was illegal. I pointed out it wasn’t. But I don’t think you changed anything in the Java code deriving the semantic relationships from the tags (I may have missed something). So it should still end up in the REST API as before.
See this PR just in case
Is there a way to put a line break in so the list is more readable?
I tried /n but that didn’t work.
Thanks
EDIT:
I did it this way. I guess it is the same results and it has a running count as well.
var i_list = (items.getItemsByTag('Point'));
for (var i_index in i_list) {
i = i_list[i_index];
console.info(i_index + " " + i.tags + "--" + i.name);
}
Output:
2025-06-24 12:06:46.363 [INFO ] [nhab.automation.script.ui.scratchpad] - 0 Point--Zoneminder_event_monitor_10
2025-06-24 12:06:46.364 [INFO ] [nhab.automation.script.ui.scratchpad] - 1 Timestamp,Point--LocalMoon_Set_StartTime
2025-06-24 12:06:46.364 [INFO ] [nhab.automation.script.ui.scratchpad] - 2 Point--Studio_Aoshima_speaker_Stop
2025-06-24 12:06:46.365 [INFO ] [nhab.automation.script.ui.scratchpad] - 3 Point--Portischbridge_Portischreceiveddata
2025-06-24 12:06:46.365 [INFO ] [nhab.automation.script.ui.scratchpad] - 4 Point--Zigbee_access_door_shed_lastupdate
202
It has been allowed in the past, and I don’t see a reason to stop allowing it. There is an automatic inferencing that read-only items (based on state description?) will be assigned to Point.Measurement, otherwise, Point.Control. See:
As has been mentioned, and sorry for repeating it, but Point, Property, Location, Equipment are all valid semantic tags and should remain as such.
If you treat them as not valid “semantic tags” (for whatever reason), then they will be classified as “non semantic tags” and therefore be allowed as “plain” tags, which will cause even more problems.
Can someone please fill me in. I’m trying to understand what the problem is that leads to this PR.
AFAICT, Point, Equipment and Location are still all valid tags that can be selected in the UI as of the latest snapshot.
The only thing is that currently they are not valid tags to be suggested in the thing-type xml and I think that’s also the correct behaviour. But that doesn’t affect what tags Items can actually be assigned.
I see no current issue regarding any of this.
In regards to this post by @uk59821 that sounded like he simply needed to tidy up his tags but otherwise things are still functioning as they were before?
I’m a bit lost now. Can someone tell me what I need to set in M3 to see badges for “CO2 or now AirQuality” and Blinds? Whatever I try I can’t see these badges. Is this really wrong?
Why it is working for “Measurement/Temperature” but not for “Measurement/AirQuality” or like before “Measurement/CO2”?
@jimtng There are two different things at play here:
@andrewfg provided lists of added, removed, moved (between Point and Property) tags and tags that changed the position in the hierarchy. This should help identifying potential issues.
@hmerk Does the semanticHomeMenu also need to be reviewed and adjusted for these semantic tag changes?
Just to add my two cents from end user perspective: Maybe consider to mark Point, Equipment and Location as Tags as deprecated, so users are aware that they should avoid them in the long run.
BUT: as long as it’s time consuming to create custom tags, there is a need for “generic” types, even if that is against the whole concept of semantic tags.
Sometimes I just want to create some Items to check wether it’s worth it and remodel later, but it’s nice to already have them within the semantic model.
Hmm, I need to check that, but don‘t think so, as we just check for existing tags, not were it belongs to in the hierarchie. But I will check…
Very good idea.
To summarise: Items that use such “naked” tags will continue to work as before. The recent changes did not break the functionality of such tags. (So remedial changes in OH core are not needed). HOWEVER we do advise users to use proper tags rather than naked tags.
Just for the avoidance of doubt no tags were removed. Not even the “naked” tags..
Nothing. There is a fix that will appear in the next i.e. final milestone.
As @michaeljoos I’m a bit lost and will wait for MileStone. I hope my Window-Sensors will work(shown in Location-Card) again too.
But I still do not understand what’s wrong in my currently Setup of the semantic model or what is deprecated. Is it why I use textual SetUp and forget something?
One more question regarding semantic tags: Does it make sense that the semantic class is always preset to “Point” when creating a new item? (I’ve tested this with various things and bindings and always preset the semantic class to “Point.”)
Or will the default be changed with OH 5.0?
For example an Z-Wave CO-Sensor:
In OH 5.0, bindings can now propose default tags for channels. These will be presented as defaults in the UI instead of Point and Property.
I could only partially follow… I do use “location” and “equipment” to built my model, like:
My Home (location)
|- inside (location)
|- ground floor (location)
|- kitchen (location)
|- ceiling lights (equipment)
|- kitchenLight (item)
|- HVAC (equipment)
|- coffee maker (equipment)
|- ground lights (equipment)
|- ...
|- living room
|- ...
|- first floor
|- bath room
|- HVAC
...
And under each equipment there’s the respective items for that equipment.
Do I have to change something following the discussion here? I do use sometimes semantic information in my rules or pages. As e.g. for “turn on/off ‘lights’” or a page with all sensors of a specific type.
Do I have to move to non-semantic tags overall as semantic property will be discontinued sometime in the future? And how do I built a “Map” of my house without Location and Equipment? I’m afraid, I’m confused now… but perhaps I just don’t understand what’s going on? 