Skip to main content
lguagneli1-Visitor
1-Visitor
October 4, 2017
Solved

Behaviour querypropertyhistory and PUT history

  • October 4, 2017
  • 11 replies
  • 3843 views

Hi all,

I have already consulted the old posts but did not find a good answer to my case.

I have different thing that have several properties. One of this properties is a integer "Counter" that for each PUT increment the value of this counter. Each thing has its own ValueStream.

The question in general is that I would like to retrieve the history of this put.

I have try to obtain this with querypropertyHistory but it happens that some row return duplicated and I don't know why.

Capture.png

The oddest thing though happens when I look at the behavior through a mashup where I put the QueryPropertyHistory service commanded by a timeselector and autorefresh.


Iit happens that at a given instant the service shows the duplicate row (same counter) and the next step is replaced by the row with the incremented counter.

Can someone help me to understand this behaviour?

But the most important question is: What is the best way to obtain the pure history of the PUT write?

Best answer by CarlesColl

I don't think this is the correct way of storing this kind of data.

Let's start with some basics:

  • ValueStream -> It's purpose it's to store one property at a time, ValueStream storage structure: timestamp, propertyName, value
  • Stream --> It's purpose it's to store one or more values at a time, Stream storage structure: timestamp, value1, value2, value3, valuer4,...

In your case I think you should go for Stream storage instead of ValueStream, as you want more than one property recorded at the same exact time and this won't happen with a ValueStream approach. What happens with QueryPropertyHistory it's it creates a fake complete row for each different timestamp that you have on any recorded property, copying previous value for empty properties on that exact timestamp.

Of course storage on Stream's are a bit more complex as you can't relay on plug-in feature as ValueStream has, you will need to have subscriptions or a timer which records the desired properties at the frequency you want.

Best Regards,

Carles.

11 replies

jamesm15-Regular Member
5-Regular Member
October 7, 2017

Can you make sure that the property data change info is set to value? I am not able to recreate this issue. What version of TWX is this on?

Alternatively, you can use the service UpdatePropertyValues ​to update the property with a value, timestamp, and quality. If the timestamp and value are the same, this will prevent the additional counter from being logged.

lguagneli1-VisitorAuthor
1-Visitor
October 9, 2017

This property has Data Change Type to Value.

Ok! I can use UpdatePropertyValues, but I'm quite sure that the Counter increments each PUT the device .

CarlesColl1-VisitorAnswer
1-Visitor
October 10, 2017

I don't think this is the correct way of storing this kind of data.

Let's start with some basics:

  • ValueStream -> It's purpose it's to store one property at a time, ValueStream storage structure: timestamp, propertyName, value
  • Stream --> It's purpose it's to store one or more values at a time, Stream storage structure: timestamp, value1, value2, value3, valuer4,...

In your case I think you should go for Stream storage instead of ValueStream, as you want more than one property recorded at the same exact time and this won't happen with a ValueStream approach. What happens with QueryPropertyHistory it's it creates a fake complete row for each different timestamp that you have on any recorded property, copying previous value for empty properties on that exact timestamp.

Of course storage on Stream's are a bit more complex as you can't relay on plug-in feature as ValueStream has, you will need to have subscriptions or a timer which records the desired properties at the frequency you want.

Best Regards,

Carles.

lguagneli1-VisitorAuthor
1-Visitor
October 10, 2017

Ok! I was quite sure that this should be the way but on the other hand in this way I will have redundant data and I don't know what does it means in terms of db writings.

So after an initial transition period, I could consider to remove valueStream from all things and keep a single stream or it's better to hold both?

What do you suggest to do?

CarlesColl1-Visitor
1-Visitor
October 10, 2017

One or the other but no sense on having booth. Well we have a combination of boot on our solution but not to store the same Properties on the same Thing.

Terms & ConditionsAccessibility statement