On my Edge node I would like to visualize the OPC values as often as possible. Lets say every second…
My edge device runs on a unstable 4G connection, and i would like to sample values only every minute. How can I limit the forwarded MQTT packages to this limit?
Is the only solution to create a expression function with a 60sec pollrate?
When transferring tag history with MQTT its seems to always store history with a 2 second sampling rate. (given that the deadband is 0.00000001).
There is the “Tag Pacing Period” that will throttle the frequency at which tag change messages are sent, but this will still include the changes from a given tag that occurred within that window. For example, if you had a tag that changes every second and you adjusted your Tag Pacing Period from the default of 1000ms to 60000ms, then MQTT Transmission would only emit a message every minute, containing the  value-change updates from that past minute.
I have actually set pacing to 5 minutes.
Even though, as the customer is satisfied with 1 minute sampling, I dont need to send 60 times the amount of data…
I have allready tried “filtering” using reference tags, before adding them into the MQTT Set Transmission Set. But reference tags does not use tag groups timing. (bug maybe?)
Any solutions you might think of Kevin? Or someone else?
Creating a “buffer”/“filter” using Expression tags is not really feasible for my application…
My intuition initially was to suggest Reference Tags, but after testing it locally (to make sure I didn’t feed you false hopes), I found the same. I’ll be filing an issue for this, as I think it would be a handy option to have in various situations. At the very least, we shouldn’t show Tag Group option when in Reference Tag mode, otherwise you’re led to intuit that it should respect the Tag Group timing configuration.
Is this Ignition Edge at, well, your edge? … or full Ignition?
Ignition Edge MQTT with History Sync.
Thanks for filing the issue.
As per now @kcollins1, there is no way of limiting the samples over MQTT. I think that we need the Tag group option for reference tags.
Any update regarding this issue? I have a customer delivery coming up, and I guess I can run on “power” mode for a short while. But this will cost us in the long run…
This seems to me like something that should be configurable in the MQTT module - something like a queue size that can be set to limit the number of changes per tag that are reported after each “tag pacing period” has elapsed.
Are your edge tags actually changing so often that this is a problem or is this discussion theoretical right now?
I did engage in some follow-up discussions on this topic, and the general consensus is that reference tags are designed for efficiency and not with “polling” in mind; therefore, they’re not intended to follow the same poll timing configurations as OPC tags use, for example. There are other aspects of tags as they relate to tag groups in addition to the polling rate, so that is why even reference tags (like all tags) are still members of a Tag Group.
I see @Kevin.Herron already posted a reply before I got this one finalized, and I agree that throttling of max-changes-per-tag-per-tag-pacing-period (or something similar) seems like a good feature for the MQTT Transmission module.
What about just creating a separate set of OPC tags (with a different Tag Group and polling rate) and using those only for publishing via MQTT Transmission (leaving your current ones to be used for visualization)?
Based on the intention of reference tags I agree with kcollins1 about were to locate the throttling. Also Ignition already have installed a throttling mechanism in the tag historian module (minumum sampling time).
It makes even more sense that the low bandwidth software supplier has this functionality embedded. I will forward this to cirrus-link as an idea.
@Kevin.Herron, Its just theoretical, but i like my system to be deterministic and who knows how much the sensors will change.
@kcollins1 Thats a great idea, all my tags are already nesten within UDT’s, so ill just make a duplicate set and a new parameter for tag Group.
Any idea how two OPC tags in different groups work with the modbus engine… Will it pull twice, or is there some smart logic here… ?
If you have 2 OPC tags pointing at the same address but with different sampling rates they are treated separately and each will be polled on its own cycle.
At least if you’re using our server and Modbus driver.
Ok, guess that makes sense.