feat: Add modern React UI with comprehensive feature enhancements #1941
+40,381
−10,027
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Major feature release adding a modern React-based web UI and numerous backend improvements for the Motion video surveillance daemon. Frontend (React 18 + TypeScript + Vite + Tailwind CSS): - Dashboard with camera streaming and quick settings bottom sheet - Settings page with scope filtering (global vs camera parameters) - Media browser with folder navigation, thumbnails, and pagination - Visual schedule picker for motion detection and recording - Hardware encoding warnings and device-aware recommendations - Configuration profiles for save/load/delete presets Backend (C++): - Migrated from legacy POST processor to JSON API endpoints - Session-based authentication with bcrypt password hashing - CSRF protection with session tokens for streams - Thumbnail generation for media library - libmicrohttpd static file serving with SPA routing support - Removed legacy webu_html and webu_post modules Infrastructure: - systemd service installation with watchdog integration - Automated installer script with dependency management - bcrypt-based password management CLI tool (motion-setup) - Comprehensive installation guide and Quick Start docs Security: - Session token authentication for all API endpoints - CSRF protection with dual token validation - Secure cookie handling with HttpOnly flags - Auto-detection of config paths with secure defaults Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
The file data/webcontrol/samplepage.html is a static HTML file that doesn't require autoconf processing. Automake was looking for samplepage.html.in template file which doesn't exist and isn't needed. This fixes the autoreconf error: configure.ac:739: error: required file 'data/webcontrol/samplepage.html.in' not found
The file was referenced in Makefile.am but missing from the working tree, causing build failure. Restored from git history (commit 756b22b). Fixes make error: No rule to make target 'doc/motion.png', needed by 'all-am'
Adds full UI support for all three Motion camera backends, allowing users to configure USB cameras (V4L2), Raspberry Pi cameras (LIBCAM), and IP cameras (NETCAM) from a unified React interface. Backend (C++): - Add camera_type field to status API (libcam/v4l2/netcam/unknown) - Add camera_device field (device path or URL) - Expose V4L2 controls array via new public accessor - Expose NETCAM connection status and dual-stream indicator Frontend (React/TypeScript): - Add useCameraInfo hook for feature detection - Add CameraSourceSettings component (type badge, device info) - Add V4L2Settings component (dynamic USB camera controls) - Add NetcamSettings component (IP camera configuration) - Update Settings page with conditional rendering - Update MovieSettings to show passthrough only for NETCAM Architecture: Hook-based feature detection with discriminated unions for type safety. No breaking changes - fully backward compatible. Files: 4 created, 7 modified (167 insertions, 17 deletions) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Required for NETCAM_STATUS enum and cls_netcam class access. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Add encapsulation methods to cls_camera for safer camera type checking and device access. This improves code maintainability by avoiding direct pointer access from web API handlers. Backend changes: - Add has_v4l2(), get_v4l2_controls() for V4L2 camera access - Add has_netcam(), has_netcam_high() for netcam stream checking - Update webu_json.cpp to use new accessor methods Frontend changes: - Remove unused config/onChange props from CameraSourceSettings - Fix TypeScript type assertion in useCameraInfo hook Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Implements intelligent camera detection with user-confirmed addition workflow.
Enables first-run camera setup and runtime camera management via Settings UI.
Backend Changes:
- New cam_detect module for Pi/USB/Network camera detection
- Platform identification (Pi model, libcamera/V4L2 capabilities)
- Sensor-aware defaults (imx708/219/477/296)
- V4L2 blacklist filtering (ISP devices)
- Persistent device ID resolution (/dev/v4l/by-id/)
- 5 new API endpoints: platform, detected, add, delete, test
API Endpoints:
- GET /0/api/cameras/platform - Platform info
- GET /0/api/cameras/detected - List unconfigured cameras
- POST /0/api/cameras - Add camera from detection
- DELETE /{camId}/api/cameras - Remove camera
- POST /0/api/cameras/test - Test netcam connection
Frontend Changes:
- Camera Management section in Settings (Global Settings)
- Multi-step Add Camera Wizard (Select → Configure → Test → Complete)
- Detected camera cards with specs and resolutions
- Configured camera cards with view/remove actions
- First-run welcome experience for zero-camera setups
- React Query hooks for detection and management
Key Features:
- Auto-detects Pi cameras (CSI) and USB cameras (V4L2)
- Manual network camera configuration with connection test
- CPU-efficient on-demand detection (no background scanning)
- Sensor-specific optimal defaults for Pi camera modules
- Frontend caching (30s detected, ∞ platform)
Files Added:
- src/cam_detect.{cpp,hpp}
- frontend/src/components/settings/CameraManagement.tsx
- frontend/src/components/settings/AddCameraWizard.tsx
- frontend/src/components/settings/DetectedCameraCard.tsx
- frontend/src/components/settings/ConfiguredCameraCard.tsx
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Enable seamless camera navigation within the Quick Settings panel via dropdown selector, allowing users to switch between cameras without closing and reopening the sheet. The switcher automatically hides for single-camera setups to reduce UI clutter. Changes: - Add CameraSwitcher component with dropdown for multi-camera selection - Integrate switcher into Dashboard bottom sheet header - Simplify sheet title (camera name now shown in dropdown) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Add type casting for API POST calls to resolve TypeScript errors - Split CI workflow into separate frontend and backend jobs - Add frontend linting and build verification to CI - Remove unused platformInfo prop from AddCameraWizard - Add support for unknown camera type in DetectedCameraCard - Change CameraManagement to default export - Regenerate build artifacts with fixes Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Member
|
Thanks for PR. There is a lot here so it will take some time to review and pull this in. I'm currently busy with "life" but from just an initial look, I think we'd need the following:
Since this is pretty big and there seem to be a few issues to resolved. How do you want to go about discussing/resolving them? Separate discussions for each item? (I don't know a way to have separate discussions/resolutions to each topic/issue in a PR and I want the discussion somewhere in the Motion repo for tracking) |
Author
|
Sorry for the lengthy email. I split it into sections so you can skip to
the parts you are interested in.
Based on your responses, I see the main issue is that I developed the UI
based on incorrect assumptions.
*Assumptions*
1. Libcamera was the main camera interface and thus Raspberry Pi was the
main platform.
2. The UI was just a convenient, built-in interface for users. But not
required for using Motion (I'm still not sure this is incorrect)
3. Forcing people to update from out-of-date software (I know this is
ALWAYS met with resistance) is going to happen. This was the time to do it
(ex. moving to JSON UI).
a. Again, the UI was built, but it was (supposed to) be designed to
be used "If wanted" and can be ignored if not. It doesn't run unless it is
used.
4. The master branch was the most recent. I didn't see the "5.0" branch
until most of the UI had already been developed.
*Responses*
1. If you installed it fresh it should've compiled fine, but I did have to
merge with the 5.0 branch. This likely caused some issues that weren't
thoroughly vetted.
2. I thought the "Clean" scripts were only the local scripts I created from
deploying fresh copies of Motion during my dev.
3. This could've been caused by the merge.
4. This was a bad assumption on my part. I would like to keep an option for
Pi specific since it has the GPIO pins. There is already a "Pi detection"
that is being used to show/hide those specific scripts.
a. This can be added to the Discussion
5. The POST can be brought back and run alongside the UI. JSON allows for
better/easier security (from my experience, but that could just be my
experience). After altering the UI to its current state on my branch the
POST was not used. I *What is the purpose of this? An easy connection for
custom built UI or connecting to Motion externally?*
6. Honestly, I didn't pay much attention to where it was being stored, just
that it was being accessed consistently from the same location.
7. I completely agree with the Error-free Compiling. I think the warnings
were "Types". They weren't causing issues and I knew there would likely be
changes to what I proposed.
8. If you used the install.sh included (CLI), there is a part where it asks
for the user to enter the admin password and then the viewer username and
password. If you didn't enter those at that point then it didn't complete
the setup. In my hurry to complete it and send the v1 of it to you I didn't
test other methods of installation. A more modern security was added. I
wasn't sure how secure it should be made (home network vs exposed to the
web). Maybe the security that was added was overkill.
*My Current Understanding*
1. Motion is designed to be platform agnostic, but Linux focused
2. Raspberry Pi's libcamera is ONE method of connecting to cameras
3. Backwards compatibility is high priority
*Optional Recommendations*
1. Based on some more recent discussions, keep the UI as a "Nice to be able
to use" and available, but specific to how you want it. If a user wants to
use a different UI (MotionEye, custom, etc) they can as the API's will
still be open for those connections. Trying to accommodate everyone and
every scenario with a built-in UI is very difficult and will make you go
bald (if not already). If you give them "most" of the options through the
built-in UI there should not be too many complaints about it.
2. Keep the Pi scripts if Pi is detected, but ensure it is modular. This
can be used as an example for adding scripting fields for other devices as
well (ex. Arduino, trigger Python scripts, etc).
a. If not already done, expose flags like Motion Detected, recording
started, recording ended, etc.
3. Alter the UI security to be configurable/selectable: User/password,
plaintext - bcrypt. I think this was already implemented. There is a method
for recovering/resetting a lost admin password, documented in the root
directory README.md.
4. Create documentation with examples will help transitions. The Pi
libraray for the CSI camera has changed dramatically, but the others likely
have not. The APIs for most of Motion doesn't need to change (that I know
of), so this doesn't have to be quite the revision I originally thought.
The UI can be though.
*Questions*
1. Can the UI be self-contained, a Use-it-As-is feature, or does it need to
be designed with a specific? Meaning, does this need to be designed
a specific way or can it follow a "Here are the majority of options for the
widest range of users" design?
a. With proper documentation which includes examples, are you
comfortable with exposing API's for anyone that doesn't want to use the
built-in UI so they can interface using a different UI?
2. The POST, What is the purpose of this? An easy connection for custom
built UI or connecting to Motion externally?
…On Sun, Jan 25, 2026 at 11:04 PM Mr-Dave ***@***.***> wrote:
*Mr-Dave* left a comment (Motion-Project/motion#1941)
<#1941 (comment)>
Thanks for PR. There is a lot here so it will take some time to review and
pull this in. I'm currently busy with "life" but from just an initial look,
I think we'd need the following:
1. On my server it did not compile. Looks like some of the
compatibility with prior versions of ffmpeg were removed and need to be
restored.
2. On my dev machine, I noticed the the M4 directory isn't in the UI
branch and is needed. (Note that some of the custom clean scripts need to
get adjusted to prevent this from be cleaned away)
3. The branch seems to have some problems with the webcontrol vs webui
being installed.
4. Since Motion isn't just PI software (it is all platform, etc), we'd
need to remove the PI specific things like the scripts.
5. I see the webu_post was remove in favor of JSON. I think that may
be too much for some of our users and we'd need to bring that back to be
alongside of the JSON. The change from GET to POST was already almost too
much for our users. (Note that the previous processing had some unresolved
problems with the url encoding requirements)
6. I think the default directories need a discussion. Historically it
was in /etc/motion but that prevented users from accessing/changing things
while the app is running. In V5 I was inclined to go to /var/lib/motion so
configurations as well a runtime data could be stored. I think I saw in the
PR that it was using /usr/local/etc/motion.
7. There were a few compiler warnings. I've gone with the approach
that Motion doesn't have any warnings.
8. I was able to get the point of seeing the start page but only got a
"Unable to connect to Motion. Please check the server." Probably due to
some of the new authorization items added but I didn't do. We probably need
to think about legacy users as well as new ones.
Since this is pretty big and there seem to be a few issues to resolved.
How do you want to go about discussing/resolving them? Separate discussions
for each item? (I don't know a way to have separate discussions/resolutions
to each topic/issue in a PR and I want the discussion somewhere in the
Motion repo for tracking)
—
Reply to this email directly, view it on GitHub
<#1941 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BRF2C6HGMOPOFANAOA4BMC34IWN6HAVCNFSM6AAAAACSXZ65USVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOOJXHEYTEMJXGE>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Restores backward compatibility with IoT devices and scripts that use form-urlencoded POST requests while maintaining security through optional CSRF token validation. Key Changes: - Restored webu_post.cpp/hpp (967 lines) from pre-removal state - Added Content-Type based routing (form-urlencoded vs JSON) - Implemented optional CSRF validation: * No token: Allowed (backward compatible) * Valid token: Allowed (secure mode) * Invalid token: Blocked (attack prevention) - Fixed compilation issues: * Added ctx_detected_cam forward declaration in conf.hpp * Added camera.hpp include in cam_detect.cpp * Fixed JsonParser.getInt() -> getNumber() in webu_json.cpp - Added comprehensive test script (test_urlencoded_post.sh) API Support: - URL-encoded POST: snapshot, pause, events, PTZ, config, camera mgmt - JSON API: Unchanged, full CSRF protection maintained - Both APIs coexist without interference Security Model: - JSON API (React UI): Always protected with CSRF + session tokens - URL-encoded POST: Optional CSRF for backward compatibility - Invalid CSRF tokens: Always blocked Tested on Raspberry Pi 5 with all commands verified working. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Member
Quite a few users interact with the Motion application via the web interface api (previously via the GET commands). The default web page interface itself doesn't need to show all the parameters but I think that the API would need to handle all of them. The web control/interface page also needs to be optional and have an option that does not rely upon any external resources/libraries. i.e. It retrieves nothing from the internet/web to work.
Updating a parameter, pausing/starting detection, checking whether detection is running, starting a recording, getting a snapshot, working a timelapse, etc. All this may be just by the user's own curl scripts/cron jobs, etc or perhaps their own web page they built. The JSON may be easier, I haven't tried it. I was just thinking of keeping the post to not change too much from what was in place before as well as still giving them the option of the previous standalone isolated web control page. Regarding the M4 problem (number 2). It is resolved by adding a new dependency for
Yea, I'm not sure I'm going to be persuaded on including PI scripts. Motion is packaged with Debian and therefore it will come with RapsiOS. Motion is also deployed across a variety of other platforms. I've had my experience of trying to include various OS builds and its just not worth the effort. e.g. I'm not going to creating and maintaining scripts for my PI zero, my PI2, the next PI6, the Arduino, the OrangePi, the PIs running BSD, the Suse servers, the Macs, Rocky, the....(you get the point) I do have lots of other comments and changes that I'd want before it goes to master (I'm guessing some of them may not be what you'd want such as the PI scripts). I'm thinking we may just want to implement a few changes and then pull it into the 5.0 branch with your changes all intact and then revise from there. |
Member
Author
|
1. UI self-contained - Absolutely, everything is self-contained and doesn't
need the internet/web (are you also referring to installation?). I like
that. The UI was designed to be optional if users wanted to use it, with
all APIs (existing and new) available for external connection (external to
Motion) should they want to use an alternative UI.
2. POST - I did a little research into this myself and see why it is quite
useful. I've added it back in. I also now have a better understanding of
the M4.
3. Pi Scripts - I think there is a miscommunication on this one. There were
some Pi scripts for restarting/shutdown the Pi, but those should've been
the only ones. There is a spot to add a custom script (similar to the one
spot MotionEye has). There are actually several, based on On-Record,
Off-Record, On-Motion, etc. I was wondering if that custom script field
could be left if a Pi platform is detected.
I had also added platform detection (I think it is looking for the OS)
and currently adding detection for the version of FFmpeg (this one was
tricky to handle once detected).
All the camera controls in the UI are using libcamera, Picamera, or
ffmpeg. Those API controls are platform agnostic.
4. *The UI in the PR should NOT be pulled into any production branch*. I
had realized after I sent that last email that I had neglected to include
Net/IP Cam and USB cam. Plus, no method of adding a camera.
My apologies for that. It was bad form sending a PR with such blatant
issues.
The "implement a few changes at a time" will work for quite a bit. The
React/JSON UI I built can be installed in parallel with the existing one.
It could be changed via the config file, and option during
installation/upgrading, or any other you like the best.
Side Note:
I don't want to try and push you in a direction you don't want to go. This
has been your baby for quite some time and I respect that. I was using
Motion and saw some room for improvement, but was using a very narrow
viewpoint. This discussion has given me a lot of insight into the direction
you would like to go and
You might already have seen/experienced the pain points of libcamera and
ffmpeg. Libcamera changes were significant, but not major. FFMPEG changes
from 4.7 - 8.0 have been major breaking changes. Developing a way of
handling that is what I'm working on right now.
*Current Task for Me*
I am going to try and develop everything I think is useful based on our
discussions, including the UI, debug it so it should run First-Time-Go,
then let you know so you can look to see if it generally follows what you
are looking for. Then we can split it up into different branches and start
pulling the pieces you want, update/work on the others.
Does that work for you?
…On Tue, Jan 27, 2026 at 1:44 PM Mr-Dave ***@***.***> wrote:
*Mr-Dave* left a comment (Motion-Project/motion#1941)
<#1941 (comment)>
1. Can the UI be self-contained, a Use-it-As-is feature, or does it
need to
be designed with a specific? Meaning, does this need to be designed
a specific way or can it follow a "Here are the majority of options
for the
widest range of users" design?
a. With proper documentation which includes examples, are you
comfortable with exposing API's for anyone that doesn't want to use the
built-in UI so they can interface using a different UI?
Quite a few users interact with the Motion application via the web
interface api (previously via the GET commands). The default web page
interface itself doesn't need to show all the parameters but I think that
the API would need to handle all of them. The web control/interface page
also needs to be optional and have an option that does not rely upon any
external resources/libraries. i.e. It retrieves *nothing* from the
internet/web to work.
2. The POST, What is the purpose of this? An easy connection for custom
built UI or connecting to Motion externally?
Updating a parameter, pausing/starting detection, checking whether
detection is running, starting a recording, getting a snapshot, working a
timelapse, etc. All this may be just by the user's own curl scripts/cron
jobs, etc or perhaps their own web page they built. The JSON may be easier,
I haven't tried it. I was just thinking of keeping the post to not change
too much from what was in place before as well as still giving them the
option of the previous standalone isolated web control page.
Regarding the M4 problem (number 2). It is resolved by adding a new
dependency for autoconf-archive . Once that is installed, the error
message goes away and the make cleanall doesn't need to get adjusted.
2. Keep the Pi scripts if Pi is detected, but ensure it is modular.
This
can be used as an example for adding scripting fields for other
devices as
well (ex. Arduino, trigger Python scripts, etc).
Yea, I'm not sure I'm going to be persuaded on including PI scripts.
Motion is packaged with Debian and therefore it will come with RapsiOS.
Motion is also deployed across a variety of other platforms. I've had my
experience of trying to include various OS builds and its just not worth
the effort. e.g. I'm not going to creating and maintaining scripts for my
PI zero, my PI2, the next PI6, the Arduino, the OrangePi, the PIs running
BSD, the Suse servers, the Macs, Rocky, the....(you get the point)
I do have lots of other comments and changes that I'd want before it goes
to master (I'm guessing some of them may not be what you'd want such as the
PI scripts). I'm thinking we may just want to implement a few changes and
then pull it into the 5.0 branch with your changes all intact and then
revise from there.
—
Reply to this email directly, view it on GitHub
<#1941 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BRF2C6FRFAPEBUZQIX2S2X34I6525AVCNFSM6AAAAACSXZ65USVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQMBXGE3TQNRUGU>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Major feature release adding a modern React-based web UI and numerous backend improvements:
Key Changes
Frontend (React)
Backend (C++)
Infrastructure
Test plan
🤖 Generated with Claude Code