Our fielded product updates Losant several times an hour; and in an errored condition, like a failed sensor, I create an event and update its event tage with a ‘number of errored occurrences’. I’ve bumped my head on a ‘maximum number of event updates’ limitation (seen below).
Of course the information that creates the event exists in the time-series, but isn’t available ‘at a glance’ when viewing the event itself.
Is there a recommendation on how to handle this without updating the event? Using a ‘number of occurrences’ tag was convenient, but I assume it comes with some overhead we are trying to avoid.
Thanks Team
I’m guessing this is an undesirable side effect of our recent changes to also historically track event tag updates. Let me run this case past the engineering team and see what ideas they have - if we can increase that limit, or add an option not to track the tag updates in the array, or something else entirely.
I think we’ll handle this by adding a flag on event creation to disable tag update tracking. Hopefully we can get that out in our March release but I can’t promise that quite yet.
We discussed doing the flag per event update but that introduces potential “chain of custody” type issues where a user could maliciously update an event without their changes appearing in the log.
I will keep you posted.
I made note of the tracking feature. I really do like the idea of maintaining an auditable log. But this particular aspect of the way I’m using one of the tags probably isn’t audit worthy. Perhaps on Event:Update nodes having an option to participate in the historical tracking might be a fix?
