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.