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
Stage | Owner | Outcome |
|---|---|---|
| 1. Prepare PDK | Dealer / Installer | Cloud nodes, readers, devices, groups, and card formats are ready. |
| 2. Connect system | PDK administrator | The STRATIS marketplace Configure flow captures the PDK System ID. |
| 3. Enable integration | STRATIS | Site Composer creates the integration and performs initial synchronization. |
| 4. Map access | STRATIS + property | Roles, amenities, and PIN preferences are mapped to PDK groups. |
| 5. Commission | Installer + property | Representative access, denial, expiry, and revocation tests pass. |
Roles
| Role | Responsibilities |
|---|---|
| PDK Dealer / Installer | Install and commission PDK hardware; configure the PDK site, cloud nodes, readers, devices, groups, and credential formats; launch the STRATIS connection. |
| STRATIS TechOps | Enable the integration in Site Composer; synchronize the layout and groups; configure role, amenity, and PIN mappings. |
| Property Representative | Approve required access by user type and amenity; participate in acceptance testing and handoff. |
Pre-flight Checklist
- Administrator access is available for the correct site in PDK.io.
- All PDK cloud nodes are powered, online, and assigned to the correct site.
- Readers, doors, and access devices are created and assigned to the correct cloud nodes.
- PDK groups exist for Resident, Visitor, Staff, Installer, and amenity access patterns.
- Device and group names are final and match the approved property layout.
- Card formats, facility codes, and planned credential types are documented.
- A supported USB credential reader is available when physical cards or fobs are in scope.
- STRATIS can access the target property in Site Composer.
- 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
- Open the target site in PDK.io.
- Open Marketplace / Integrations.
- Locate the STRATIS integration tile.
- Select Configure.
- On the STRATIS form, select I’m already in contact with STRATIS.
- Enter your full name and email address. Enter the property name if requested.
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
- Open the property in Site Composer.
- Select Tools.
- Locate PDK and select Open.
- In Enable PDK Integration, open Select a PDK System ID.
- Select the entry corresponding to the property connected in Stage 1.
- Select Enable Integration.
- 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
- Confirm the expected System ID appears in the PDK tool header.
- Select Sync Layout.
- Compare buildings, cloud nodes, and access points with PDK.io.
- 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
- Select Sync Groups.
- Confirm live groups are returned.
- Confirm the result reports 0 drifted.
- 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
STRATIS Role | Mapping Level |
|---|---|
| Resident | Unit |
| Visitor | Unit and Property |
| Property Visitor | Property |
| Guest | Unit |
| Staff | Property |
| Manager | Property |
| Property Administrator | Property |
| Installer | Property |
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
- Open Amenity Access.
- Select Add Amenity Unit.
- Select the STRATIS amenity unit and corresponding PDK group.
- Save the mapping and repeat for each amenity.
- Test one selected and one unselected amenity during commissioning.
Configure PIN Preferences
- All roles initially have Assign PIN disabled.
- Enable Assign PIN only for eligible roles that should receive PDK PINs.
- Enable Email PIN when STRATIS should send newly created PINs by email.
- 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
Credential Type | Raw Bytes | Hex Characters | Packet Width |
|---|---|---|---|
| 4-byte MiFare Classic (common) | 4 | 8 | 32-bit |
| 7-byte MiFare Ultralight / DESFire | 7 | 14 | 56-bit |
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.
Field | 32-bit Value | 56-bit Value/Note |
|---|---|---|
| Name | USB32 | Use a clear name such as USB56 |
| Num Bits | 32 | 56 |
| Card Holder ID Bits | 32 | 56 |
| Card Holder Start Address | 0 | 0 |
| Facility Code fields | Blank | Blank — a CSN has no facility code |
| Parity fields | Blank | Blank — a raw UID has no parity fields |
| Default Min Input Bits | 31 | Bracket the actual 56-bit packet |
| Default Max Input Bits | 33 | Bracket the actual 56-bit packet |
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
- Open the cloud node’s Edit Active Card Format screen.
- Select the new reusable format.
- Confirm the node-level minimum and maximum input-bit range brackets the credential packet length.
- Resolve any overlapping active ranges before saving.
- Repeat for every cloud node serving an in-scope door.
- Tap a credential and verify the node decode log returns the expected decimal credential number.
Interpret the Decode Log
| Decode Result | Explanation and Steps |
|---|---|
| Expected decimal + DENY | The format is correct. Check the holder’s groups and access rules. |
| Raw hexadecimal string | The tap was not decoded. Recheck format fields and node activation. |
| Shifted or smaller decimal | Bits may be consumed by parity, facility-code, or offset settings. Leave those fields blank and use start address 0. |
| No active format supports this length | Widen the node’s minimum/maximum input-bit range. |
| Completely different decimal | Possible byte-order mismatch. Escalate; do not guess because the PDK credential number is immutable. |
Commission the Integration
Foundation Checks
- Correct PDK System ID appears in Site Composer.
- Expected cloud nodes and access points appear.
- Expected PDK groups appear and synchronization reports 0 drifted.
- Access-point names and hierarchy match PDK.io.
- Each amenity maps to the intended PDK group.
- Every required role has a group mapping; unused roles have no unintended access.
Resident Acceptance Test
- Create or select a test resident and assign the correct unit.
- Issue the property’s intended PIN, fob, or garage credential.
- Confirm the PDK holder, group memberships, and credential in PDK.io.
- Test a representative authorized common-area reader.
- Test an unauthorized reader to confirm denial.
- 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
- Grant the intended property-level mapping to a test staff or installer user.
- Test representative authorized and unauthorized doors.
- Grant one amenity, then test the selected and an unselected amenity.
- Remove the user or amenity mapping and confirm access is revoked in PDK.io and at the reader.
Visitor Test
- Create a visitor invitation.
- Confirm delivery of the visitor PIN.
- Test the PIN at a physical PDK reader.
- Revoke or expire the invitation.
- Confirm the change in STRATIS and PDK.io.
- 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:
- PDK site name and verified System ID.
- List of commissioned cloud nodes, readers, and doors.
- Active card formats on each cloud node.
- Final PDK group list and STRATIS role-to-group mapping.
- Amenity mappings and enabled PIN preferences.
- Credential formats, UID lengths, and facility-code requirements.
- Commissioning results, known limitations, and open issues.
- Installer, property, and STRATIS support contacts.
- Date and time of final layout and group synchronization.
Troubleshooting
| Symptom | Corrective Action |
|---|---|
| System ID missing in Site Composer | Repeat Configure from the STRATIS tile, submit the form, and reload Site Composer. |
| No live groups | Confirm groups exist and cloud nodes are online; run Sync Layout, then Sync Groups. |
| Synchronization drift | Compare PDK.io with STRATIS; correct PDK.io and synchronize again. |
| User has no access | Check STRATIS role, role mapping, PDK holder, group membership, and credential state. |
| User has too much access | Remove the incorrect role/group or amenity mapping and verify live PDK groups. |
| Fob rejected at one node | Check the node-level active card format and minimum/maximum input-bit range. |
| Revoked credential briefly works | Allow asynchronous cloud-node synchronization, then retest and escalate if access remains. |
| Devices changed after go-live | Run Sync Layout, then Sync Groups, and review mappings for drift. |
Comments
0 comments
Please sign in to leave a comment.