Community Tip - If community subscription notifications are filling up your inbox you can set up a daily digest and get all your notifications in a single email. X
I have a PLC Thing with a ThingShape. The ThingShape has a property that is bound to a kepware tag from the Thing. This property has a "!" next to it. What does this mean? Everything works fine, just curious.
Also, I noticed that in our DEV env, this property shows under the ThingShape without the "!". Why is the property showing differently in the other env?
Solved! Go to Solution.
This means that the property is overwritten. If you define the property on a Thing Shape or Thing Template and then "overwrite" it by binding a Kepware tag to it on an implementing Thing, the property definition is replaced by the tag. This is why the "!" icon appears. You will not see this icon when creating a Kepware tag directly on the Thing without having a previously defined property.
Similarly, you will notice the same "!" icon for services. Services defined on a Thing Shape or Thing Template can be set to "Overwritable," allowing them to have different implementations for different Thing Entities.
This means that the property is overwritten. If you define the property on a Thing Shape or Thing Template and then "overwrite" it by binding a Kepware tag to it on an implementing Thing, the property definition is replaced by the tag. This is why the "!" icon appears. You will not see this icon when creating a Kepware tag directly on the Thing without having a previously defined property.
Similarly, you will notice the same "!" icon for services. Services defined on a Thing Shape or Thing Template can be set to "Overwritable," allowing them to have different implementations for different Thing Entities.
So, if I create a property on a Thing, bind the kepware tag to this property, then bind the ThingShape property to this property, this would not happen? And also, is their a preference for best practice here?
I prefer defining the properties on the Template/Thing Shape and then binding the Kepware tags to them. This approach provides predefined names that you can reference in your services, among other things.
Simple example:
Imagine you have two assets sending temperature data to Kepware. The Kepware tag names might be something like "SENSOR_1_VAL" and "SENSOR_2_TMP". Here, you have two tags that logically represent the same value (a temperature), but their names differ slightly.
The issue becomes apparent when you bind the Kepware tags directly in the Thing itself. There's no clear identifier for the two assets to simply query the temperature. Of course, you could rename the property at the moment of binding the tag on the Thing. However, the easiest and most consistent approach would be to create a Thing Template with a "temperature" property that is then overridden by the Kepware tag.
This way, you can write custom logic that consistently references the "temperature" property on all Things implementing the Thing Template for your Temperature Sensors.