The .generateUUID() and register(applicationName, uuid) methods are only relevant when coupled with the provisioning of a physical device. For instance, these resin-sdk methods are used by our resin-cli to implement the resin device init command, which is also part of our resin quickstart wizzard:
$ resin device init -h
Usage: device init
Use this command to download the OS image of a certain application and write it to an SD Card.
Notice this command may ask for confirmation interactively.
You can avoid this by passing the `--yes` boolean option.
Examples:
$ resin device init
$ resin device init --application MyApp
Options:
--application, -a, --app <application> application name
--yes, -y confirm non interactively
--advanced, -v enable advanced configuration
I think @simonkemper is trying to do exactly that? Provision a device through the SDK instead of the device provisioning itself. Would be good to have some more info or context on what happens in normal situations, or really any extra info. At the moment does look curious.
@imrehg@kostas Yes right! I am exactly trying to do this but I have figured out how the registration process works by taking a deep look into the CLI-Code and making some experiments.
All in all you can pre-assign a device’s image by setting the UUID property in the config.json which I assumed but it wasn’t mentioned. So that was what I was looking for! Basically I wanted to know more about the mechanism behind the scenes …
So this lead to another (two) question:
Has the device('s container) access to the config.json?
What is that “offlineMode=false” setting? And what does it?