cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Need to share some code when posting a question or reply? Make sure to use the "Insert code sample" menu option. Learn more! X

Behaviour querypropertyhistory and PUT history

lguagneli
1-Newbie

Behaviour querypropertyhistory and PUT history

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?

1 ACCEPTED SOLUTION

Accepted Solutions

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.

View solution in original post

11 REPLIES 11
jamesm1
5-Regular Member
(To:lguagneli)

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.

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 .

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.

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?

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.

Ok! This it's true. I will work on this side.

Just another question about this. So you said that the behaviour of the QueryPropertyHistory is conforming to the fact that we use valueStream.

In other words QueryPropertyHistory works fine and with a single PUT I can have more than one row in the result of this service?

I'm sorry, I don't understand the question

I just wanted to be sure that the behaviour I have seen using the ValueStream is correct.

Anyway I will work with stream instead of value stream and I'll let you now.

Hi,

You can't have more than one row for a single put on the ValueStream itself, you will have only one value recorded on the ValueStream, but QueryPropertyHistory doesn't returns raw ValueStream data, it returns a "fake" join between all the different values for Thing properties.

Best Regards,

Carles.

Thank you.

This is exactly what I thought but I did not know if it was correct. There's no way to get row as is from valueStream.

This is helpfull for me.


Yes for sure, all the services "Query"+baseType+"PropertyHistory" does it. Also if you use QueryPropertyHistory for a single property will do it either.

Top Tags