The value stream attached to the thing's properties in my model, sometimes (rather most times) shows values at almost same time stamp (a microsecond difference, even when I gave the time difference for each trigger to be at least 10 seconds) with some of the properties being identical whereas some changing according to the logic written in the subscription or service. So just to clarify it, for example if there is logic where if the subscription runs the value of speed and distance of a thing should change but sometimes it changes only distance with speed being identical from the last reading and sometimes it does vice versa. This kind of results in an unreliable data most of the time and I am afraid that data cannot be fed in the Analytics server for further analysis, since it will not make sense to feed in partially correct data to train the model.
Theoretically, every time a subscription runs it gets stored in a value stream and hence both the values should change (according to my code), no matter at what frequency the value s stored in the value stream. Is it correct or am I missing something here?
P.S: it is important to note that sometimes it just runs smoothly with everything in place and all correct readings with proper time gaps and sometimes it just becomes so confusing just to look at the data and to understand what is going wrong. And all this happens without me changing anything in the code, but just running at maybe different times of the day (for ex. once every 3 hours)
TW it's not a real time system, then you can't expect you will have perfect event executing as requested, maybe you have too many event triggers ( or other background processes ) and your event subscription executions gets queued and executed all in once...
Just my two cents,
Yes, I think so too, but don't you think if it is implemented in real-time systems(such as industries) it should at least be fast enough to execute a long and complex subscription, especially when the time difference between the triggered events is 10 seconds?
Or should I break down a big subscription into few smaller ones? However, in my opinion, after looking at the TW behavior, it seems that multiple subscriptions for one trigger would rather be more confusing.
For sure you should break long lasting subscriptions, having long lasting service executions will kill you TW Instance, as each service execution starts a Transaction and with it you start getting blocking conditions.
OK Sure, I will try it the way, you suggested and will see if there is any change in the output.