Community Tip - Visit the PTCooler (the community lounge) to get to know your fellow community members and check out some of Dale's Friday Humor posts! X
Reading up on the Edge SDK to try and understand the how the property aspects affect the behavior of data propagation from a VirtualThing on the edge to the RemoteThing in the Thingworx Platform on the server.
In general i understand the concept. Populate VirtualThing properties, then call updateSubscribedProperties() to tell the Edge SDK to push the property values up to the Thingworx Platform. I also understand that the property aspects pushType control when and if these property values actually get pushed.
Once the values are pushed to the Thingworx Platform, i understand that the cacheTime controls how the RemoteThing gets the update values.
Where i get confused is where exactly the values are stored. The documentation mentions that a cacheTime of 0 means that when the RemoteThing requests the value, it should request it from the property cache (as opposed to fetching it from the VirtualThing). Is the property cache a separate memory space from the property value? That is, does data always move from the edge to the property cache and then, when the RemoteThing requests the value, it moves the value from the cache to the property value memory space? What exactly happens here?
Solved! Go to Solution.
The platform has an in memory runtime model that will hold the latest property value assigned.
A device can be pushing values into that.
Depending what you set on the platform side.
Always Read from Cache - it reads what is in memory
Always Pull - it requests the latest known value from the Device
Cached for # seconds - when the there is a platform side request of the value, if within cache it reads cache, else it will request from device.
Hope that helps.
The platform has an in memory runtime model that will hold the latest property value assigned.
A device can be pushing values into that.
Depending what you set on the platform side.
Always Read from Cache - it reads what is in memory
Always Pull - it requests the latest known value from the Device
Cached for # seconds - when the there is a platform side request of the value, if within cache it reads cache, else it will request from device.
Hope that helps.
Hi @Robert Taylor and Pai Chung ,
I am trying to explain this in little more detail , Please let me know if you find my answer useful.
Synchronization of a remote VirtualThing with the ThingWorx server simplifies the data delivery process. You could make these updates on your own by directly calling a server RemoteThing over your SDK connection. However, the advantage of using a VirtualThing is that it introduces a cache between your remote data and its analog RemoteThing on the server. This cache allows you to efficiently manage requests between the server and your remote VirtualThing, preventing the server from making too many requests to your remote process. In addition, the cache allows you to easily bind the values in the cache to specific properties on a server RemoteThing.
This process of binding remote data to properties of a server RemoteThing allows you to compose server RemoteThings from the properties of multiple remote VirtualThings, enabling multiple remote devices or machines to contribute to the properties of a single RemoteThing on the server.
One remote device or machine could contribute data collected from a real sensor and push it to the server. The server could then notify a remote application that data had changed. That remote application could update itself and then contribute additional properties back to the server, based on its own calculations When it receives sensor data, a VirtualThing posts this data to the server cache.
RemoteThing on the server is bound to this property. This RemoteThing subscribes to changes in this property value. When this value changes, the subscription function is called. This subscription function notifies a VirtualThing in a remote application that new data is available.
This update could also be done using bindings since they can also trigger code within the remote machine. The result from the ThingWorx server perspective is that there is a single RemoteThing, whose state (its properties) is updated from multiple sources but appears to be a single entity as far as its use in mashups is concerned.
At the same time, it is providing a real-time, synchronized copy of its state that you can then use to manipulate the RemoteThing.
ThankYou
Ravi Upadhyay
Thanks for the detailed description. I did find it useful and i'm sure others will as well.