Login

u/An0n_666

r/frigate_nvr r/homeassistant
Home Assistant Security Visibility
▲ 28 r/homeassistant

Home Assistant Security Visibility

Hello fellow nerds,

I’m sure I’m not alone thinking Home Assistant has a bit of a security visibility gap.

Whether you use Nabu Casa, a VPN/tunnel, or a reverse proxy, many of us access Home Assistant over the internet. Some approaches are safer than others, but regardless of how you access your instance, I think one thing is missing:

Visibility into who actually has access, where they’re connecting from, and what they’re doing.

This has come up in the Home Assistant Community and Reddit. I’ve personally made requests for it in the past.

The Open Home Foundation has obviously been adding security features to Home Assistant, but there are a million other things competing for their time.

So I built something for myself:

HA Security

My goal is to provide better visibility into user authentication and user activity:

  • Real time visibility into authenticated connections (via Websocket monitoring)
  • Historical session/connection information by user account
  • Source IP address
  • Credential/refresh-token metadata
  • Client information where Home Assistant exposes it
  • Connection/login timestamps
  • Optional GeoIP/ASN/hostname information
  • Successful login observation
  • Failed password/MFA attempt observation
  • User-attributed Home Assistant service-call auditing
  • Credential and IP history
  • Basic, explainable security assessments

In order to highlight items to review, the integration looks at events and flags specific ones like:

  • Repeated failed authentication attempts followed by a successful login
  • A successful login using both a new credential and an unfamiliar public IP
  • New credentials, IP addresses, or clients being observed for an account

It's absolutely not perfect, and it's definitely not a finished product, but this should hopefully help out someone else who is looking for better visibility on their accounts/security within Home Assistant.

AI had a heavy hand to get this to the point it's at today.

Let me know your thoughts. Would love to know what the world thinks of something like this.

If you have an idea for it, submit a PR or start a discussion on the repo.

My future goal is to enable token revoking via the dashboard/service calls, account disabling, and more. Giving more control over authentication rather than just visibility.
This got me to my MVP goal, but I think there is a lot more possibility to come!

u/An0n_666 — 7 days ago
▲ 11 r/frigate_nvr

Reolink Doorbell Two-Way Talk - Help

I'm at a loss. I've been digging through the Frigate docs, and I can't seem to land on a good configuration for my Reolink Video Doorbell (WiFi).

Some information to preface this:

  • I'm rather comfortable with Frigate configs, but am not an expert.
  • Video streaming is not new to me, I understand most of it, but there is still a lot to learn (hence why I am here 😄)
  • My Reolink Video Doorbell Camera stream configs: https://imgur.com/a/e9Gnl0P

I have tried all the configurations, but what I have found is that the "recommended" Go2RTC stream options from Frigate for Reolink cameras using ffmpeg:http produces a significant 300-800ms+ audio drift.
Using a standard RTSP stream, the audio drift is very minimal and usable.

So, I've used standard RTSP for my main live/recording stream consistently, and this works well.
I use the HTTP stream for the sub-stream for detection, and this also works well.

When I was trying to introduce Two-Way into the mix, things got messy.

At first, I followed what was suggested within the docs "To use the Reolink Doorbell with two way talk, you should use the recommended Reolink configuration"

However, this returned me back to my first issue of using the http stream causes a massive audio delay.
(Also, side note, I think the docs reference the "recommended" stream wrong as it ends the stream link with "...#audio=copy#audio=opus", would this not cause a re-encoding of copied audio for no reason? Maybe I'm missing something?)

Since this did not work for me, I resorted to just using the RTSP stream (no separate two-way stream at this time), and it obviously messed with my recordings during any two-way talk sessions causing corruptions (as you could expect).

So, I have tried multiple stream configurations, I've also tried creating a completely separate two-way talk stream to use exclusively for live-view and two-way, while leaving the "main" used for only recording.

My current issue is that no matter what configuration I try, I either end up with corrupted recordings, huge recording/live audio drift, or (at present with the current config (below) no returned audio when using two-way talk.

To note, I'm using the two-way talk feature exclusively within Frigate web UI at this time. I am not using the Advanced Camera Card in HA, trying to keep this all contained within Frigate for high spouse approval.

I'm looking for anyone who has a working setup with the Reolink doorbell + two-way, or anyone who knows more about video/audio streaming and restreaming than I do to please help me get this to a working state.
I'd love to be able to use this functionality reliably within Frigate directly.

Thank you in advance. Please see my current config, plus a bunch of commented-out stream settings with notes on why they didn't work for me.

########################################################### DOORBELL #########################################################################################################         
  doorbell:
    ffmpeg:
      inputs:
        - path: rtsp://127.0.0.1:8554/doorbell_sub
          input_args: preset-rtsp-restream
          roles:
            - detect
        - path: rtsp://127.0.0.1:8554/doorbell
          input_args: preset-rtsp-restream
          roles:
            - record
      output_args:
        record: preset-record-generic-audio-aac
    live:
      streams:
        main: doorbell
        two-way: doorbell_2way
    detect:
      width: 640
      height: 480
      fps: 8
    record:
      enabled: true
      alerts:
        retain:
          days: 5
        pre_capture: 30
        post_capture: 60
      detections:
        retain:
          days: 5
      continuous:
        days: 5
      motion:
        days: 0
    snapshots:
      enabled: true
      retain:
        default: 5
    zones:
      walkway:
        coordinates: 0.396,0.621,0,1,0.824,1,0.489,0.627
        inertia: 3
        loitering_time: 0
    objects:
      track:
        - person
        - dog
    review:
      alerts:
        required_zones: walkway
    motion:
      mask: 0.272,0,0.267,0.076,0.713,0.067,0.715,0
go2rtc:
  streams:
 ############################ DOORBELL ############################
    doorbell:
      - rtsp://USR:PASS@192.168.0.141:554/h264Preview_01_main #used for main & two way talk. Works fine for main, using for Two-way causes recording interruption.
      #- ffmpeg:http://192.168.0.141/flv?port=1935&app=bcs&stream=channel0_main.bcs&user=USR&password=PASS#backchannel=0 # recommended Reolink method - huge audio lag 
      #- "ffmpeg:rtsp://USR:PASS@192.168.0.141:554/h264Preview_01_main#audio=pcm#video=copy" # Intended use should prevent audio drift, but was glitchy
	  
    doorbell_2way:
      - ffmpeg:http://192.168.0.141/flv?port=1935&app=bcs&stream=channel0_main.bcs&user=USR&password=PASS#video=copy#audio=opus # Was working, but had a 300-800ms audio drift
      #- rtsp://USR:PASS@192.168.0.141:554/h264Preview_01_main #used for two way talk. No audio returned

    doorbell_sub:
      #- rtsp://USR:PASS@192.168.0.141:554/h264Preview_01_sub # used in two way talk. Seemed to work
      #- "ffmpeg:rtsp://USR:PASS@192.168.0.141:554/h264Preview_01_sub#audio=pcm#video=copy" # Intended use should prevent audio drift, but was glitchy 
      - ffmpeg:http://192.168.0.141/flv?port=1935&app=bcs&stream=channel0_ext.bcs&user=USR&password=PASS#backchannel=0 # Was working, but had a 300-800ms audio drift
reddit.com
u/An0n_666 — 4 months ago