[Feature] Expose 7 missing writable Device fields on New-/Set-NBDCIMDevice

[ctrl-alt-automate]

Follow-up from #409.

While verifying #409 against the live NetBox 4.5.7 OpenAPI schema (WritableDeviceWithConfigContextRequest), seven writable Device fields turned out to have no parameter on New-NBDCIMDevice or Set-NBDCIMDevice. All seven are nullable=true, so each one should be clearable via $null on the Set- variant from day one (consistent with the #409 pattern).

Missing fields

Field	Schema type	nullable	Notes
location	integer (FK)	true	Sub-site hierarchy — widely used since NetBox 3.x
airflow	string (enum)	true	7 values: front-to-rear, rear-to-front, left-to-right, right-to-left, side-to-rear, passive, mixed. Needs [ValidateSet] + parity check via scripts/Verify-ValidateSetParity.ps1
oob_ip	integer (FK)	true	Out-of-band management IP — FK to IPAddress
latitude	number (decimal 5,2)	true	Use [double] / [Nullable[double]] — not integer
longitude	number (decimal 6,2)	true	Use [double] / [Nullable[double]] — not integer
config_template	integer (FK)	true	FK to ConfigTemplate
local_context_data	object (JSON)	true	Freeform JSON — pass as [hashtable] / [object]

Proposed parameter types

Following the #409 pattern — [T] on New-, [Nullable[T]] on Set- for integers/doubles; [string] on both for airflow with clearing via "" (standard PrimaryModel blank=True convention); [hashtable] on both for local_context_data.

Parameter	New-NBDCIMDevice	Set-NBDCIMDevice	Clearing
Location	[uint64]	[Nullable[uint64]]	-Location $null
Airflow	[ValidateSet(...)][string]	[ValidateSet(...)][string]	-Airflow '' (verify against schema — may need $null)
OOB_IP	[uint64]	[Nullable[uint64]]	-OOB_IP $null
Latitude	[double]	[Nullable[double]]	-Latitude $null
Longitude	[double]	[Nullable[double]]	-Longitude $null
Config_Template	[uint64]	[Nullable[uint64]]	-Config_Template $null
Local_Context_Data	[hashtable]	[hashtable]	-Local_Context_Data @{} (TBD — verify against schema)

Implementation notes

• airflow null-clearing — schema says nullable=true but NetBox enums are historically blank=True strings. Before implementing, verify with a live PATCH whether "" or null clears it. See empty-string vs null clearing memory patterns.
• airflow ValidateSet — run scripts/Verify-ValidateSetParity.ps1 -NetboxVersion v4.5.8 after adding. NetBox 4.6 GA may expand the set; gate on current version's values.
• latitude / longitude precision — schema enforces decimal(5,2) and decimal(6,2) respectively. Use [double]; let server-side validation handle rounding / range.
• Tests — follow the [Feature] Null out various parameters on Set-NBDICMDevice #409 pattern: one $null assertion per nullable parameter, one happy-path assertion, one ValidateSet rejection for airflow.

Out of scope

• Site stays [uint64] (nullable=false — Device must live somewhere).
• Role / Device_Type / Status / Face stay unchanged (all nullable=false).
• Position precision bug ([uint16] → [double]) — tracked separately because it crosses more than just the Device scope.

Context

Original observation documented in the comment on #409. @mkarel expressed interest in contributing this one — assigning first right of refusal. If it's stale for ~2-3 days we'll pick it up on this side with Co-Authored-By credit per established pattern.

Targets v4.6.0 (accumulator branch on dev).

[ctrl-alt-automate]

Quick heads-up before you start — did some live schema + PATCH spelunking on zulu-how (NetBox 4.5.8) to save you a round-trip. Feel free to ignore any of this if your plan differs; this is reference, not prescription.

1. airflow ValidateSet — my original list was short

My issue body above lists 7 values. The live 4.5.8 schema has 10:

{
  "enum": [
    "front-to-rear", "rear-to-front",
    "left-to-right", "right-to-left",
    "side-to-rear", "rear-to-side",
    "bottom-to-top", "top-to-bottom",
    "passive", "mixed"
  ]
}

I missed rear-to-side, bottom-to-top, top-to-bottom. Source: GET /api/schema/?format=json → .components.schemas.WritableDeviceWithConfigContextRequest.properties.airflow. scripts/Verify-ValidateSetParity.ps1 -NetboxVersion v4.5.8 will also surface any further drift once the parameter exists.

2. airflow null-clearing — both null and "" work

Tested empirically on a live 4.5.8 instance with 4 PATCH calls (device state restored to original afterwards):

PATCH body	Result
{"airflow": "front-to-rear"}	200 — set
{"airflow": null}	200 — cleared to null
{"airflow": "passive"}	200 — set
{"airflow": ""}	200 — cleared to null (server treats "" as null)

The schema declares both in the enum ("enum": [..., "", null]) and nullable: true, same shape as Interface.duplex — so it fits the existing empty-string sentinel pattern from PR #401 (-Duplex '', -POE_Mode '', -RF_Role '' on Set-NBDCIMInterface). That pattern's the lowest-surprise fit here since PowerShell users already know the idiom from other Interface clears.

3. Other fields — quick schema check

While I was poking around I also spot-checked the schemas for the other 6 missing Device fields. Summary:

Field	OpenAPI type	nullable	Clearing
location	integer (FK)	true	JSON null — use [Nullable[uint64]] on Set- (same as #409 pattern)
oob_ip	integer (FK)	true	JSON null — use [Nullable[uint64]] on Set-
latitude	number (decimal, max 8.2)	true	JSON null — use [Nullable[double]] on Set-
longitude	number (decimal, max 9.2)	true	JSON null — use [Nullable[double]] on Set-
config_template	integer (FK)	true	JSON null — use [Nullable[uint64]] on Set-
local_context_data	object (free JSON)	true	JSON null

Note: latitude / longitude are decimal(8,2) / decimal(9,2) — my issue body said (5,2) / (6,2) based on older memory. No practical impact (max_digits only affects very large coordinates) but worth knowing if you're writing range tests.

4. Not doing any code — this is yours

I haven't touched New-/Set-NBDCIMDevice; this is all observational. You know the codebase and the test patterns from #398, so I'll stay out of your way. Ping me (or open a draft PR) whenever — happy to review with fresh eyes.

If you'd rather I pick this up after all (schedule-dependent things come up), just say the word. Same goes for #412.

[mkarel]

Thanks I will take a look at these hopefully this weekend if time allows. ~Matt Karel Two roads diverged in a wood, and I-- I took the one less traveled by, And that has made all the difference. -Robert Frost (The Road Not Taken)

…

On Fri, Apr 24, 2026, 2:31 AM Control-Alt-Automate ***@***.***> wrote: *ctrl-alt-automate* left a comment (ctrl-alt-automate/PowerNetbox#411) <#411 (comment)> Quick heads-up before you start — did some live schema + PATCH spelunking on zulu-how (NetBox 4.5.8) to save you a round-trip. Feel free to ignore any of this if your plan differs; this is reference, not prescription. 1. airflow ValidateSet — my original list was short My issue body above lists 7 values. The live 4.5.8 schema has *10*: { "enum": [ "front-to-rear", "rear-to-front", "left-to-right", "right-to-left", "side-to-rear", "rear-to-side", "bottom-to-top", "top-to-bottom", "passive", "mixed" ] } I missed rear-to-side, bottom-to-top, top-to-bottom. Source: GET /api/schema/?format=json → .components.schemas.WritableDeviceWithConfigContextRequest.properties.airflow. scripts/Verify-ValidateSetParity.ps1 -NetboxVersion v4.5.8 will also surface any further drift once the parameter exists. 2. airflow null-clearing — both null and "" work Tested empirically on a live 4.5.8 instance with 4 PATCH calls (device state restored to original afterwards): PATCH body Result {"airflow": "front-to-rear"} 200 — set {"airflow": null} 200 — cleared to null {"airflow": "passive"} 200 — set {"airflow": ""} 200 — cleared to null (server treats "" as null) The schema declares both in the enum ("enum": [..., "", null]) and nullable: true, same shape as Interface.duplex — so it fits the existing empty-string sentinel pattern from PR #401 <#401> (-Duplex '', -POE_Mode '', -RF_Role '' on Set-NBDCIMInterface). That pattern's the lowest-surprise fit here since PowerShell users already know the idiom from other Interface clears. 3. Other fields — quick schema check While I was poking around I also spot-checked the schemas for the other 6 missing Device fields. Summary: Field OpenAPI type nullable Clearing location integer (FK) true JSON null — use [Nullable[uint64]] on Set- (same as #409 <#409> pattern) oob_ip integer (FK) true JSON null — use [Nullable[uint64]] on Set- latitude number (decimal, max 8.2) true JSON null — use [Nullable[double]] on Set- longitude number (decimal, max 9.2) true JSON null — use [Nullable[double]] on Set- config_template integer (FK) true JSON null — use [Nullable[uint64]] on Set- local_context_data object (free JSON) true JSON null Note: latitude / longitude are decimal(8,2) / decimal(9,2) — my issue body said (5,2) / (6,2) based on older memory. No practical impact (max_digits only affects very large coordinates) but worth knowing if you're writing range tests. 4. Not doing any code — this is yours I haven't touched New-/Set-NBDCIMDevice; this is all observational. You know the codebase and the test patterns from #398 <#398>, so I'll stay out of your way. Ping me (or open a draft PR) whenever — happy to review with fresh eyes. If you'd rather I pick this up after all (schedule-dependent things come up), just say the word. Same goes for #412 <#412>. — Reply to this email directly, view it on GitHub <#411?email_source=notifications&email_token=AEO33S5JKX6QGNMNZQ7W3OL4XMC3LA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMZRGEYTKNRZGIYKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4311156920>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEO33S7ZOEBMHPMYLGMVQML4XMC3LAVCNFSM6AAAAACYEXVV32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGMJRGE2TMOJSGA> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AEO33S2UYYGD7BMSGMOTU4T4XMC3LA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMZRGEYTKNRZGIYKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AEO33S4OLDXJPLLAF5NSANL4XMC3LA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMZRGEYTKNRZGIYKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[mkarel]

The latest commit to address issue 411 & 412 looks to be associated with my existing PR. I did manual testing against the parameters, and everything looks good.