When I create a new Calculated Tag inside the default tag provider, MQTT Transmission does not automatically publish it to the MQTT broker. The tag only becomes visible in MQTT Explorer after I manually click Refresh in the Transmission Control folder.
This happens every single time a new Calculated Tag is added — whether I add one tag or an entire subfolder of tags.
In a production environment where Calculated Tags are added regularly by engineers who are not always aware of the MQTT refresh requirement, this creates a silent data gap — tags appear healthy in Ignition but are simply not publishing to the broker until someone notices and manually triggers the refresh.
.
This expected/designed behavior. See here for more details:
Hi Wes,
Is there any plan to address the list of manual actions required in that first link you provided? Took me entirely too long to discover that page after running into several of them through observation only… At least for those with a definite cause and corrective action, seems like Transmission could/should be capable of identifying the situation and refreshing (etc) to keep things synchronized.
Or if architectural limitations of Sparkplug v3, is anything on the roadmap with v4 that might address root causes?
Thanks,
Michael
This was really a design choice in MQTT Transmission. Many people use scripting to create, delete, or modify tags. If Transmission automatically published a new BIRTH on any change of any tag, it would be really problematic. Instead, we chose to make this control via a tag (which can also be scripted against) to support a more automatic behavior.
We also now have a ‘Refresh Required’ tag on a global and per Edge Node basis. So, this can further aid in scripting/automatic refreshing.
Thanks for replying. I have watched the Sparkplug v4 video you were on a few weeks ago, would the “ABIRTH” or “MBIRTH” you describe at the 43 minute mark potentially allow most/all of these situations to be eliminated in a future major update if the v3 BIRTH message disruption is reduced? https://www.youtube.com/watch?v=6CZAe3KcqJM
Sorry to keep on about it, I’m not trying to be unconstructive and do appreciate there are constraints. We are in that situation where we want to script tags, and distributing over Sparkplug as means of transparently exposing everything via a UNS is an ideal solution. But the experience has been frustrating and feels fragile when having to micromanage Transmission and Engine on multiple gateways to get UDT definitions and tags propagated out reliably, and it compounds with scale (gateway/tag count and number of people maintaining tags). In contrast, distributing over a Remote Tag Provider just works, however we stand to lose the inherent UNS output without additional effort.
Again, thanks for engaging in a discussion.
With regard to Sparkplug v4 ‘modified births’ - I haven’t actually spent too much time thinking about how that will be implemented in Transmission specifically. I would guess at this point we may offer an ‘autodetect and publish’ option given the load will be far less that it would be now. So, it may eliminate your concerns around the full refresh.
With regard to management, yeah it can be a bit cumbersome. We do have some customers that use the EAM module from IA for UDT management at the Edge systems but still use MQTT for data. Maybe this could be a good option for you?
