4 Replies Latest reply on Sep 22, 2016 12:15 PM by mlemus

    SetValue including a Timestamp for PI AF Attributes using data reference <None>


      I would like to update the timestamp of an attribute that has data reference <None>, using PI Web API and the SetValue PUT attributes/{webId}/value functionality. We have a larger plan - a use case for us is that we have many PI AF attributes that behave like static values and we have no interest  in tracking if or when those change but we would like to know the current value and the timestamp that was grabbed from the external source. These PI AF attributes are currently using Table Lookup references and we want to get away from this functionality and use a web service model to update these types of attributes only when changed. Using Fiddler as a test, I can set the value but not the timestamp. I was was able to update a new child-attribute called Timestamp, with value of timestamp, but that seems like a waste. PI AF Attributes, like PI Points, should be able to have a timestamp value other than 1970-01-01, right? 

        • Re: SetValue including a Timestamp for PI AF Attributes using data reference <None>
          Rick Davin

          Hi Marc,


          Static attributes, i.e. attributes with a null data reference, are not historical in nature and generally have one timestamp.  Technically this timestamp is not 1970-01-01 but rather the EffectiveDate of the Element.Version.  One could save values with specific dates by creating new Element versions, but I generally try to avoid that.


          If you are going to have no more than a handful of dates, consider an AFTable and the Table Lookup data reference.  If you have more than that, you really should use the Data Archive to historize your data.  Given the question, you seem reluctant to do this.  May I ask why?


          If you never want to historize an attribute, then you will need 2 static attributes: one to hold the value and the other to hold that value's DateTime.




          1 of 1 people found this helpful
            • Re: SetValue including a Timestamp for PI AF Attributes using data reference <None>

              Hello Rick,

              I agree, I don't want to use versions.  We are experimenting with moving away from table lookups of data that comes form an external database.  We have about 200 of such attributes.  Since you asked, I find it hard to accept making a PI tag for something that won't change.  I have done so, many times and I understand for some EA customers with unlimited tags, this is probably OK.  I used to use ModuleDB properties back in the old days and when we were using RtReports.  But now Coresight is the favorite tool and it seems to choke on loading lots of assets with lots of attributes. As I pointed out, and you confirmed, I can use the Attribute/Child Attribute, one to hold the value the other to hold the timestamp, but that won't look very intuitive to visualization people.

                • Re: SetValue including a Timestamp for PI AF Attributes using data reference <None>

                  Hello Marc,


                  What you describe appears like a valid use case for Table Lookup to me. If you like to move away from referencing data that is stored in external databases, you can create the table directly in AF. It's also possible to Import the data of an external table and to create an AF table with this data.


                  EDIT: Sorry, I have used the wrong wording. Instead of creating a Linked Table, you create a Table Import. This will persist the external table in AF. Please note that changes to the external table will not automatically reflect in the imported AF Table.

                  1 of 1 people found this helpful
                    • Re: SetValue including a Timestamp for PI AF Attributes using data reference <None>

                      Gregor, Thank you for the reply.  We are using imported not linked tables, and the asset counts we are talking about are around 6,000.  So we do see a delay with bringing all that in to cache.  We also found that "linked" option using parameters and getting data directly from external tables, which is the only way to get current data into a table without manually re-importing it, was extremely slow!


                      I was speculating about a few things:

                      (1) The attributes with <None> have values/timestamps that are coming directly from PI AF, i.e. - kind of behaving like "static" or constant values. - there are 5 of these type attributes and some of these are String Builder and use attribute values from the table lookups;

                      (2) The attributes with Table Lookup references, are getting data from PI AF too, via the "imported" tables, each requires a SQL statement for each element/attributes - there are 55 of these from three different tables;

                      (3) The PI Point referenced attributes are getting current values/timestamp, so that seems quick enough - in my use case I have 55 of these - I'm going out on a limb here and saying that the performance of bringing in these values to AF Cache is good.


                      My theory is that if leave the PI Point references alone but remove any table lookup references and instead use <None> and populate the values with a service, only if they have changed, that the client cache load will improve, and I hope, significantly.