I’d like to create a UDT where the data is coming from similar valves via mqtt engine. I have setup the UDT properties using expression tags.
Here is what a typical valve tag looks like, where the “C01A” is the valve name.
{[MQTT Engine]Edge Nodes/tellus/ipusa/epic01/Strategy/Numeric Variables/C01A_SAV_domode}
Then I created a parameter string called ValveName.
So this is the expression I used so the tag uses the parameter value:
like {[MQTT Engine]Edge Nodes/tellus/ipusa/epic01/Strategy/Numeric Variables/{ValveName}_SAV_domode}
For the tag instance I am testing with, the parameter is set to “C01A”
But I’ve got something wrong because it is not substituting the value for the parameter, it is using the literal {ValveName}. I’ve tried an extra set (and even a third) of curley braces around {ValveName} within the expression, with no luck.
You cannot nest curly braces. Construct your outer tagpath as a string, concatenating with the inner curly braces. Supply that to the tag() expression function.
(The tag() expression function is a horrible hack to be avoided in all contexts other than expression tags, btw. IMNSHO.)
No, an expression tag is the right answer. And the tag() function is the right answer in an expression tag. I’m just advising you to not use the tag() function in UI bindings.
It is close.
I’m getting a conversion error.
Error_TypeConversion “The actual value was not able to be coerced into the configured data type for the source of this value.”
Here is the expression for the tag:
concat("{[MQTT Engine]Edge Nodes/tellus/ipusa/epic01/Strategy/Numeric Variables/", {ValveName} , “_SAV_domode}”)
Here is the error showing up for the tag instance :
Error_TypeConversion(“Error trying to coerce ‘{[MQTT Engine]Edge Nodes/tellus/ipusa/epic01/Strategy/Numeric Variables/C01A_SAV_domode}’ to a number.”)
Can I explicitly tell it to covert to an integer somehow?
The toInt() is not able to do the conversion. I can pass a failover value to the toInt(), but that really doesn’t help. I wonder what is really going on?
I am puzzled.
I set up two test UDT properties, one with the hard coded full mqtt path, and another with the concat function creating the same hardcoded full path.
They produce the same expression string, but the hardcoded one works and the concat one errors.
Do I have to do something to the result of the concat before it can be evaluated properly by the expression?
Your expression is supplying a literal string, which is trying to be coerced into an integer.
You need to wrap that entire expression in the tag() function to make it a dynamic lookup.
pturmel said that right off, but I did not understand.
tag( concat("[MQTT Engine]Edge Nodes/tellus/ipusa/epic01/Strategy/Numeric Variables/", {ValveName}, “_SAV_domode”))
I just needed to pull the curley braces off the tagname. Working Now! Thank you very much.
I see from some other posts that writing to expression tags does not seem possible. I guess that makes sense. So I think that will be a problem with the UDT I’m try to put together. Is there an alternative way to approach this UDT to the MQTT Tags. The on/off devices for this UDT are Valves, Pumps, Motors - so being able to write is a big part of it.
I’ve found myself using the tag() expression in UI elements more often lately. I’m curious to know why you recommend against using in that context and what alternative you prefer (if other than the standard indirect binding).
Indirect binding is significantly more efficient than the tag() function due to eliminating recomputing string expressions. The tag() expression function also has a history of producing pathological CPU use, particularly in Perspective. (Much reduced in current v8.1, though.)
Adding a custom property for an indirect tag binding also make dependent expressions much easier to understand/maintain. Just say no to tag().
I know this conversation has been done for a while, but I am running into a project that has used the expression function tag() in a lot of places, we are seeing occasional runaway CPU and client lockups. I stumbled upon this post and I am wondering if you think it could be a reason and why?
Yes, because expression functions must return a value. When starting up a binding, or dynamically changing the tag path, the tag value is not instantly available. tag() can do one of two things: stall for a result (which typically stalls the UI), or return "uncertain initial value". In the latter case, when the true initial value becomes available, the expression must execute completely again to pick it up.
Tag bindings (indirect or not) can simply do nothing at all until the proper value arrives, without stalling anything.
