Closed jamesjara closed 6 years ago
jobs
like shadow
is built on top of device
. Basically, it shares same implementation of device which opens a connection with a unique client ID.
Hmm but so if I already have
var thingShadows = awsIot.thingShadow({
clientId: <YourUniqueClientIdentifier>,
});
then I use the jobs lines latter, because I need to be subscribe to the shadow changes but also to any OTA job request
var jobs = awsIot.jobs({
clientId: <YourUniqueClientIdentifier>,
});
Is this using the same unicuqe connection internally (I guess if the clientId match) ? Because currently we have the thingShadow already implemented on the devices and we are testing the OTA with aws-jobs
Right now, if you do not provide clientId, SDK will generate a unique id for each session. In this case, the client ids would be different. If using same client id, the connection will drop due to id conflicts. Right now, the SDK does not provide a uniform wrapper on both. Or you could use job class to subscribe shadow topics by your own. By doing this, you will implement shadow behavior by yourself.
okay thanks for the information, so it is okay to have two different client connections from the device running at same time, living together connecting to the aws-iot service?
That is totally fine although there is an account level throughput limit and other limits as well so you cannot have infinite connect sessions in the end. For your reference. https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html#limits_iot
Please open another thread if you still have questions.
Hello
As we know the device can only run one single connection by same client id, based on that. A physical device opens a connection with the
device
implementation to subscribe to the AWS IoT Shadow. I was wondering how it that will work based on thejobs
implementation seems to create another new MQTT client