Create static constants for the default semantic tags

[jimtng]

This enables the default semantic tags to be referred to as constants by bindings to enable compile time check.

[jimtng]

@andrewfg you might be able to use this

[jimtng]

If we can be sure that the "simple" tag names must be unique, we can simplify the constants to just the last part of it, i.e.

CAMERA instead of EQUIPMENT_CAMERA.

[andrewfg]

Umm. Actually I strongly prefer the constants WITH prefixes. When developing a binding, if you want to apply a tag on a thing then the tag must be an EQUIPMENT_xx tag. Or if you want to apply tags to a channel they must be POINT_xx and/or PROPERTY_xx tags.

[andrewfg]

@jimtng here is an example piece of code from the Hue thing handler whereby the thing's semantic equipment tag gets set dynamically. Ideally I would pull in your EQUIPMENT_xx tags from this PR rather than using hand coded strings.

    /**
     * Update the thing's semantic equipment tag. The main determinant for the equipment type is the supported channels.
     * For lights use the product archetype to split between light bulbs and strip lights. Rooms and Zones are
     * considered to be (groups of) light bulbs.
     */
    // TODO use the semantic tag constants from OH core
    private void updateSemanticEquipmentTag() {
        String semanticEquipmentTag = null;

        // sensor equipment
        if (supportedChannelIdSet.contains(CHANNEL_2_LIGHT_LEVEL) //
                || supportedChannelIdSet.contains(CHANNEL_2_MOTION)
                || supportedChannelIdSet.contains(CHANNEL_2_TEMPERATURE)) {
            semanticEquipmentTag = "Sensor";
        } else

        // security equipment
        if (supportedChannelIdSet.contains(CHANNEL_2_SECURITY_CONTACT)) {
            semanticEquipmentTag = "Security";
        } else

        // button equipment
        if (supportedChannelIdSet.contains(CHANNEL_2_BUTTON_LAST_EVENT)) {
            semanticEquipmentTag = "Button";
        } else

        // rotary dial equipment
        if (supportedChannelIdSet.contains(CHANNEL_2_ROTARY_STEPS)) {
            semanticEquipmentTag = "RotaryDial";
        } else

        // rooms and zones are a super-set of light bulb equipment
        if (thisResource.getType() != ResourceType.DEVICE) {
            semanticEquipmentTag = "LightBulb";
        } else

        // everything else is individual light equipment
        if (thisResource.getProductData() instanceof ProductData productData) {
            if (STRIPLIGHT_ARCHETYPES.contains(productData.getProductArchetype())) {
                semanticEquipmentTag = "LightStrip";
            } else {
                semanticEquipmentTag = "LightBulb";
            }
        }

        logger.debug("{} -> updateSemanticEquipmentTag({})", resourceId, semanticEquipmentTag);
        updateThing(editThing().withSemanticEquipmentTag(semanticEquipmentTag).build());
    }

[jimtng]

Actually I strongly prefer the constants WITH prefixes. When developing a binding, if you want to apply a tag on a thing then the tag must be an EQUIPMENT_xx tag. Or if you want to apply tags to a channel they must be POINT_xx and/or PROPERTY_xx tags.

I believe that I understand your point.

My thinking is that when you're setting a tag here, you are selecting the "end point" of the tag without dictating the exact hierarchy of the tag. Yes, it must be a certain type (Equipment vs Point / Property) but in here you are not dictating that Equipment Z must be a subcategory of Y which is the subcategory of X.

So instead of stating here DefaultSemanticTags.EQUIPMENT_X_Y_Z, you just say DefaultSemanticTags.Z.

This frees up the ability later on to restructure Z within core to be either promoted or demoted e.g. to become EQUIPMENT_Z, EQUIPMENT_X_Z, or even EQUIPMENT_A_B_Z without having to make changes in all the consumer of the constants.

It is still Z to you here, due to the virtue of Z having to be unique. There can never be EQUIPMENT_A_Z and EQUIPMENT_B_Z to require specifying the full path.

The advantage is simpler looking code. You know you want a FRIDGE. You shouldn't have to care if it's EQUIPMENT_FREEZER or EQUIPMENT_WHITEGOODS_FREEZER, or anything else.

It has a 1 to 1 equivalent of using a plain string vs constant.

A possible compromise could be to create the constants as TYPE_ENDNAME without having the hierarchy. So we'll have

EQUIPMENT (the root tag)
EQUIPMENT_FREEZER (not EQUIPMENT_WHITEGOODS_FREEZER)
LOCATION_LAUNDRYROOM (not LOCATION_INDOOR_ROOM_LAUNDRYROOM)

However this has the potential to be confusing.

[jimtng]

A possible compromise could be to create the constants as TYPE_ENDNAME without having the hierarchy. So we'll have

EQUIPMENT (the root tag) EQUIPMENT_FREEZER (not EQUIPMENT_WHITEGOODS_FREEZER) LOCATION_LAUNDRYROOM (not LOCATION_INDOOR_ROOM_LAUNDRYROOM)

I've changed it to this scheme now. I recognise that this makes it very clear the type of the tag without getting into the hierarchy details.

[jlaur]

Maybe we could use the casing ("SummerHouse") to also separate words with underscore, so this would become LOCATION_SUMMER_HOUSE, WDYT?

[andrewfg]

create the constants as TYPE_ENDNAME without having the hierarchy

Exactly. That is all I am asking for.

The idea of tag nesting is too complex to automate anyway.

Another (much better) idea would be to put the different classes of tag constants into actually different java classes. So you would have four classes Equipment, Point, Property, Location that contain each their own tag constants. So instead of using EQUIPMENT_XXX one would use Equipment.XXX

[jimtng]

@andrewfg and @jlaur - updated to
DefaultSemanticTags.Location.SUMMER_HOUSE

[andrewfg]

LGTM subject to #4616 and #4619 being merged.

---

EDIT: actually we don't need to wait for those PRs as their content can be added later I think. Or??

[andrewfg]

Brilliant! One of my wishes (when I grow up) is to be able to do regexes like that..

[andrewfg]

Yes, I like this structure. Thankyou.