system.tag.storeTagHistory - Creating New Tag IDs and acting funny

Ignition
1

Hello,

I’m using the system.tag.storeTagHistory function, and I’m getting some somewhat unexpected behaviors.

When I first started messing with it, I noticed that every time I ran the function that it was creating a new tag ID in the sqlth_te table. It appeared that it was because the new value was being stored outside of the [create / retired] range. This is undesirable because I want to write values to these tags many times, and I don’t want to blow up my sqlth_te table with tag counts.

My solution for this was to manually update the sqlth_te table to give the specific tag that I’m working with a created datetime of 0 and a retired datetime of ~2099. This seemed to be working pretty well for the one tag I was looking at.

I then added a new tag, and I wrote a value, and then I updated the created / retired values.
Next, I wrote a value to that tag (using system.tag.storeTagHistory) again, and it created a new entry into my sqlth_te table with a restricted created / retired range.
Then, I wrote several more values to my tag on different dates, and they all went under the new tag.

So, my question is, how does the system.tag.storeTagHistory function actually work, and is there a way that I can get it to work without creating tons of additional tagid’s in my sqlth_te table?

If I need to do some manual configuration of the tags when I create them, I can do that and just make it part of my process. I just need to know exactly what to do, and it would be nice to know why…

Here is some of my data out of my DB:

These results are all based on querying the same tagpath.

select
top 1000
*
from
sqlth_te
where
tagpath like ‘some/tag/path’

select
top 1000
*
from
sqlt_data_1_2018_09
where
tagid in
(select id from sqlth_te where tagpath = ‘some/tag/path’)
order by t_stamp DESC

PS: Now, I just wrote a value with a DateTime before the t_stamp of the 2.22 value, and it created tagid 1026 with a created time of 1536987600000
and retired time of 1539101125010

Also, Running Ignition v. 7.9.2

2

Having worked through this pretty extensively with support, here is what seemed to be the solution:

It was recommended that I update to 7.9.9 because there were some changes to the storeTagHistory() function somewhere in there. No problem, upgrade completed.

Since I am storing tag history from before the point was created, it is EXPECTED that a new entry in the sqlth_te table be created. This will have a created date of your storeTagHistory() t_stamp, and a retired date of the created time of the original historian entry.

This was my initial thought, which was why I thought updating one of the te entries to a created t_stamp of 0 would solve the problem.

It turns out that I was correct, and if you are going to be storing history on tags from before they were actually created in the system, you can set the original tag created time to zero. After updating this sqlth_te created t_stamp to zero (or whatever earliest past date you will be using) you have to restart the Tag Historian.
This can be accomplished by restarting the entire gateway or changing something on the Historian Provider and applying the changes. I simply changed the description on the webpage and hit save changes, checked the log to confirm that it restarted the historian, and commenced testing my points. After this process, storeTagHistory() hasn’t created any additional sqlth_te entries.

The Caching is mentioned in the storeTagHistory() documentation, but I didn’t find it particularly clear and I certainly didn’t understand what I needed to do in order to use it properly.
https://docs.inductiveautomation.com/display/DOC79/system.tag.storeTagHistory

I hope this helps someone in the future (if so please like it so I know my time wasn’t wasted in posting the update / solution)

And big thanks to the support team.

-Rob W.

8 Likes