None.
We did not (yet) touch locations. (Even though they are ripe to be cut..)
That was already done.
1 Like
As in Point.UNDEF and Property.UNDEF?? The only benefit that I can imagine for UNDEF would be if (say) thete is a Property and Point is missing. But I canât imagine any difference between that and Point == null. So I would strongly argue agsinst reintroducing such an over complicated solution to a non existent problem..
I am justing bringing up what used to be possible and accepted. Location, Equipment, Point and Property where valid tags by themselves (without being listed explicitely in the semantic tags list) and treated as such in the UI. If it is meaningful or not, I am with you it may not be. But I want to avoid breaking things as much as possible. It is not about reintroducing something, it is about avoiding breaking changes. And I can imagine someone wanting to classify something as a Point without being explicit about the meaning for some obscure reason.
According to the original forum posts on the semantic model, if a Property class tag exists without a Point class tag, the Point class tag would implicitely be considered to be Status or Control (HABot Walkthrough (2/n): Semantic Tagging & Item Resolving).
For Equipment, it is in the documentation this is allowed as a tag (Semantic Model | openHAB):
Select the Thing you want to create the Equipment from, and alter the details of the Equipment item that will be created. If you donât find an appropriate Semantic Class, choose Equipment .
1 Like
I Have now tried 5.0 M3 Docker image and Iâm still facing the same problem, any ideas how I can resolve this?
@andrewfg It looks like we also need the list of tags that got move in the hierarchy, e.g. CO2 from Property->CO2 to Property->AirQuality->CO2. This should have limited direct user impact, but it does have impact in the UI code as core provides these tags with their hierarcy in the REST API. If some user scripts rely on it, it could also be impacted.
2 Likes
Is there any reason that should suddenly not be allowed?
- It has always been allowed to do that since OH 2,.5.
- Before there was support for custom tags, it was the only way to include an Item in the semantic model that didnât have an appropriate tag. There were many years between the introduction of tags and support for custom tags so there are many users who are using these tags.
- Itâs kind of a needless breaking change to no longer allow that now. It doesnât hurt to continue to allow it, but it will cause a lot of rework on a lot of end users to not allow it.
No tag at all means itâs not in the semantic model. Thatâs the difference.
The problem is we have many years worth of support for these tags. Removing them as options will be a breaking change much bigger than the other breaking changes already made to the tags.
2 Likes
@AndrewFG
Since OpenHAB 3.x, Iâve gradually imported my file-based items into the main UI via import.
And I simply tagged many of them only as points. In retrospect, that was certainly a mistake.
Is there a way to generate a list during the migration that identifies and saves the âlikelyâ faulty tagged items? It would make cleanup much easier if I didnât have to manually sort through approximately 2,300 items.
Automatic correction would be nice, but I fear the many variations are too complex. 
The following one-liner of JS code will give you a list:
console.info(items.getItemsByTag('Point').map(i => i.name).join(', '));
In the Developer Sidbar you can simply search for âPointâ and pin the Items that come up. But thatâs going to show a lot of false positives. But it will also give you a nice list you can work off one by one.
You can use the API Explorer and the GET /items endpoint to return those Items with âPointâ as a tag.
If that were possible there wouldnât be a need for the Point tags in the first place.
Thanks for the tip.
There are only 1055 items. Weâll see how and if I can handle that.
I also see removeTags(âŠtagNames). Isnât that something? Or am I misinterpreting names of the tags to remove? (It wouldnât replace the tags, of courseâŠ)
Well it would have been a nice thing if you had mentioned that while we were writing the tagging guidelines and the documentation, and before I started writing code. And AFAICT even if this has been in use since Jurassic times it seems not to ever have been so documented. Or??
Anyway perhaps you can give me a full list of things that need to be changed now in both code and in documentation?
It never occurred to me that you would just assume that certain tags were never used and eliminating them wouldnât be a breaking change. And I said before you ever got started that I had little time to devote to this so itâs not like I could review every line of code and catch every nuance of what was being done.
You can blame be all you want, but I recall no discussion or mention that Point, Equipment, and Location would be removed as options. If I had, I would have mentioned it.
@Mherwege posted links where itâs documented. Right now the user facing parts of the semantic model is only covered in Getting Started. Thereâs an open PR that was never finished to add more docs covering how to create custom tags.
If Equipment and Point are allowed, there should be no changes to the documentation. For code 
, I donât know the code. Though there are unfinished PRs that include more documentation for the semantic model that might need to be adjusted before they get merged (assuming they ever get finished).
If this breaking change remains, then Getting Started needs to be updated and a lot more needs to be added to the release notes in distro to explain these are no longer allowed and what to do about it. @uk59821 is not the only user who is going to have a whole lot of work ahead of them.
Existing Equipment whose Parent Changed (Old=>New)
Boiler:(none)=>HVAC
Blinds:(none)=>WindowCovering
Speaker:(none)=>AudioVisual
Inverter:(none)=>PowerSupply
Television:Screen=>Display
LightStripe:Lightbulb=>LightSource
LawnMower:(none)=>Horticulture
SmokeDetector:Sensor=>FireDetector
Projector:(none)=>Display
Battery:(none)=>PowerSupply
Lightbulb:(none)=>LightSource
Receiver:(none)=>AudioVisual
Car:(none)=>Vehicle
RadiatorControl:(none)=>HVAC
Screen:(none)=>AudioVisual
WallSwitch:(none)=>ControlDevice
MotionDetector:Sensor=>OccupancySensor
Fan:(none)=>HVAC
Existing Properties whose Parent Changed (Old=>New)
Rain:(none)=>Precipitation
CO2:(none)=>AirQuality
CO:(none)=>AirQuality
That was the whole reason why I insisted on taking so much time to get the guidelines and documentation right. We should never just assume. => We should only implement things that are written down. Personally I insist on that.
Anyway @rlkoshak and @Mherwege please tell me what you want me to do. I am NOT going to assume or double guess anything more. I need hard instructions from you both.
It will be less work overall for everyone to allow Point and Equipment and Location as semantic tags.
1 Like
Everyone except me who has to rework everything apparently
Then donât do it.
But is it so much work to just add Point_Point, Equipment_Equipment, and Location_Location as tags? Thatâs hardly âreworking everythingâ.
1 Like