• State Verified Answer
  • Replies 8 replies
  • Subscribers 3 subscribers
  • Views 228 views
  • Users 0 members are here
Options
Related

Alternatives to step function - store last value before change?

PowerPI

I'm working with a MW value for a solar facility. It will obviously be 0 all night. Then at 8 am it will start updating. The last recorded value of 0 might be hours before that.

Then when a report is run using Datalink's sampled values (every 15 min), it will show interpolated values from the last recorded 0 until 8 am. I'm trying to find a way to not interpolate during that time frame but allow interpolation during daylight hours.

If the archive recorded the last value of 0 before updating the value at 8 am, that would practically eliminate the issue.

Is there a way to do that or another way to accomplish this? Thanks

 

Parents Reply Children
  • 0 in reply to PowerPI

    Nope, no mistake. If a point is stepped, then the last value before a changed value is not stored, as the value can always be inferred from the last value stored.

    If a point is NOT stepped, then the last value before a changed value is needed so that the interpolation is correct.

    Basically:

    Stepped:     0       1       2       3   
Not stepped: 0   0   1   1   2   2   3   3

    With regards to the compression settings, the situation is the following:

    Lets say you set exception testing to 0.1 and compression testing to 0.2 MW.

    And lets say the data you receive is:

    2.0, 0, 0, 0, 0, 0.05, 0.15, 0.4, 1.0, 2.0, etc

    Then what will happen is that the following data will pass exception testing:

    2.0, 0, -, -, -, -, 0.15, 0.4, 1.0, 2.0, etc

    All that data will also pass compression testing (0.4 passes the test, so 0.15 is added to the archive so that interpolation is "correct").

    You can alleviate that a bit by setting up a relatively short compmax, but that will mean lots of data stored that isn't really needed. Setting up a shorter excdev won't make a difference as the additional zeros will be thrown away by compression testing.

    All of these problems exist if you have any data source with relatively long time ranges of unchanged values and then get a first changed value that is only slightly different. Exception and compression testing is not able to correctly ensure that you store a completely straight line in that case.

    In cases where that straight line is really needed, you would basically have to set compression and exception testing to zero.

    There IS another thing you can try to work around this limitation generally :

    1. Set up a parallel AF attribute with a formula data reference.
    2. As the input put in the MW value attribute and simply output it.
    3. Set the output as stepped.
    4. Set up an AF Analysis that reads those two attributes.
    5. Set up a condition that checks against a time (daylight) or value (zero).
    6. Depending on that condition output either the stepped or the non-stepped attribute.
    7. This Analysis needs to be triggered periodically!
    8. Depending on your use case you can store the output or not. You can even disable the analysis and it will then only be executed when the output attribute is read.

    In your special case you can probably make your life a lot easier by simply checking your value against a lower threshold (say 0.5 MW) and outputting 0 if the value is below that (either through an analysis or a formula).