[openipc-ai]

For OpenIPC/majestic#341: majestic's motor settings have moved from isp.autofocus to a single ptz block. majestic-af reads them from there since OpenIPC/majestic-af#30, and OpenIPC/firmware#2585 bumps the firmware's pin to it.

Three device profiles write the old keys on first boot. majestic no longer reads those keys, and nothing carries them over. Each profile now writes its ptz equivalent instead:

Profile	Was	Now
gk7205v510_ultimate_zenointel-sd-2n-4g	.isp.autofocus.enabled true, .isp.autofocus.actuator gpiostep	.ptz.enabled true, .ptz.actuator gpiostep
hi3516dv100_lite_xm-n81820	.isp.autofocus.enabled true, .isp.autofocus.actuator ms41908	.ptz.enabled true, .ptz.actuator ms41908
hi3516ev300_lite_xm-85h50ai	.isp.autofocus.enabled true	.ptz.enabled true

The first two matter most. ptz_control=gpiostep and ms41908 do not switch the motor on by themselves (only the two Pelco values do), so without this change those heads would boot with no motor at all. The 85H50AI also gets the motor from ptz_control=pelco-xm, so its line is for consistency.

Merge this in the same release as the firmware pin bump and the matching majestic nightly. With the new keys and an older majestic, these boards would lose the motor in the opposite direction.

[openipc-ai]

/review

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Upgraded cameras can lose motor control 🐞 Bug ≡ Correctness

Description

The replacement .ptz.enabled and .ptz.actuator values are written only by the one-shot
customizer.sh, with no migration for cameras configured under the old keys. When an existing
camera upgrades without rerunning customization, the new Majestic configuration does not receive the
settings that select and enable its motor.

Code

devices/hi3516dv100_lite_xm-n81820/general/overlay/usr/share/openipc/customizer.sh[R29-30]

+cli -s .ptz.enabled true
+cli -s .ptz.actuator ms41908

Evidence

The new values appear in first-boot customizers, while the repository documents that customization
runs once and that the upgrade URL it wrote survives upgrades. No upgrade-time migration is shown in
this repository; the precise behavior of the external firmware upgrade path is not established here.

devices/hi3516dv100_lite_xm-n81820/general/overlay/usr/share/openipc/customizer.sh[22-30]
CLAUDE.md[65-68]
.github/workflows/master.yml[688-694]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Existing cameras may not rerun the first-boot customizer after upgrading, so replacing the old motor settings there alone does not configure them for the new Majestic version.
## Fix Focus Areas
- devices/hi3516dv100_lite_xm-n81820/general/overlay/usr/share/openipc/customizer.sh[29-30]
- devices/gk7205v510_ultimate_zenointel-sd-2n-4g/general/overlay/usr/share/openipc/customizer.sh[48-49]
- devices/hi3516ev300_lite_xm-85h50ai/general/overlay/usr/share/openipc/customizer.sh[31-31]
## Recommended Fix
Provide an upgrade-time migration that sets the appropriate `.ptz.*` values for already-customized devices, without overwriting settings users have changed. Coordinate it with the firmware and Majestic update.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can turn these tips off under Display > Comment parts

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗