The documentation and API to add/modify/delete customers is very complete. The differnet actions supplied can do pretty much anything you want.
Contrary to this is the clientDevice and prizmElement types. The API is silent as to adding these types and no action seems to exist that returns an elementId. Compare this to addCustomer which returns the customerId. The appearance is that all elements should be discovered first, then they may be managed. I likely don’t understand how prizm is functioning but that is what it looks like from the API point of view.
Either a couple of networkIf types and actions are missing that might enable the addElement functionality or I have really missed the knowledge boat concerning how one is to accomplish the feat without the devices prior discovery. Maybe one is always required to discover the element first. The difficulty in that situation is an installer waiting in the field to have a unit accepted after the first failed attempt at registration.
The reason behind wanting this is to activate a clientDevice, allow its full management by prizm, and when it first registers, make attribute changes to the element as they have been passed to prizm. This is somewhat like the GUI procedure detailed in guide starting on page 94 titled
Prizm2 User Guide wrote: Procedure 17: Accepting an uninstalled element for BAM-only operations
And, the reason you want to do this is to allow the provisioning of the device before it’s installation. One must get the donkey in front of the cart