In MQTT Transmission 4.0.22, a reported refresh issue affected custom properties on existing tags, particularly when a custom property was bound to a UDT parameter and transmitted UDTs were converted to standard tags. The refresh controls under Transmission Info/Transmitters appeared to retain prior tag information while discovering new tags. By contrast, Transmission Control/Refresh appeared to republish the complete tag information.
Compare the Refresh Behaviors
| Refresh control | Observed result | Use in diagnosis |
|---|---|---|
| Transmission Info/Transmitters refresh options | Previously published tags appeared to retain cached property information; new tags were added. | Check whether an existing tag's changed custom property remains stale. |
| Transmission Control/Refresh | Appeared to retrieve and publish all tag information again. | Use as the available full-refresh path when existing metadata is stale. |
Identify the Affected Tag Configuration
The reported configuration used custom properties on existing tags. A custom property was bound to a UDT parameter, and MQTT Transmission was configured to convert UDTs to standard tags. The evidence does not establish whether stale data originated in the refresh control, property binding evaluation, UDT conversion, or another configuration detail, so treat the behavior as a reproducible symptom rather than a confirmed root cause.
Refresh and Verify the Tag Information
- Change or inspect the custom property on an existing affected tag.
- Run the relevant refresh under Transmission Info/Transmitters and check whether the existing tag reflects the current property value.
- If the property remains stale, run Transmission Control/Refresh.
- Verify that the existing tag now contains the current custom property and that newly added tags are still present.
If the behavior remains reproducible, provide the module configuration and an exported tag set to Cirrus Link support. These artifacts are required to reproduce the interaction between the bound UDT parameter, custom property, and UDT-to-standard-tag conversion.
Interpret the Version Evidence
The initial observation and the later successful verification both identify MQTT Transmission 4.0.22. The closing verification states that the modules worked properly on the latest module versions, identified there as v4.0.22. Because the evidence does not identify a separate fixed build, configuration change, or confirmed defect, do not attribute the resolution to a specific patch. Confirm the versions of all installed modules and retest the two refresh paths with the affected tag export.
FAQ
Which MQTT Transmission control performs a full tag refresh?
In the reported case, Transmission Control/Refresh republished all tag information, while refresh options under Transmission Info/Transmitters appeared to retain information for previously published tags.
Why does MQTT Transmission refresh new tags but not changed properties?
The observed case involved a custom property on an existing tag bound to a UDT parameter, with UDTs converted to standard tags. The evidence suggests a refresh-path issue but does not confirm whether caching, binding evaluation, or UDT conversion caused it.
Was the MQTT Transmission 4.0.22 refresh issue confirmed as a bug?
No confirmed root cause or fixed build is documented in the evidence. A later test reported proper operation with module version 4.0.22, so reproduce the behavior with the affected configuration and exported tags before escalating it.
