PDK Installer Guide 

The following guide provides instructions on how to connect a commissioned PDK system to a STRATIS property, validate the synchronization, and complete a controlled handoff. 

Prepare, Connect, and Enable PDK Integration 

Prerequisites 

Stages 

Roles

Pre-flight Checklist 

1. Administrator access is available for the correct site in PDK.io.  
2. All PDK cloud nodes are powered, online, and assigned to the correct site.  
3. Readers, doors, and access devices are created and assigned to the correct cloud nodes.  
4. PDK groups exist for Resident, Visitor, Staff, Installer, and amenity access patterns.  
5. Device and group names are final and match the approved property layout.  
6. Card formats, facility codes, and planned credential types are documented.  
7. A supported USB credential reader is available when physical cards or fobs are in scope.  
8. STRATIS can access the target property in Site Composer.  
9. The property has approved the intended role and amenity mappings.  

Record the System ID shown under PDK.io > System Settings for verification only. The normal integration workflow does not allow manual entry of the System ID.  

Connect the PDK System 

Stage 1: Launch Configure in PDK.io 

1. Open the target site in PDK.io.  
2. Open Marketplace / Integrations.  
3. Locate the STRATIS integration tile.  
4. Select Configure.  
5. On the STRATIS form, select I’m already in contact with STRATIS. 
6. Enter your full name and email address. Enter the property name if requested. 

7. Select Connect My System and confirm the success message.

    

   

   Configure passes a one-time authorization token to STRATIS. STRATIS redeems it for the System ID and makes that system available for selection in Site Composer. Do not copy and paste the System ID into an unrelated property.  

Stage 2: Enable the Integration in Site Composer 

1. Open the property in Site Composer. 
2. Select Tools. 
3. Locate PDK and select Open. 
4. In Enable PDK Integration, open Select a PDK System ID. 
5. Select the entry corresponding to the property connected in Stage 1. 
6. Select Enable Integration. 
7. Wait for the page to reload and display “PDK integration enabled.” 

If you see an empty drop-down, repeat the PDK.io Configure flow, submit the form, and reload Site Composer. An empty list means the System ID was not captured successfully or has not arrived yet. 

For a property still being staged, select the System ID before Move to Production. Leaving the field empty causes the PDK integration step to be skipped. 

Synchronize and Map Access 

Synchronize the Layout 

1. Confirm the expected System ID appears in the PDK tool header.  
2. Select Sync Layout.  
3. Compare buildings, cloud nodes, and access points with PDK.io.  
4. Correct naming or cloud-node assignments in PDK.io, then synchronize again.  

PDK.io is the authoritative source for the PDK hardware layout. Correct hardware and group configuration in PDK.io rather than masking a mismatch only in STRATIS.

Synchronize Groups 

1. Select Sync Groups.  
2. Confirm live groups are returned.  
3. Confirm the result reports 0 drifted.  
4. If groups are missing, correct them in PDK.io and synchronize again.  

Groups must be synchronized before role mappings are created. 

Map STRATIS Roles to PDK Groups 

Use the + control on each synchronized PDK group to assign the appropriate STRATIS role. A role without a group mapping will not receive PDK access. 

Map Amenities 

1. Open Amenity Access. 
2. Select Add Amenity Unit. 
3. Select the STRATIS amenity unit and corresponding PDK group. 
4. Save the mapping and repeat for each amenity. 
5. Test one selected and one unselected amenity during commissioning. 

Configure PIN Preferences 

1. All roles initially have Assign PIN disabled. 
2. Enable Assign PIN only for eligible roles that should receive PDK PINs. 
3. Enable Email PIN when STRATIS should send newly created PINs by email. 
4. Do not enable ordinary role-based PIN assignment for Visitor or Property Visitor; those roles use the shareable-PIN invitation workflow. 

Configure USB/CSN Card Formats 

Use this section when STRATIS enrolls the raw serial number (CSN/UID) of a MiFare credential with a USB reader. A CSN has no facility code. The PDK cloud node must have a number-only card format capable of decoding the complete UID packet.  

STRATIS cannot configure PDK card formats through the integration API. Define the format in PDK.io and activate it on every existing cloud node that protects an in-scope door.  

Determine the UID Length 

Confirm the credential population before configuration. A 32-bit-only format will deny a 7-byte credential.

Define the Reusable System-Level Format 

In PDK.io, add a card format and populate only the required fields. Leave optional facility-code and parity fields blank for a raw CSN.  

Support Facility Code Processing and Supports Parity should display as not supported when the optional fields are blank. For CSN formats, that is the correct result. 

Activate the Format on Every Cloud Node 

1. Open the cloud node’s Edit Active Card Format screen. 
2. Select the new reusable format. 
3. Confirm the node-level minimum and maximum input-bit range brackets the credential packet length. 
4. Resolve any overlapping active ranges before saving. 
5. Repeat for every cloud node serving an in-scope door. 
6. Tap a credential and verify the node decode log returns the expected decimal credential number. 

Interpret the Decode Log 

Commission the Integration 

Foundation Checks 

1. Correct PDK System ID appears in Site Composer. 
2. Expected cloud nodes and access points appear. 
3. Expected PDK groups appear and synchronization reports 0 drifted. 
4. Access-point names and hierarchy match PDK.io. 
5. Each amenity maps to the intended PDK group. 
6. Every required role has a group mapping; unused roles have no unintended access. 

Resident Acceptance Test 

1. Create or select a test resident and assign the correct unit. 
2. Issue the property’s intended PIN, fob, or garage credential. 
3. Confirm the PDK holder, group memberships, and credential in PDK.io. 
4. Test a representative authorized common-area reader. 
5. Test an unauthorized reader to confirm denial. 
6. Revoke the credential and confirm the PDK record and physical reader behavior update. 

For Schlage properties with a shared physical credential, test both the PDK common-area reader and the Schlage unit lock. 

For Yale configurations, validate the approved separation between PDK common-area credentials and Yale unit access. 

Staff, Installer, and Amenity Tests 

1. Grant the intended property-level mapping to a test staff or installer user. 
2. Test representative authorized and unauthorized doors. 
3. Grant one amenity, then test the selected and an unselected amenity. 
4. Remove the user or amenity mapping and confirm access is revoked in PDK.io and at the reader. 

Visitor Test 

1. Create a visitor invitation. 
2. Confirm delivery of the visitor PIN. 
3. Test the PIN at a physical PDK reader. 
4. Revoke or expire the invitation. 
5. Confirm the change in STRATIS and PDK.io. 
6. Physically retest the PIN after revocation or expiration. 

Internal QA guidance currently identifies visitor PIN operation outside the scheduled invitation window as a known limitation. Do not promise time-window enforcement until the installed release has been physically verified. 

Existing Properties Outside Site Composer 

When the property is not available through normal Site Composer navigation, STRATIS can enable the canonical PDK setup process, then provide the direct PDK management page for synchronization and mapping. The legacy process should produce the same partner, property profile, PIN preferences, layout sync, and group sync as the standard workflow. 

Handoff Package 

The handoff package to clients should contain: 

1. PDK site name and verified System ID. 
2. List of commissioned cloud nodes, readers, and doors. 
3. Active card formats on each cloud node. 
4. Final PDK group list and STRATIS role-to-group mapping. 
5. Amenity mappings and enabled PIN preferences. 
6. Credential formats, UID lengths, and facility-code requirements. 
7. Commissioning results, known limitations, and open issues. 
8. Installer, property, and STRATIS support contacts. 
9. Date and time of final layout and group synchronization. 

Troubleshooting