Nest Cam -> Frigate (Integrated go2rtc) Setup Workflow

[jshank]

I went through the full workflow of getting a few of my newer nest cameras working in Frigate through go2rtc. It seems like this process changes quite frequently but here it is, tested and working, as of today.

Nest Cam -> Frigate (Integrated go2rtc) Setup Workflow

Goal: To stream supported Nest cameras (2021+ models) locally using the go2rtc instance integrated within Frigate, authenticating via the Google SDM API, and feeding this stream into Frigate NVR for recording and object detection. This guide assumes Frigate (with go2rtc) is run via Docker/Docker Compose.

Tip

If any of these URLs aren't working, check https://developers.google.com/nest/device-access/authorize for guidance on where to place variables and which values to copy back out.

Phase 1: Prerequisites

1. Supported Nest Camera: Ensure you have a newer (2021+) Nest Cam model (wired/battery/floodlight) or Nest Doorbell (battery). Nest Cam IQ and older models are not supported by this method.
2. Google Account: The account used to manage your Nest devices in the Google Home app.
3. Frigate Instance with Integrated go2rtc: Running Frigate version that includes go2rtc (e.g., via Docker).
4. NAS/Storage (Optional): For Frigate recordings.
5. $5 USD: For the one-time Google Device Access registration fee.
6. Command Line Access: Terminal with curl installed.

Phase 2: Google Cloud & Device Access Setup

1. Google Cloud Project: Create one at console.cloud.google.com.
2. Enable API: In your Cloud Project, go to "APIs & Services" -> "Library" -> search for and enable "Smart Device Management API".
3. OAuth Consent Screen: Go to "APIs & Services" -> "OAuth consent screen".
   • User Type: External.
   • Fill in App name (e.g., "Frigate-go2rtc Nest"), support email, developer contact.
   • Skip Scopes section for now.
   • Add your Google account email as a Test user.
   • Save the consent screen config.
4. OAuth Client ID: Go to "APIs & Services" -> "Credentials".
   • Click "+ CREATE CREDENTIALS" -> "OAuth client ID".
   • Application type: Web application.
   • Name: e.g., "Frigate-go2rtc Nest Web Client".
   • Authorized redirect URIs: Add https://www.google.com (This is used for the OOB flow to get the authorization code).
   • Click "Create".
   • Immediately copy and securely save the displayed Client ID and Client Secret.
5. Device Access Project: Go to the Google Device Access Console.
   • Create a new project, link it to your Google Cloud Project.
   • Enter the Client ID you just created.
   • Pay the $5 USD fee.
   • Copy and securely save the Device Access Project ID displayed.
6. Set Publishing Status to Production (IMPORTANT for Token Longevity):
   • Go back to the "APIs & Services" -> "OAuth consent screen" page in the Google Cloud Console for your project.
   • Find the "Publishing status" section (you mentioned this might be grouped under a section like "Audience"). It will likely say "Testing".
   • Click the button labeled "Publish App".
   • Confirm the action when prompted.
   • Note: For personal use with the SDM API accessing only your own device data, full Google app verification is typically not required. Simply changing the status to "In production" removes the 7-day expiry limit on refresh tokens.

Phase 3: Authorization (Getting the Refresh Token)

1. Construct Auth URL: Create this URL, replacing placeholders with your values:

https://nestservices.google.com/partnerconnections/YOUR_DEVICE_ACCESS_PROJECT_ID/auth?redirect_uri=https://www.google.com&access_type=offline&prompt=consent&client_id=YOUR_OAUTH_CLIENT_ID&response_type=code&scope=https://www.googleapis.com/auth/sdm.service

2. User Consent: Paste the constructed URL into your browser. Log in with the Google account managing your Nest devices. Approve the access request from your app (e.g., "Frigate-go2rtc Nest").
3. Capture Authorization Code: Your browser will redirect to google.com. The URL in the address bar will now contain ?code=4/0A...SOME_LONG_CODE...&scope=.... Copy the code value (everything between code= and &scope). This code is short-lived.
4. Exchange Code for Refresh Token: Immediately run this curl command in your terminal, replacing placeholders:

   curl -L -X POST 'https://www.googleapis.com/oauth2/v4/token' \
   -d 'client_id=YOUR_OAUTH_CLIENT_ID' \
   -d 'client_secret=YOUR_OAUTH_CLIENT_SECRET' \
   -d 'code=THE_AUTHORIZATION_CODE_YOU_COPIED' \
   -d 'grant_type=authorization_code' \
   -d 'redirect_uri=https://www.google.com'

5. Save Refresh Token: The JSON output will contain a refresh_token. Copy and securely save this refresh_token. This is the long-term credential go2rtc will use.

Phase 4: Getting Camera Device IDs

1. Get Access Token (Temporary): Run this curl command, replacing placeholders with your credentials:

   curl -L -X POST 'https://www.googleapis.com/oauth2/v4/token' \
   -d 'client_id=YOUR_OAUTH_CLIENT_ID' \
   -d 'client_secret=YOUR_OAUTH_CLIENT_SECRET' \
   -d 'refresh_token=THE_REFRESH_TOKEN_YOU_SAVED' \
   -d 'grant_type=refresh_token'

   Copy the access_token value from the JSON output.
2. List Devices: Run this curl command, replacing placeholders:

   curl -X GET 'https://smartdevicemanagement.googleapis.com/v1/enterprises/YOUR_DEVICE_ACCESS_PROJECT_ID/devices' \
   --header 'Content-Type: application/json' \
   --header 'Authorization: Bearer YOUR_ACCESS_TOKEN'

3. Identify Device IDs: Parse the JSON output. Look for the devices list. For each camera:
   • Find the parentRelations[0].displayName (e.g., "Front Room").
   • Find the corresponding name field (enterprises/.../devices/AVPH...).
   • The Device ID is the long AVPH... string at the end of the name. Copy and save the specific ID for each camera you want to stream.

Phase 5: Environment Variable Setup (Docker Compose - Frigate Service)

• Define the credentials and IDs as environment variables for your Frigate container (since go2rtc runs inside it). Add these to the environment: section of your Frigate service in docker-compose.yaml or define them in an .env file used by it. Make sure variable names exactly match those used in your Frigate config.yml (must include prefix of FRIGATE_). Frigate typically handles substitution for these variables within its config.yml.

  # Example within docker-compose.yaml for the Frigate service
  services:
    frigate:
      container_name: frigate
      image: ghcr.io/blakeblackshear/frigate:stable # Or your preferred version
      restart: unless-stopped
      privileged: true # Often needed for hardware acceleration
      # ... other frigate settings (volumes, devices, etc.) ...
      volumes:
        - /etc/localtime:/etc/localtime:ro
        - ./config:/config # Map main config directory
        - type: tmpfs # Optional: for clips in memory
          target: /tmp/cache
          tmpfs:
            size: 1000000000
      ports:
        - "5000:5000" # Frigate Web UI
        - "1984:1984" # go2rtc Web UI (if exposed by Frigate)
        - "8554:8554" # RTSP (if exposed by Frigate)
        - "8555:8555" # WebRTC (if exposed by Frigate)
      environment:
        # Define all variables needed by the go2rtc streams config below
        FRIGATE_NEST_OAUTH_CLIENT_ID: 'YOUR_OAUTH_CLIENT_ID'
        FRIGATE_NEST_OAUTH_CLIENT_SECRET: 'YOUR_OAUTH_CLIENT_SECRET'
        FRIGATE_NEST_DEVICE_REFRESH_TOKEN: 'THE_REFRESH_TOKEN_YOU_SAVED'
        FRIGATE_NEST_DEVICE_ACCESS_PROJECT_ID: 'YOUR_DEVICE_ACCESS_PROJECT_ID'
        FRIGATE_NEST_CAMERA_ID_FRONT_ROOM: 'AVPH...ID_FOR_FRONT_ROOM_CAM...'
        # Add variables for other cameras if needed
        # FRIGATE_NEST_CAMERA_ID_BACK_YARD: 'AVPH...ID_FOR_BACK_YARD_CAM...'
        # ... other Frigate environment variables ...

Phase 6: Frigate Configuration (config.yml including go2rtc Streams)

• Edit your Frigate config.yml (e.g., ./config/config.yml).
• Define the go2rtc streams directly under the top-level go2rtc: key.
• Reference the environment variables defined in Phase 5 using the {FRIGATE_VAR} syntax.
• Define your cameras under the cameras: key, pointing the input path to the internal go2rtc RTSP stream (rtsp://127.0.0.1:8554/...).

  # Example contents of Frigate config.yml
  
  # MQTT, Database, Detectors, etc. settings go here
  # ...
  
  # Define go2rtc streams directly in Frigate config
  go2rtc:
    streams:
      # Name for the stream (used in RTSP URL below)
      front_room_nest:
        - nest:?client_id={FRIGATE_NEST_OAUTH_CLIENT_ID}&client_secret={FRIGATE_NEST_OAUTH_CLIENT_SECRET}&refresh_token={FRIGATE_NEST_DEVICE_REFRESH_TOKEN}&project_id={FRIGATE_NEST_DEVICE_ACCESS_PROJECT_ID}&device_id={FRIGATE_NEST_CAMERA_ID_FRONT_ROOM}
  
      # Example for another camera
      # back_yard_nest:
      #   - nest:?client_id={FRIGATE_NEST_OAUTH_CLIENT_ID}&client_secret={FRIGATE_NEST_OAUTH_CLIENT_SECRET}&refresh_token={FRIGATE_NEST_DEVICE_REFRESH_TOKEN}&project_id={FRIGATE_NEST_DEVICE_ACCESS_PROJECT_ID}&device_id={FRIGATE_NEST_CAMERA_ID_BACK_YARD}
  
    # Optional: Add other go2rtc settings if needed
    # rtsp:
    #   listen: ":8554" # Usually handled automatically by Frigate
  
  # Define Frigate cameras
  cameras:
    # Name for the camera within Frigate
    nest_front_room:
      ffmpeg:
        inputs:
          # Use go2rtc stream name defined above in go2rtc.streams
          # Point to localhost (127.0.0.1) because go2rtc runs inside the Frigate container
          - path: rtsp://127.0.0.1:8554/front_room_nest
            roles:
              - detect
              - record # Or clips
      detect:
        enabled: True
        # ... your detection settings ...
      record:
        enabled: True
        # ... your recording settings ...
  
    # Define other cameras here...
  
  # Other Frigate settings (Recordings, Birdseye, etc.)
  # ...

Phase 7: Running and Testing

1. (Re)start your Frigate container: docker-compose up -d (or however you manage your containers).
2. Check Frigate/go2rtc Logs: Look for successful connection messages related to the Nest stream(s) in the Frigate container logs. Access the go2rtc Web UI (often via Frigate's UI or port 1984 if exposed) to check stream status under the "Streams" tab.
3. Test Frigate Stream: Verify the camera feed (nest_front_room) appears in the Frigate UI ("Cameras" section) and that detection/recording is working as expected.
4. Optional Direct RTSP Test: If you exposed port 8554 from the Frigate container, you could try accessing rtsp://<frigate-ip>:8554/front_room_nest with VLC, but accessing via Frigate is the primary goal.

[jshank]

I just updated to include the publishing step, required to get your token to last more than 7-days (mine expired). This should produce a long-lived refresh token that lasts indefinitely.

Regarding the lifespan of the long-lived refresh token you get after setting your Google Cloud OAuth app to "In production":

Google doesn't publish a specific, fixed maximum expiration date (like "this token will expire in exactly 1 year") for these production refresh tokens.

Here's the general understanding:

1. Long-Lived: They are designed to be long-lived and do not have the automatic 7-day expiry that "Testing" app tokens have.
2. No Fixed Time-Based Expiry (Usually): As long as the token is being used periodically, it generally won't expire simply due to old age.
3. Inactivity Expiry: Google policies often state that a refresh token might expire if it remains completely unused for an extended period, typically around 6 months. However, since go2rtc needs to use the refresh token regularly (roughly every hour) to get new short-lived access tokens, this inactivity expiry should not apply to your active setup.
4. Revocation: While they don't typically "expire" based on time when actively used, they can become invalid if they are revoked. Common reasons for revocation include:
   • You manually revoke the application's access in your Google Account security settings.
   • You change your Google account password (this sometimes triggers revocation).
   • The token remains unused for an extended period (Google policies might expire inactive tokens, often after months).
   • Your Google Cloud project or Device Access project is deleted or significantly changed.
   • Major security policy changes by Google.

In practice: For your go2rtc setup with a published app, you can expect the refresh token to last indefinitely unless one of the revocation events occurs. You shouldn't need to manually regenerate it on a regular schedule like you did when it was expiring weekly.

[Hockilliona1re]

Hey mate, i've followed your guide all the way up to --> Phase 4: Getting Camera Device IDs --> 2. List Devices: Run this curl command, replacing placeholders.... And when i put the command i just get this prompt (in the photo). Any ideas (ive spent 3 hours trying random things - not super code/tech savvy).

Notes: I've been using Terminal on my Macbook as CMD in Windows doesnt seem to want to do alot of the commands. Also i had to edit the scripts you had to include -globoff after the url's

(i saw this suggestion on another post elsewhere) as without it i couldnt get the previous scripts to run in terminal as i was getting a "curl: (3) bad range in URL position 2:" response.

Thanks in advance.

[jshank]

I've fixed the instructions in the post. Apparently my markdown editor got overzeolous and tried to escape all of the URLs. I see that one of the errant [ made it into your command. Try this one:

curl -X GET 'https://smartdevicemanagement.googleapis.com/v1/enterprises/YOUR_DEVICE_ACCESS_PROJECT_ID' --header 'Content-Type: application/json' --header 'Authorization: Bearer YOUR_ACCESS_TOKEN'

[ampersandru]

got it working thanks to your guide, however, I got nonstop errors until I added &protocols=WEB_RTC&video=h264&audio=opus at the end of the go2rtc command and also add ffmpeg input_args to the cameras. This is the 2nd gen doorbell wired and nest floodlight.

  door:
    enabled: true
    ffmpeg:
      inputs:
        - path: rtsp://127.0.0.1:8554/door
          input_args: # <--- THIS IS THE CORRECT PLACE for FFmpeg input options
            - -rtsp_transport
            - tcp
            # Explicit VAAPI hardware acceleration for decoding
            - -hwaccel
            - vaapi
            - -hwaccel_device
            - /dev/dri/renderD129 # <--- VERIFY THIS PATH AND CONTAINER PASSTHROUGH
            - -hwaccel_output_format
            - vaapi
          roles:
            - detect
            - record
            - audio
    detect:
      enabled: true
    record:
      enabled: true

[mankot14]

Are you able to hear audio from your Nest Doorbell Wired (2nd gen)? I'm not having any luck using these settings...

[rsiv]

Try adding the following in your camera ffmpeg config -- recordings need AAC but Nest provides Opus:

    ffmpeg:
      output_args:
        record: preset-record-generic-audio-aac

[DanubeRS]

I am happy to report that I have successfully configured the Nest integration with 0.16b3 and have had moderate success.

One thing I have noticed is that the incoming WebRTC stream occasionally has a "huccup" and reconfigures itself, which I think is the cause for the issues surrounding corrupted frames and streams (see an example of my screenshot below)

These corrupted frames seem much more prevalent in the detect streams (converted to mjpeg), but have noticed that the recordings also produce it, as well as if I use ffplay directly on the go2rtc output of the nest:... stream

My current approach (which is still a work in progress) involves an intermediate exec:ffmpeg... as a sanitisation stream that applies filters, performs slight buffering, and implements other stability improvements. It's been a journey so far, and I would like to extend my gratitude to Grok and Claude for their guidance. I also want to document my progress along the way and the thought process that led to it, in case the community has any suggestions or viable configurations.

For now, I have been experimenting with the following as a part of a larger transcode and transform:

• -fflags nobuffer+discardcorrupt -flags low_delay -err_detect ignore_err - Used to detect corrupt frames and discard, as well as ignore any errors during the decoding process
• -vf "format=yuv420p,scale=1920:1080,tpad=stop=-1:stop_mode=clone" - Used to force to 1080 HD; sometimes the cameras will re-init as a strange intermediate resolution and format for a handful of frames before being reconfigured again back to the standard stream. This might be a bug or quirk of the WebRTC stream. I also pad out any missing frames with the last known good frame. Ideally, I would like to limit this to only a few, and only to interpolate if there is a corrupt frame or two
• -buffer_size 4096 -max_delay 100000 - Reducing the input buffer (still experimenting) while disabling the mux buffer. Still foggy on this
• I have been experiencing audio drift and have yet to come up with a solution. It seems as if the audio stream starts a few seconds before the video feed, and we want to ensure that the PTS of each line up correctly

I'll leave it here for now; I've done a clean frigate install and will continue to experiment to see what I can get to stick.

I will also add that I will be using this sanitised stream as a basis for all Frigate roles, with the record passing off to an A380 for tuned QSV encoding to either HEVC or AV1. This has posed its challenges, but so far, it seems to be a solved problem based on my testing, provided the issues with input stream stability can be resolved.

EDIT:
My current command (in the go2rtc config) is as follows, and is working quite nicely over the past half hour.

    office:
      - nest:?client_id={FRIGATE_NEST_OAUTH_CLIENT_ID}&client_secret={FRIGATE_NEST_OAUTH_CLIENT_SECRET}&refresh_token={FRIGATE_NEST_DEVICE_REFRESH_TOKEN}&project_id={FRIGATE_NEST_DEVICE_ACCESS_PROJECT_ID}&device_id={FRIGATE_NEST_CAMERA_ID_OFFICE}&protocols=WEB_RTC&video=h264&audio=opus
    office_re:
      - exec:/usr/lib/ffmpeg/7.0/bin/ffmpeg 
        -hide_banner -fflags nobuffer+discardcorrupt 
        -qsv_device /dev/dri/renderD129
        -err_detect ignore_err -flags low_delay 
        -rtsp_transport tcp -i "rtsp://127.0.0.1:8554/office"
        -vf "format=yuv420p,scale=1920:1080:flags=fast_bilinear,tpad=stop=-1:stop_mode=clone"
        -c:v h264_qsv -preset veryfast -tune zerolatency -b:v 5M -g 15 -bf 0 -refs 1 -look_ahead 0 -async_depth 1 -low_power 1 -rdo 0 -mbbrc 0 
        -c:a libopus -b:a 128k -application lowdelay -frame_duration 5
        -af "aresample=async=1" 
        -fps_mode vfr -async 1 -f rtsp -rtsp_transport tcp -flush_packets
        1 {{output}}

Command is a little messy, but will clean up and report back once I get some more confidence that it performs well.

[amritsinghbains]

this documentation helps! As I am new to frigate I didn't know the requirements of config.yml like mqtt, you can include that in your documentation

mqtt:
enabled: false

I was wondering since it uses a lot of data from google nest camera, hopefully I won't be charged as the video seems to be online all the time?

[michaelarnauts]

It took a while to figure this out, but the latest go2rtc (1.9.9) now also support 1st gen nest doorbell devices (that only do RTSP).

See AlexxIT/go2rtc#1253

Make sure to put the newer go2rtc binary in the configuration folder, since the one integrated with frigate is still older.

You need to follow all the steps above, but you'll need to add &protocols=RTSP to the nest: URI.

I also replaced the / symbols with %2F in my refresh token.

[markh07]

Super helpful! Got it working without any issues. Waiting for my Coral to arrive and will continue with the setup of the rest after.

[rsiv]

Awesome work detailing all the steps!
Can confirm that my 1st gen wired Nest Doorbell works with this setup once I migrated it from Nest to the Google Home app.

Before migration, list devices API from phase 4 returned:

"type": "sdm.devices.types.DOORBELL",
"traits": {
  "sdm.devices.traits.Info": {
    "customName": ""
  },
  "sdm.devices.traits.CameraLiveStream": {
    "maxVideoResolution": {
      "width": 640,
      "height": 480
    },
    "videoCodecs": [
      "H264"
    ],
    "audioCodecs": [
      "AAC"
    ],
    "supportedProtocols": [
      "RTSP"
    ]
  },
  "sdm.devices.traits.CameraImage": {
    "maxImageResolution": {
      "width": 1920,
      "height": 1200
    }
  }
}

After migrating the device to Google home app, go2rtc was able to connect and stream:

"type": "sdm.devices.types.DOORBELL",
"traits": {
  "sdm.devices.traits.Info": {
    "customName": ""
  },
  "sdm.devices.traits.CameraLiveStream": {
    "videoCodecs": [
      "H264"
    ],
    "audioCodecs": [
      "OPUS"
    ],
    "supportedProtocols": [
      "WEB_RTC"
    ]
  },
  "sdm.devices.traits.CameraImage": {
    "maxImageResolution": {
      "width": 1920,
      "height": 1200
    }
  }
}

[MFornander]

I got the go2rtc nest source working but it was glitching a lot with bad data and frames causing ffmpeg to restart and causing the CPU to spike. I also wanted a transcode to make sure the video stream is clean even though the camera already produces an h264 stream. I wanted a hardware transcode and use my NV GPUs to minimize resource use. I synthesized the info in this thread with ps ffmpeg in the frigate container and ffmpeg h264_nvenc docs.

I ended up with this working with close to 0% CPU/GPU overhead looking at nvtop/btop and no glitching looking at my indoor wired Nest Cam(so far):

go2rtc:
  streams:
    nest_garage_raw:
      - nest:?client_id=XXX&client_secret=YYY&refresh_token=ZZZ&project_id=AAA&device_id=BBB
    nest_garage:
      - exec:/usr/lib/ffmpeg/7.0/bin/ffmpeg
        -hide_banner -v error
        -hwaccel cuda -hwaccel_output_format cuda
        -fflags nobuffer -flags low_delay -timeout 5000000
        -user_agent go2rtc/ffmpeg
        -rtsp_flags prefer_tcp
        -i "rtsp://127.0.0.1:8554/nest_garage_raw"
        -vf "fps=5,scale_cuda=w=1280:h=720,hwdownload,format=nv12,eq=gamma=1.4:gamma_weight=0.5"
        -c:v h264_nvenc -g 50 -bf 0 -profile:v high -level:v auto -preset:v p2 -tune:v ll
        -c:a copy
        -user_agent ffmpeg/go2rtc
        -rtsp_transport tcp -f rtsp {{output}}

[DanubeRS]

I'm very interested to see how this compares to my earlier comment; I have since reverted to a plain, raw stream, as I was encountering a whole bunch of PTS/DTS issues. I was also experiencing issues where the HW encoder fell over when the dynamic resolution and bitrate changed, as it broke the filter graph in ffmpeg.

Please let me know if your stream can maintain its quality and if any synchronisation issues arise after being live for a while. This is where my initial config started to show cracks.

[Treintjes]

Can we get a video for start to finish of this for those of us that are not as smart lol

[edse]

Help needed

Backyard1 has high FFmpeg CPU usage (24%)

First thanks so much for the well explained, step-by-step post. I really appreciated it.

Now, is there a way to use a lower resolution stream for the detect to avoid high ffmpeg CPU usage? I'm doing it with my non-nest cameras by just adding a new stream with the "/stream2" to the rtsp url. This gives me a lower resolution feed that I use only for the detection & audio roles.

    backyard2_sub:
      - rtsp://backyard2:[email protected]:554/stream2

Is there a way to do that with a Nest camera? Do they provide a lower res feed?

Hope you guys also have already run into this issue before and found a solution.

[jshank]

Currently, the Google Smart Device Management (SDM) API for Nest cameras does not provide a direct command or parameter within the GenerateWebRtcStream or similar commands (like GenerateRtspStream for legacy devices) to explicitly request a lower resolution stream.

The live stream access commands in the SDM API, such as those related to the CameraLiveStream trait, initiate a session to get a stream from the camera. The stream content and quality are primarily determined by:

1. Camera's Setting: The maximum video quality is set through the Google Home app or Nest app (Low, Medium, High, Max). This setting governs the resolution and bandwidth used by the camera. The camera itself may automatically adjust its resolution and compression based on available bandwidth, even at the highest quality setting.

2. WebRTC Stream Constraints: For WebRTC streams, your SDP offer (Session Description Protocol) can include video constraints, which may influence the stream received. However, the SDM API documentation for the CameraLiveStream trait primarily notes the supported video resolutions as a range (e.g., Minimum: 480p, Maximum: 1080p) but does not expose a parameter in the initial command to force a specific lower resolution.

The API does allow you to customize the resolution when downloading a camera image snapshot using width or height query parameters, but this applies to still images, not live streams.

The camera's behavior, where the live stream may start at a lower resolution and switch to higher quality after a moment, is an automatic feature of the Google Home app and camera software, not an explicit option in the SDM API's streaming commands.

---

You can see an example of changing the video quality using the Nest app interface in this video: How To Change The Video Quality On The Nest Video Doorbell, but that's not a substream per-se, just an overall change of the stream quality and likely not what you're trying to achieve.

MFornander approach seems to be the best way, you generate a lower-res version of the stream and then point frigate at that stream.

[edse]

Yep! It did the trick. Even without a GPU, reducing the resolution of the video used for detection improved the CPU usage. Thanks for the help @jshank.

Here is what I did:

go2rtc:
  streams:
    backyard1:
      - nest:?client_id={FRIGATE_NEST_OAUTH_CLIENT_ID}&client_secret={FRIGATE_NEST_OAUTH_CLIENT_SECRET}&refresh_token={FRIGATE_NEST_DEVICE_REFRESH_TOKEN}&project_id={FRIGATE_NEST_DEVICE_ACCESS_PROJECT_ID}&device_id={FRIGATE_NEST_CAMERA_ID_BACKYARD}&protocols=RTSP
    backyard1_sub:
      - "ffmpeg:backyard1#video=h264#width=1280#height=960#raw=-fpsmax 5"

cameras:
  backyard1:
    enabled: true
    ffmpeg:
      inputs:
        - path: rtsp://127.0.0.1:8554/backyard1?video&audio
          input_args: preset-rtsp-restream
          roles:
            - record
        - path: rtsp://127.0.0.1:8554/backyard1_sub?video&audio
          roles:
            - detect
            - audio
      output_args:
        record: preset-record-generic-audio-aac
    live:
      streams:
        backyard1: backyard1

[TTG24]

Hello,

Phase 3 is truly hurting my brain.
I've followed every single step as slow as I could and still I get this annoying response:

{
  "error": "invalid_grant",
  "error_description": "Malformed auth code."
}

How can I get past this? I even made an entirely new project and it still just doesn't work.
Do I copy the "/" after code=? Do I not? Both don't work either way.

EDIT: Holy after many hours, I finally got it.

I suggest EVERYONE to always come back to this specific page:
https://developers.google.com/nest/device-access/authorize

It seems to be the most direct way of keeping your devices, tokens, etc. up to date.

[jshank]

Thanks for coming back to it. I've added that URL as a tip for folks. Let me know if the placement makes sense.

[keenlearner-404]

I always got "No access to partner" in the phase 3 step 2 User Consent. I have spent 10 hours on this issue.

I have a 3rd gen Nest wired doorbell, which was released on Oct.1st. With many research, I suspect this new model is not supported by SDM API. I hope to hear from other 3rd gen wired owners about their experience.