I would just show a datetime with the information posted by the device to show when it last communicated.
It isn't connected as would a RemoteThing through an Agent, it is a 'Thing' that is receiving periodic updates from somewhere.
As values are written to properties, the timestamp is recorded and can be retrieved using the VTQ services.
this way you can show how 'fresh' the information is.
Oops I see you want to create a device automatically.
I would be very careful since it'll be easy for someone to mimic making the http requests and 'spam or dos' your server
If your device has any logic capabilities, you can have it do a specific call that creates the Thing
else you could possibly monitor your Application Log and pull certain errors from it to then create the Thing
Again be VERY CAREFUL you shouldn't just create a representative Thing because you got an HTTP call, it should be identified and verified.
Thanks a lot Pai! I am new to ThingWorx so I still have many gaps.
So just to confirm,
1) the RemoteThings template is intended JUST for physical devices that implement an edge agent?
2) When you say that HTTP requests have to be identified and verified, isnt it enough to use appKey header in the HTTP request?
and last question:
3) unbound things is just for physical devices that implement an edge agent?
Thanks a lot for your fast answer!
Not sure if you've gone through any of the classes but there are some good classes that explain these concepts.
Remote type things have a few uses
1. Connection with our ThingWorx agent to provide bi-directional secure communication using our Always-On technology
2. ThingWorx federated connection
[I believe some of our Connection Server integration to Azure and Amazon might leverage Remote Things as well, not certain]
If someone at some point even gets their hands on the appKey they can spoof being a device. If your device talks http that is even made easier to do.
In Monitoring Remote Things, the Unbound Things tab shows Agents that are connected to the platformed but not mapped/bound to a representative Remote type Thing
So if you are just doing http to Thingworx, you could go with a full fledged model, or you could even go with a single Thing that becomes the request processor. Use case should drive the solution design.