[Config Support]: Yet another Reolink door bell user (sorry!)

[bobmarley2021]

Describe the problem you are having

Hi, having read through what seems like tens of Reolink doorbell issues and tutorials on the web, I'm going to have to admit defeat on this one and ask for help with my config.

I initially had just video working with just RTSP - and this worked well with person detection. I wanted audio support in the video clips, however, and this is where I am coming unstuck.

go2rtc version is way beyond 1.2 (a problematic version for audio with this door bell from what I can tell) and there doesn't appear to be anything damning in the logs. I've obviously made a config error but I can't see it....

Docker is running in an LXC on Proxmox, Coral and SSD passed through. Coral is detected.

Problems: events page void of events, cameras page shows no frames received, recordings seem to only be randomly recording 1m clips

Aim: 24/7 recording, event (person, dog, cat, etc) recording - with audio :)

Version

Frtigate: 0.13.2-6476f8a, go2rtc: go2rtc 1.8.4

Frigate config file

mqtt:
  enabled: False

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


detectors:
  coral:
    type: edgetpu
    device: usb

detect:
  enabled: True
  width: 640
  height: 480
  fps: 5

objects:
  track:
    - person
    - dog
    - cat
    - bicycle

rtmp:
  enabled: false

record:
  enabled: True
  retain:
    days: 14
    mode: motion
  events:
    retain:
      default: 28
      mode: active_objects

snapshots:
  enabled: true
  clean_copy: true
  retain:
    default:  14

birdseye:
  width: 1920
  height: 1080
  restream: true

go2rtc:
    streams:
      doorbell_main:
        - "ffmpeg:http://192.168.x.x/flv?port=1935&app=bcs&stream=channel0_ext.bcs&user=xxx&password=xxx!#video=copy#audio=copy#audio=opus"
        - rtsp://xxx:[email protected]:554/h264Preview_01_main
      doorbell_sub:
        - rtsp://xxx:[email protected]:554/h264Preview_01_sub

cameras:
  doorbell:
    enabled: true
    ffmpeg:
      hwaccel_args: preset-vaapi
      inputs:
        - path: rtsp://127.0.0.1:8554/doorbell_main?video=copy&audio=aac
          input_args: preset-rtsp-restream
          roles:
            - record
        - path: rtsp://xxx:[email protected]:554/h264Preview_01_sub
          roles:
            - detect
    live:
      stream_name: doorbell


logger:
  logs:
    frigate.record: debug
    level: debug
    rtsp: debug
    streams: debug

Docker compose

version: "3.9"
services:
  frigate:
    container_name: frigate
    privileged: true # this may not be necessary for all setups
    restart: unless-stopped
    image: ghcr.io/blakeblackshear/frigate:stable
    shm_size: "128mb"
    devices:
      - /dev/bus/usb:/dev/bus/usb  # Passes the USB Coral, needs to be modified for other versions
      - /dev/dri/renderD128:/dev/dri/renderD128 # For intel hwaccel, needs to be updated for your hardware
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /opt/frigate/config:/config
      - /mnt/Frigate_SSD:/media/frigate
      - type: tmpfs # Optional: 1GB of memory, reduces SSD/SD Card wear
        target: /tmp/cache
        tmpfs:
          size: 1000000000
    ports:
      - "5000:5000"
      - "8554:8554" # RTSP feeds
      - "8555:8555/tcp" # WebRTC over tcp
      - "8555:8555/udp" # WebRTC over udp
    environment:
      FRIGATE_RTSP_PASSWORD: "xxxxx"

Relevant log output

### FRIAGTE

2024-02-20 03:15:15.046639171  [INFO] Preparing Frigate...
2024-02-20 03:15:15.068252257  [INFO] Starting Frigate...
2024-02-20 03:15:15.628159476  [2024-02-20 03:15:15] frigate.app                    INFO    : Starting Frigate (0.13.2-6476f8a)
2024-02-20 03:15:15.628162786  [2024-02-20 03:15:15] peewee_migrate.logs            INFO    : Starting migrations
2024-02-20 03:15:15.628164086  [2024-02-20 03:15:15] peewee_migrate.logs            INFO    : There is nothing to migrate
2024-02-20 03:15:15.628165228  [2024-02-20 03:15:15] frigate.app                    INFO    : Recording process started: 819
2024-02-20 03:15:15.628171543  [2024-02-20 03:15:15] frigate.app                    INFO    : go2rtc process pid: 90
2024-02-20 03:15:15.635624451  [2024-02-20 03:15:15] frigate.app                    INFO    : Output process started: 829
2024-02-20 03:15:15.644717876  [2024-02-20 03:15:15] frigate.app                    INFO    : Camera processor started for doorbell: 834
2024-02-20 03:15:15.644719784  [2024-02-20 03:15:15] frigate.app                    INFO    : Capture process started for doorbell: 835

### GO2RTC

2024-02-20 03:15:15.046034794  [INFO] Preparing new go2rtc config...
2024-02-20 03:15:15.206080275  [INFO] Starting go2rtc...
2024-02-20 03:15:15.296730846  03:15:15.296 INF go2rtc version 1.8.4 linux/amd64
2024-02-20 03:15:15.297267969  03:15:15.297 INF [rtsp] listen addr=:8554
2024-02-20 03:15:15.297505630  03:15:15.297 INF [api] listen addr=:1984
2024-02-20 03:15:15.297584034  03:15:15.297 INF [webrtc] listen addr=:8555
2024-02-20 03:15:25.047914941  [INFO] Starting go2rtc healthcheck service...

Frigate stats

Not sure how to get this?

Operating system

Proxmox

Install method

Docker Compose

Coral version

USB

Any other information that may be helpful

Door bell is the Wifi version but is ~1M away from an AP the other side of the wall, stats in the UniFi controller show:

Signal -40 dBm
AP/Client Signal Balance Good
Standard WiFi 4
MIMO Configuration 2x2
Rx Rate 300 Mbps
Tx Rate 300 Mbps

More importantly, before I messed with the config, audio-less video was working like a champ :)

I expect this to be a school boy error that's staring me in the face... I'd appreciate any help!

[NickM-27]

let's see a screenshot of the system page

[bobmarley2021]

Sure: screenshot

Interestingly, when I fired up the docker to get the screenshot, I now see this:

2024-02-21 00:20:39.572458824  [2024-02-21 00:20:14] frigate.detectors.plugins.edgetpu_tfl INFO    : Attempting to load TPU as usb
2024-02-21 00:20:39.572462499  [2024-02-21 00:20:39] frigate.detectors.plugins.edgetpu_tfl ERROR   : No EdgeTPU was detected. If you do not have a Coral device yet, you must configure CPU detectors.

This is the first time I have seen this.. a quick Google shows that this is not uncommon (https://community.home-assistant.io/t/frigate-no-edgetpu-was-detected/377111/11), and that the device needs flashing (it only appears with this ID before initial setup? I really don't understand this as it was working perfectly fine last week, I have never performed a flash).... anyhow.... I checked lsusb, and sure enough I have the device shown with the incorrect ID:

Bus 002 Device 003: ID 1a6e:089a Global Unichip Corp. 

I read this: https://williamlam.com/2023/05/google-coral-usb-edge-tpu-accelerator-on-esxi.html
Which lead to this: https://github.com/google-coral/webcoral

Now I see:

Bus 002 Device 006: ID 18d1:9302 Google Inc. 

But when disconnecting from my workstation and reconnecting to Proxmox, I see the original:

Bus 002 Device 003: ID 1a6e:089a Global Unichip Corp. 

Apparently this has to be done on each connect - which would explain why it suddenly stopped working and reset....What a peculiar device!!

The docs say that the firmware update is usually performed automatically by the libedgetpu library, so presumably this should automatically happen when using Frigate... any ideas what to do next?

Edit: Just found the frigate docs re troubleshooting this... I'll report back once everything is run through and tried.

Edit2:

Just posting this for others with Proxmox, as not related to Frigate:

So it seems that the issue is that a recent proxmox update broke gasket-dkms. Apex_0 is not present under /dev

Info:

uname -a
Linux Proxmox 6.5.11-8-pve #1 SMP PREEMPT_DYNAMIC PMX 6.5.11-8 (2024-01-30T12:27Z) x86_64 GNU/Linux

From a Proxmox thread here: https://forum.proxmox.com/threads/update-error-with-coral-tpu-drivers.136888/

apt remove gasket-dkms
apt install dkms lsb-release sudo git dh-dkms devscripts pve-headers
git clone https://github.com/google/gasket-driver.git
cd gasket-driver/
debuild -us -uc -tc -b
cd ..
dpkg -i gasket-dkms_1.0-18_all.deb

Now I see:

lsmod | grep apex
apex                   28672  0
gasket                126976  1 apex

~ # dmesg | grep gasket
[  206.236943] gasket: module verification failed: signature and/or required key missing - tainting kernel

As per here: google/gasket-driver#19 secure boot is not enabled. Whilst it is supported in Proxmox 8.1 out the box, this is not a fresh 8.1 install.

I haven't been able to resolve this yet.

Edit3:

Well tbh, this Coral is starting to get on my nerves.

I have:

1. Reverted to kernel 6.2.16-20-pve
2. Built gasket-dkms from source using: https://github.com/google/gasket-driver/
3. I see the results:

lsmod | grep gasket
gasket                135168  1 apex

Supposedly this is the solution everyone else is using?

But still no Apex_0:

cd /dev/apex*
zsh: no matches found: /dev/apex*

~ # cd /dev/Apex*
zsh: no matches found: /dev/Apex*

// on soap box

This really is a rather nasty product with extremely poor support from Google. When they get it wrong they really do get it very wrong. Even the way the firmware is handled with this thing is the most ridiculous idea. Whoever approved that at design stage needs sacking. Increased wear on the chip and the possibility of changing dev IDs? Idiots. Complete idiots. If the Coral didn't whip the pants off everything else, I would be returning it right now. I am at a loss as to what to try next. I suspect this is probably the entire cause of the sudden issues I have with my Frigate, but I am at a total loss now as to how I fix them!

// off soap box

Edit4:

Now I can't even get the device detected by webcoral on my workstation. Starting to wonder if the damn thing is faulty!

Edit5: Replacement ordered. I can find examples of users with faulty units that never initialise and get 'stuck' on 1a6e:089a.

Best case it fixes this, worst case I will have 2 in tandem when this is finally resolved. I will post back again when it arrives!

[bobmarley2021]

Right... I've got it detected again - I'm still not sure if this original one is faulty, it's now getting very hot. I will compare to the new one when it gets here. This has been an absolute PITA to say the very least. I have wasted hours on this, and probably shaved a few years off my life! 😆

I even considered running in a VM instead of an LXC following this, but I would not have room in this HP Mini for another GPU to pass through.

Anyway, it looks like the gist of it is:

1. Remove gasket-dkms
2. Pin kernel 6.2.16-20-pve
3. Use google repo:

echo "deb https://packages.cloud.google.com/apt coral-edgetpu-stable main" | tee /etc/apt/sources.list.d/coral-edgetpu.list
curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
apt-get update
apt-get install libedgetpu1-std

4. Do a make reset on the host - see below

I noticed in the docs that I never should have /dev/apex_x as this is for PCI. I was still scratching my head as to why it wasn't initialising so I did something I didn't really want to do and grabbed build tools and did a make reset with it plugged into the Proxmox host. After rebooting, I noticed the Google Inc device, and now when I hotplug I see the device change from Unichip to Google after about ~15 seconds. 🥳 🎉

So... I'm going to have a play with my config now, and I'll post back if I continue to have issues. Hopefully all the above information helps others in the same situation.

[bobmarley2021]

So having now tested this for 10 or so days. I think this can be closed. The replacement Coral runs WAY cooler than the original, so I will warranty the faulty one. It would seem that this issue was caused by a fault that resulted in the device not getting flashed on connection. This was resolved as mentioned above, but judging by how hot it was getting - I'm guessing it could fail again if left.

Whilst my fault for not noticing the Coral was not being detected until posting here, it would be helpful if the Frigate interface could make this more obvious. When checking the system page, it did at first glance appear that there was some connection to the Coral as there were some metrics shown there - perhaps a red banner across the top of that panel with NOT DETECTED could be helpful? I am still not sure why the original logs when I first opened this didn't show that the TPU wasn't connected? Perhaps the fault was intermittent.

Anyway, I hope this information helps others in the same situation.