The large part of your tags do seem to follow this schema. But there are a couple of errors e.g. ‘Point’ is not a tag but rather a CLASS of tag, neither is ‘Point_Control’ a tag. Furthermore sometimes you have applied an Equipment tag e.g. ‘SmokeDetector’ or ‘Window’ where perhaps you should apply (also) a point/property tag e.g. ‘Alarm’ / ‘Smoke’ resp. ‘Control’ / ‘OpenLevel’
But finally – to pick up @Mherwege 's intimation – there are indeed a couple of tags that shifted from being Point tags to being Property tags; however @Mherwege it is not clear to me that this is the cause of the issue; surely the tags are treated as strings at this point? or are they being cast back to Java classes before the badges are applied?
Just one thought: I see that in some cases you applied just a Property tag e.g. ‘VOC,’ or ‘AirQuality’ whereas in OH 5 we have added a rule that it is not allowed to have just a Property (object) tag without a Point (verb) tag. So in your cases they should probably become ‘Measurement’ / ‘VOC’, ‘Measurement’ / ‘AirQuality’ .. (or ‘Alarm’ / ‘VOC’ etc.) @Mherwege do we have a mechanism in OH core now that refuses such ‘naked’ Property tags? And if so, perhaps we should implement a log output on that? (Indeed maybe we did that already? => @fibu-freak can you please advise if you see such warnings in your logs?
As I’m no programmer it will take a while to understand the XML-Scheme, but I will try to learn
In my thinking “Point” was a placeholder for not defined properties, so I will have a look an that.
I do not quite understand what is meant.
“SmokeDetector” and “Window” are tags to declare an Equipment(with item-type Group) and that’s what a window-sensor or a smoke-detector is ??? or not ??? (also AirqualitySensor in OH5)
VOC or Airquality are new in OH5 and I implemented those tags in my OH4.3.5 SetUp so not to have any problems when upgrading .
In the problems I described here, Ididn’t find warnings in the log. I only observed that the badges are not anymore present in OH5.
I will give the properties “VOC and Co² and Airquality” a point-tag like “Measurement” and see what happens.
I believe we need a list of all removed or renamed semantic tags and include that in the release notes
I don’t think we need the added tags as it will not break anything existing.
We also need to mention those that changed “type”.
Can you post your upgraderecord json (located in userdata/jsondb/)? Note I don’t know whether there may be sensitive information there, so please take a look yourself before posting.
You don’t need programming skills. You should just check that you use only tags which appear in the Point, Property, or Equipment tags lists in the schema file.
They are Strings in core, but get interpreted in the UI. If the UI widgets relied on specific semantic tags to render certain elements, changes in these tags may have broken the rendering.
This could be the result of moving OpenState from (wrongly) being a Point to (correctly) being a Property. Indeed it is a perfect example of why we had to move it (since Point.Control plus Point.OpenState is a syntactically forbidden combo).
@Mherwege can you please why on earth one would/should allow Point.Point or Property.Point as a placeholder for anything? Either there is a valid tag applied or there isn’t..
I believe Point, Equipment and Location were considered valid tags before, to classify them as one of these without being more specific. I am in doubt about the usefulness, but I believe these then did show up int the automatic widgets on the Locations/Equipment/Points tabs. Property does not have relevance in this context.
This change might be the problem for the UI, IIRC the code correctly, it depends on the type of the semantic tag as well.
This needs to be checked, can you please create an UI issue?
