Write to tag and set timestamp?

When I write to a tag, can I set the timestamp as well somehow?

I am collecting history for a tag from the response from an API call and storing it to the tag, but I also want to set the current value to the latest value in the history with its associated timestamp intact. Possible?

You should be able to construct a complete QV (value, quality, timestamp) and write that instead of just the value.

1 Like

Yep, should have known that haha. Cheers

#example only
from com.inductiveautomation.ignition.common.model.values import BasicQualifiedValue, QualityCode
BasicQualifiedValue(14, QualityCode.Good, system.date.now())
2 Likes

Hmm, just trying this again for something else, I actually don’t know if it is working… as a test I created a new memory tag with history enabled with no min capture rate (max time between samples), and to capture all records.

from com.inductiveautomation.ignition.common.model.values import BasicQualifiedValue as qval, QualityCode as qc

tagPath = '[default]Testing/New Folder 1/Test'
now = system.date.now()
now = system.date.setTime(now, 0,0,0)

values = []
value = qval(50, qc.Good, system.date.addHours(now, 3))
values.append(value)

value = qval(50, qc.Good, system.date.addHours(now, 5))
values.append(value)

system.tag.writeBlocking([tagPath]*len(values), values)

system.tag.queryTagHistory([tagPath], now, system.date.setTime(now, 3,1,0), returnSize=-1)

If I run this at 1707, I see a single historical entry added at 1707, not at 0300 and another at 0500 :frowning: Even if I try to write a single value, the result is the same - the timestamp is always the time of the write and not the time that I’m supplying.

@PGriffith should this work? Or how else can I write a value with timestamp to a tag? And will this write that timetstamp into the history as well if the tag is historised?

Essentially, we have a 3rd party system which stores history for some things. We’re pulling in this history via API calls every 10 mins and we might get a handful of historic points in that time. I want to:

  1. store that history into the Ignition database for corresponding Ignition tags
  2. write the latest value with timestamp to the corresponding Ignition tags

I’m guessing the timestamp of the tag is not what the historian uses to store data: Your tag timestamp will be set to whatever you provide, but then some other mechanism determines the timestamp for the historized data.

You can try system.tag.storeTagHistory, which should allow you to provide your own timestamp to the historian, but you’ll need to un-historize your tag or you’ll get 2 entries for the same data point, with 2 different timestamps.

2 Likes

The tag history system filters out tag changes with timestamps going backwards in order to avoid problems with OPC servers that sometimes deliver updates out of order.

IIRC, there’s a setting to disable that behavior. I don’t recall where.

FWIW, the proper way to populate past history is with the storeTagHistory function. (Whoops, just noticed pascal mentioned that.)

1 Like

In the advanced properties on the realtime tag provider:

This is actually what I have been using, but I also wanted to write the latest historical value to the value of the tag, keeping the timestamp of the historical record. If I write all historic records using storeTagHistory and also write the tag value, I would then get two entries in the database (well actually I believe I’m getting duplicate id errors stacking up in my s+f quarantine log due to exactly this). So then I thought that maybe I could just use tag.write* to write all of the historical records using qualified values to the same tag in the one tag write function. Maybe this would bring other complications, but I was curious to see if it would work.
I think i’ll just go back to what I originally planned and write all but the latest record using storeTagHistory, then write the latest record via tag.write*.

The gateway I actually tested this on does not have this option checked, however the gateway I’m actually using this for does since we are predominately talking to MQTT devices. This probably explains why I was seeing it working when I first posted, but then wasn’t seeing it working yesterday on the other gateway. It’s all very complicated…