[Release] Camect Connect

I've spent the last several months (on and off) trying to come up with the "best for me" overall security video solution. Until I started reading about camect, I had pretty much settled on these components...

  • HE (C8 by the time we move into the new home)
  • Scrypted (non-NVR) running on a dedicated rPi to get videos into Apple Home (iPhones, iPads, etc.)
  • All cameras will be POE, with various Reolink cameras being the current plan
  • A dedicated NVR to record the hi-def streams. Was leaning towards Reolink, but backing away from that because I don't want to be tied exclusively to Reolink cameras.
  • Using the recognition features of the Reolink cameras for detection, notifications, etc.

Not sure why I started reading about camect, but it's got me rethinking some of this. I have some camect-specific questions...

  1. How does camect's NVR compare to the typical camera manufacturers' NVR's, e.g., the Reolink NVR's? Is the "feature list" similar? I assume one benefit of the camect NVR is that I wouldn't be limited to the manufacturer's cameras.
  2. Regarding the 24MP limit... I will have some cameras that I want to record but don't want to use detection on them. if I have a 8MP camera that is being recorded in hi-def 24/7, but is not using any detection, how does that affect the 24MP limit? Does it "count" as 8MP towards the 24MP limit, count as something less, or doesn't count at all?
  3. It seems to me that I will have three video stream "consumers", i.e., Scrypted (hi-def), camect for detection (?-def), and the NVR (hi-def, maybe camect-NVR). Is this reasonable for cameras like Reolink, Armcrest, etc.? I suppose there could be some times where I will live view the camera via a browser or camera app, but I doubt that will happen very often if all the other parts work well.
  4. What is the minimum resolution for reasonable detection by camect? The Reolink video doorbell I have looks like it only supports 5MP and 640x480. I will have two of them. It seems like chewing up 10MP (for the two of them) out of the 24MP is a waste for two video doorbells, but is 640x480 good enough to detect something up to 20' away?

I'll take a crack at some of this...

  1. With Camect you can use any camera that supports RTSP or Onvif. I'm a little surprised that this wouldn't be the case with an Reolink NVR too. I think Camect has all the NVR basics but I've never used an Reolink NVR so I can't compare them. It's possible you might prefer the Reolink UI/app to ours. One thing to be aware of is that Camect is designed to prioritize the analytics -- i.e. If you're running close to the limit, you will see the UI responsiveness degrade before the analytics do. Regular NVRs aren't doing analytics in the NVR so are unlikely to have this behavior.

  2. Your 8MP camera will mostly count as 8MP even if you turn off analytics on it. We don't have a "direct to disk" recording w/o touching the video at all, i.e. so the hub has to at least decode and sometimes re-encode the video, and that will take up its share of video encoding/decoding capacity which is one of the resources behind the 24MP "limit".

The 24MP limit is a rule of thumb though, and we say "24MP in normal home security usage" ... i.e. it also matters what the cameras are viewing -- a camera with a lot of activity produces more motion to analyze. The hub will allow you to add up to about 30MP if you want, and some people do things like lower camera frame rates to squeeze more MP in. You need to have at least 5 fps to get good detection, and we'd say stay at 10 or above to be safe.

If you have a bunch of 4K cameras, you should also consider whether it might make the most sense to just run Camect in parallel with a cheap NVR, and let the cheap NVR record in full resolution. For analysis, 1080p or even 720p is good enough for the vast majority of residential cameras.

  1. Most decent cameras can handle 3 video streams. Amcrest in particular should usually be fine with it. I'll let others speak for Reolink.

  2. Detection quality depends on the size in pixels of the object being detected. You'll get great results if the longest dimension of the object (i.e. height for a person, or length for a car) is 100 pixels, and get results of varying quality down to about 50 pixels. In terms of whether 640x480 works at 20', you'll have to also consider the size of what you want to detect, and possibly the angle at which the camera is viewing the subject.

1 Like

A couple of years ago, I set up and successfully ran Rules using the Camect to Hubitat drvers and apps. My Camect NVR would spot movement (via web cam), determine what was moving, and pass that info to the Hubitat to use in Rules. For example, I could have the web cam over my front door porch detect motion, the Camect would determine the motion was a person (not a wasp or a rabbit or etc.), and the Hubitat would turn on the front porch light.

A couple of years have passed and I recently realized the web cam-to-Hubitat-light-control was no longer working. I have updated my Hubitat firmware many times over that period; the Camect/Hubitat linkages (from Brian Wilson, bubba@bubba.org) has only had one very minor update in that time. While I have some notes from when I set it all up, I'm sure I've forgotten all the exact steps.

Since (it appears to me) the firmware changes for the Hubitat "Rules" have undergone the bulk of the updates, it is probably the source of why the Rule no longer works. In trying to debug the issue, I have determined the web cam to Camect are working and passing the info to the Hubitat. The Hubitat "gets" the info, but just doesn't respond to it (turn on the porch light).

In the following screen shots are what I found. Maybe someone can spot what the problem is. All comments and suggestions are appreciated.

Screen shots:
Rule_info
Device_front-porch-virtual_info
Device-log_front-porch
DFevice-log_rule-for-Camect-connect

Notes for screen shots::

  • It took several screen shots to get all the info in several shots; so they're marked *-1, *-2, etc.
  • All of this info was collected a few minutes after walking out onto the porch to (hopefully) trigger the porch light.
  • The porch light is a member of the "Outside front lights" group.

If you need further info or see other tests I should run, please let me know. Thanks!

Joe Henley





It’s hard to say what’s going on with the rule you created from the screenshots, please post a screenshot of the rule itself.

@user2318

I am going to merge this to this thread [Release] Camect Connect as @brianwilson still maintains this.

1 Like

I was limited to only 5 images; relevant rule image is attached now.


Hi
Thanks for response. I was not sure where the problem lies, Camect Connect or Hubitat Rules. My guess is it's in the Rules. But however you folks want to point me is fine. Again, thanks!
Joe Henley

I’m no rule machine expert but I don’t think this rule will behave as intended because of the trigger.

A trigger needs an event to occur. Let’s say your Camect sees a person at 10:01am. That will cause the LastMessage attribute to be updated to read “front porch just saw a person.”

Your rule won’t trigger, because of the time restriction, and that’s fine since you configured it that way.

But if the person walks away, and then Camect sees them again at 10:02am, the rule still won’t trigger.

Why? Because the LastMessage attribute didn’t change.

At 10:01am, it was “front porch just saw a person,” and at 10:02am, it was still “front porch just saw a person.” Even though it was two separate motion events.

If the attribute doesn’t change, no event is generated by the hub, and there is no trigger for the rule to execute.

So the rule might work sometimes, if the last thing Camect saw on the front porch wasn’t a person.

In that case, when it sees a person, the attribute will update, an event will be generated, your rule will trigger (if it’s between 10:02am and 10pm), and the actions will execute.

Does that make sense?

1 Like

Mark,
Thanks for the ideas. Yes, it makes sense. I always thought the "event" was the Camect sending the message (then it was tested to see if it included "person"). But let me test your idea a bit. I'll be back to you.
Joe Henley

I think something like this would do what you want.


Between 10:02am and 10pm, the rule will trigger every time the motion sensor on the Camect virtual device becomes active (i.e. when Camect sees something new), but the actions will execute only when LastMessage contains “person” (i.e. the last thing Camect saw was a person).

Mark,
I recreated your logic on my Hub, see screenshot below. Unfortunately, it doesn't work.
As I recall, the Camect drivers are such that they work as motion detectors, and the need to work around the "triggering" problem was eliminated. One had only to use the Last Message in the trigger (see example that used to work).
So I'm back to wondering where the problem lies. That example above of "that used to work" actually used to work. But no more. I can no reason why. Thus my concern that with all the updates (a good thing) going on with Hubitat, something critical for my Rule logic got "thumped."
Further thoughts appreciated. Also hoping Brian Wilson might weigh in on this.
Thanks!
Joe Henley


I don’t quite follow what you mean by this.

Can you post logs of your new rule when a person walks in front of the camera?

I’m actually on my way home as I write this, so I’m going to test out my version of the rule as I approach my front door.

From what you’ve posted so far, I believe your Camect integration appears to be working as intended.

1 Like

Here's a log of the rule initalizing, triggering with camera motion, but not turning on the lights because the first motion event is a dog; the subsequent motion event is a person (me), so the rule not only triggers, but the actions execute, the lights turn on and turn off five minutes later.

The rule you originally posted won't work consistently, for the reason I explained. But this rule should act this way every time, I think.

What does the Front Yard Cam "Device Information" (on the Device pasge for Front Yard Cam) look like for your set-up?
Joe

Like this:

Mark,
Got some personal issues absobing my time right now. Expect to be back engaging this issue again next week.
Joe Henley

1 Like

Mark,
I've given up on the idea that my approach works. Maybe it did in the past -- doesn't really matter anymore. I re-wrote the half dozen or so rules which use the Camect interface; things seem to work as desired; issue is closed.
THANK YOU for your help with this (and also your patience).
Joe Henley

1 Like

I'm finding that alerts are hit or miss making it from Camect over to Hubitat. From my testing thus far, I've confirmed the alerts are reliably showing up in Camect, but only one or two here and there make it to HE. On the HE side, I'm looking at and refreshing the events tab of the virtual motion device properties to check for updates. I've also tried enabling temporary logging on the HE Camect Connect app and re-tested, but there are no errors reported there either. Any thoughts on where to troubleshoot next?

Try commenting out this line (line 101):
if (state.isDebug) runIn(3600, logsOff)

Then go back into Apps -> Camect Connect -> Next ->Done.

Then go back to live logs and try to trigger some events. Things appear to be working for me..

Thanks. No change in behavior, or any logs to indicate what's going on. The only thing I see in logs are those related to do doing the " Apps -> Camect Connect -> Next ->Done" procedure. It worked once after making the code change, then hasn't since.

(I actually removed the code in line 101 entirely as I wasn't sure how exactly to comment it out. It kept saying "unexpected character at line 101" when I prepended with *, #, or / )

Edit - It does seem to work if I wait long enough in between tests, usually like 30 minutes.