Point update method does not work as expected (sometimes)

[AlcibiadesCleinias]

Bug report

Description

When I have used update_value before Pt Created with REPLACE option PI Server merely flushed recently updated data (I guess, it flushed rows where the special flag had a place, i.e. Substituted flag, via: https://docs.osisoft.com/bundle/af-sdk/page/html/T_OSIsoft_AF_Data_AFUpdateOption.htm). I have not expected that, ofc.

However, for data that is updated after the Pt Created REPLACE method works as expected as I can see and test.

To Reproduce

import PIconnect as PI
from PIconnect.PIConsts import RetrievalMode
from datetime import datetime, timedelta

with PI.PIServer() as server:
    points = server.search(tag)
    p = points[0]
    
    created = p.raw_attributes['creationdate']
    created = datetime(created.Year, created.Month, created.Day, created.Hour, created.Minute, created.Second, created.Millisecond)
    
    print('before:')
    print(p.recorded_values(created, datetime.now()).head(), end=f'\n{"-"*10}\n')
    
    p.update_value(
        1e+10,
        time=created - timedelta(days=1), 
        update_mode=PI.PIConsts.UpdateMode.NO_REPLACE,
        buffer_mode=PI.PIConsts.BufferMode.BUFFER_IF_POSSIBLE,
    )
    
    print('updated:')
    print(p.recorded_values(created - timedelta(days=30), datetime.now()).head(), end=f'\n{"-"*10}\n')
    
    p.update_value(
        1e+10,
        time=created - timedelta(days=1), 
        update_mode=PI.PIConsts.UpdateMode.REPLACE,
        buffer_mode=PI.PIConsts.BufferMode.DO_NOT_BUFFER,
    )
    
    print('replaced:')
    print(p.recorded_values(created - timedelta(days=30), datetime.now()).head(), end=f'\n{"-"*10}\n')

Expected behavior

In my work, I have created test points in order to reproduce service behavior (aka test stand). So, newly created test points have their created stamp in a "recent" time, however, I was supposed to start debugging with historical data and here update_value method came to help me as I thought. So, I faced the bug mentioned above and spent time locating the one in a code. I believe, if there were a kinda warning about the buggy behavior it would save me time.

Possible solutions

Not sure that we want to dig into the PI problem hard, maybe there should be a simple warning on update_value older than created property (as for unexpected hardcode on your own risk behavior).

Screenshots

before:
2021-07-13 11:28:03+00:00    9003
2021-07-13 11:29:03+00:00    9000
2021-07-13 11:30:03+00:00    9001
2021-07-13 11:31:03+00:00    9002
2021-07-13 11:32:03+00:00    9002
Name: SINUSOID6, dtype: object
----------
updated:
2021-07-12 11:28:03+00:00    1e+10
2021-07-13 11:28:03+00:00     9003
2021-07-13 11:29:03+00:00     9000
2021-07-13 11:30:03+00:00     9001
2021-07-13 11:31:03+00:00     9002
Name: SINUSOID6, dtype: object
----------
replaced:
2021-07-13 11:28:03+00:00    9003
2021-07-13 11:29:03+00:00    9000
2021-07-13 11:30:03+00:00    9001
2021-07-13 11:31:03+00:00    9002
2021-07-13 11:32:03+00:00    9002
Name: SINUSOID6, dtype: object
----------

System

• OS: Windows Server 2012 SP3 (OSIsoft(r) AF SDK Version: 2.9.1.8106)
• Python version: 3.7.4
• PIconnect version: 0.9.1

Additional context

Ofc, maybe there is a good workaround how to fill the PI server with a lot of data for a newly created point. For me, I found the solution: use INSERT as an option for update_value of the test point.

UPD: I can report that the bug sometimes does not occur (you can possibly check it via several runs of the code). UPD2: I added ~~screenshot~~ result of script executing

[sulla138]

I also experience strange behavior. I use this command: attribute.update_value(point.value, point.time, update_mode = DataUpdateMode.REPLACE)

I expect the new entry to appear in the attribute's time series, and the new entry appears with the correct time, but the value is of the previous entry, i.e. (point.time, PrevValue) instead of (point.time, point.value)

[AlcibiadesCleinias]

I also experience strange behavior. I use this command: attribute.update_value(point.value, point.time, update_mode = DataUpdateMode.REPLACE)

I expect the new entry to appear in the attribute's time series, and the new entry appears with the correct time, but the value is of the previous entry, i.e. (point.time, PrevValue) instead of (point.time, point.value)

so, are you sure that point you have tried to update older than 'Pt Created' (as in my example)?

[sulla138]

@AlcibiadesCleinias

In my case, I just insert a point between two points, and the inserted point has the correct time, but the value of the point to the left of it.

[AlcibiadesCleinias]

@AlcibiadesCleinias

In my case, I just insert a point between two points, and the inserted point has the correct time, but the value of the point to the left of it.

ok, thank you for the replay, interesting... I do not notice such behavior.

Can you share what is update_mode = DataUpdateMode.REPLACE in https://github.com/Hugovdberg/PIconnect/issues/607#issuecomment-906595625 ? is it PI.PIConsts.UpdateMode.REPLACE ? And, maybe code to reproduce and your system info?

[sulla138]

Code to reproduce. DataUpdateMode.REPLACE is PI.PIConsts.UpdateMode.REPLACE

point_time = datetime(2018, 9, 9, 22, 59, 0)
point_value = 242851.032
attribute.update_value(point_value, point_time, update_mode=DataUpdateMode.REPLACE)

$ pip show piconnect

Name: PIconnect
Version: 0.9.1
Summary: Python connector to OSIsoft PI SDK
Home-page: https://github.com/Hugovdberg/PIconnect
Author: Hugo Lapré
Author-email: [email protected]
License: MIT license
Location: c:\users\pc\appdata\local\programs\python\python37\lib\site-packages
Requires: pandas, pythonnet, future, wrapt, pytz
Required-by:

$ sys.version '3.7.4 (tags/v3.7.4:e09359112e, Jul 8 2019, 20:34:20) [MSC v.1916 64 bit (AMD64)]'

AF SDK Version 2.9.1.8106. Assembly Version 4.0.0.0. .NET: v4.0.30319

[vadtam]

@AlcibiadesCleinias In my case, I just insert a point between two points, and the inserted point has the correct time, but the value of the point to the left of it.

ok, thank you for the replay, interesting... I do not notice such behavior.

Hello. Can you write your Python version, PiConnect version and PIAF Version (including SDK).

[Hugovdberg]

This is some strange behaviour, but I'm not sure I can fix this myself. I don't have a server at my disposal on which I have write permissions, so I'm not able to test this. Is this issue still occurring with the 0.10 release of PIconnect?