alexdelprete
Getting comfortable
I think the ONVIF functionality makes a difference. Try it if you have time.
Only thing that could work, is sniffing the traffic when you use Batch Config to turn that option on/off. But I doubt it's http calls.
New RCA HSDB2A 3MP Doorbell IP Camera
- Thread starter fleece
- Start date
I think the ONVIF functionality makes a difference. Try it if you have time.
Only thing that could work, is sniffing the traffic when you use Batch Config to turn that option on/off. But I doubt it's http calls.
ciphershort
Getting the hang of it
So is the best way to configure "camera-based" motion detection with batch config? Only reason I ask is because I've tried to create a custom motion zone in batch config but when I click save it gets rid of what I created and boxes fill the full frame so I'm not sure it actually saves.
Before I click save:
After I click save:
Before I click save:
After I click save:
ciphershort
Getting the hang of it
Still having some issues with motion detection and alerting with SSS. It got me thinking. Does the camera initiate the conversation with SSS for a motion event? If so, that means I'll need to have a port open from my camera VLAN to my Synology IP. Anyone know what that is to save me from having to sift through logs? @alexdelprete maybe?
alexdelprete
Getting comfortable
Best way for me because my DS1812+ does a lot of stuff and I don't want it to manage the detection algorithm that could stress the CPU if I can let the camera handle it. If your NAS is more recent and powerful, you can let it manage the detection process.
Setting the zone works fine here:
alexdelprete
Getting comfortable
The SSS and the camera are in constant communication, at least in my setup, I see it from my wireless mesh system. I have a constant flow of 3Mbit/s between the NAS and the camera.
I understand why you create a VLAN for those devices, but at least you should open up communication between the SSS (NAS) and the camera. I remember in the thread someone posted all the ports he detected looking at his fw logs. I don't know if those were reported in the 101, check it up.
At first i had the same result as you describe. Just whipe all the boxes. Save it. Then select a small zone click save again. Then select the complete zone. And save
When you are using motion detection from the camera then the camera initiates the communication to SS. So you have to open that.
alexdelprete
Getting comfortable
I don't think it works that way, unfortunately, check the help doc on SSS:
- "By camera" offloads the detection algorithm to the camera, saving the NAS cpu
- The "keep original camera settings" tells SSS to use the detection area configured in the camera, that's it. At least this is what SSS help says.
This doesn't mean the video stream is sent to SSS only when motion is detected by the camera: I see a constant 2-3Mb/s traffic from the cam to the nas, 24h/24h, even when there are no motion events.
Deductively, we can say that the stream is continuous, and when the camera detects motion, it tells SSS to record the stream.
I don't know how much CPU is used by the detection algorithm, but if I had a powerful synology, I would do everything on NAS, since the stream is sent anyway and it's easier configuring things on SSS than via Batch Config.
In my case, the NAS is not one of the most powerful ones (DS1812+) and it also acts as a server for Docker, mySQL, and other services I need. So I let the camera manage the detection.
If I find out that the CPU usage of the algorithm is negligible, I might switch everything to SSS.
Let me know if you experience the same behavior on your camera/SSS setup.
alexdelprete
Getting comfortable
Yes, Batch Config is a little weird on that stuff, but once you understand the logic, it's pretty easy. On SSS it's way better.
ciphershort
Getting the hang of it
I don't think it works that way, unfortunately, check the help doc on SSS:
- "By camera" offloads the detection algorithm to the camera, saving the NAS cpu
- The "keep original camera settings" tells SSS to use the detection area configured in the camera, that's it. At least this is what SSS help says.
This doesn't mean the video stream is sent to SSS only when motion is detected by the camera: I see a constant 2-3Mb/s traffic from the cam to the nas, 24h/24h, even when there are no motion events.
Deductively, we can say that the stream is continuous, and when the camera detects motion, it tells SSS to record the stream.
I don't know how much CPU is used by the detection algorithm, but if I had a powerful synology, I would do everything on NAS, since the stream is sent anyway and it's easier configuring things on SSS than via Batch Config.
In my case, the NAS is not one of the most powerful ones (DS1812+) and it also acts as a server for Docker, mySQL, and other services I need. So I let the camera manage the detection.
If I find out that the CPU usage of the algorithm is negligible, I might switch everything to SSS.
Let me know if you experience the same behavior on your camera/SSS setup.
View attachment 61526
From a network directionality perspective, the NAS is actually making the connection to the camera for the stream not the other way around. This is why my streaming works even though my camera IP is blocked from talking to my NAS. My NAS can establish a connection to the camera all day in that direction so this proves you don't need ports opened with the camera as the source and the NAS as the destination as long as you are allowing established traffic from the camera to the NAS. You do, however, need ports opened with the NAS as the source and the camera as the destination which is what I have configured.
My question still is on how event detection is communicated. If it's just a flag on the video stream, then it's probably fine the way I have it. If it's a separate communication flow with the camera initiating that flow and sending it to the NAS, then I'll have to make an allowance for that. I don't trust any IoT device on my network to be able to talk to more than it should have to so that's why I run a locked down IoT network. My issue could just be with the motion zone weirdness so I'll tweak it like @KlaverBoer suggested and let it run for a while.
Yes, Batch Config is a little weird on that stuff, but once you understand the logic, it's pretty easy. On SSS it's way better.
Are you saying you can edit the camera motion zone from SSS? I know you can uncheck the "Keep original camera settings" box on the Event Detection page in SSS Camera Settings but didn't know if that actually updated the camera.
ciphershort
Getting the hang of it
Actually a thought just hit me. It has to be a flag or something on the stream itself. Because the camera is never configured to interact with the NAS/NVR. The camera is just there doing it's thing for any device that connects to it for a "pull" of data....
alexdelprete
Getting comfortable
1. The NVR/SSS is the master, the camera is a slave, it does not initiate a connection, the master does via RTSP. So the communication is always started from the NAS, never from the camera. So I don't understand when you say that you have configured it the other way around. The slave sends the video stream continuously, and when it detects motion, it sends some tag/message in the same RTSP session. At least this is how I would have done it. But it's just speculation until we study the RTSP protocol/standard.
2. I think the motion detection event is inside the same RTSP session, inbound. I never studied the RTSP protocol, but I bet there's some session/application layer data structure used to exchange data from the slave to the master.
3. You need to "open ports" when you use a firewall, and they work at the OSI level >= 4, not related to VLANs. VLANs are OSI Level 2 layer, for L2 switches, ethernet level. Probably you have a Layer 3 switch, that routes traffic between VLANs, but you don't see "ports" at Layer 3. So you can route traffic between VLANs based on addresses (MAC and IP), not ports. This is just to clear out that probably you have all IoT devices in a separate subnet, associated with a specific VLAN. So you not only route traffic through a Layer 3 switch, but you also have a firewall between all subnets that inspects transport layer (level 4) traffic, so the "ports". Let me know if I got it right.
alexdelprete
Getting comfortable
ciphershort
Getting the hang of it
1. The NVR/SSS is the master, the camera is a slave, it does not initiate a connection, the master does via RTSP. So the communication is always started from the NAS, never from the camera. So I don't understand when you say that you have configured it the other way around. The slave sends the video stream continuously, and when it detects motion, it sends some tag/message in the same RTSP session. At least this is how I would have done it. But it's just speculation until we study the RTSP protocol/standard.
2. I think the motion detection event is inside the same RTSP session, inbound. I never studied the RTSP protocol, but I bet there's some session/application layer data structure used to exchange data from the slave to the master.
3. You need to "open ports" when you use a firewall, and they work at the OSI level >= 4, not related to VLANs. VLANs are OSI Level 2 layer, for L2 switches, ethernet level. Probably you have a Layer 3 switch, that routes traffic between VLANs, but you don't see "ports" at Layer 3. So you can route traffic between VLANs based on addresses (MAC and IP), not ports. This is just to clear out that probably you have all IoT devices in a separate subnet, associated with a specific VLAN. So you not only route traffic through a Layer 3 switch, but you also have a firewall between all subnets that inspects transport layer (level 4) traffic, so the "ports". Let me know if I got it right.
Yeah I'm saying VLAN which equals L3 subnet which is an isolated by firewall rules on my Unifi network. All my VLAN gateways sit on my Unifi USG which I can then control whether to isolate VLAN traffic from other VLANs or not. I should have been more specific and clear before. Not used to other people understanding networking. I'm a network engineer by trade so my home network isn't the average home network and usually when I try to explain it to people they fall asleep before I get 5 words out haha.
alexdelprete
Getting comfortable
I'm an ex sysadmin/network admin. Didn't mean to correct you in any way, the intent was to clarify that it is important to take care of the security of IoT devices, and it is not easy doing it without specific knowledge.
I'm so fascinated by Unifi products, but gosh, they are so expensive. maybe one day I'll set the budget for them...being a professional, I really like making the mainstream/commercial products work, but I can't understand how these mainstream brands sell so many products that are really bugged and missing many basic functionalities.
I'm sorry if my post upset you, it really wasn't my intention, if it did please accept my apologies. It was just an old nerd's rant.
ciphershort
Getting the hang of it
Not at all! Just providing some context as to my background so we can understand each other better. I love the Unifi products. Got most of them on eBay but they are pricier than your average consumer network gear. You were right to spell things out for those that may read this and not understand. Your post was clear and would explain it to someone who might lack proper understanding. Good job!I'm an ex sysadmin/network admin. Didn't mean to correct you in any way, the intent was to clarify that it is important to take care of the security of IoT devices, and it is not easy doing it without specific knowledge.
I'm so fascinated by Unifi products, but gosh, they are so expensive. maybe one day I'll set the budget for them...being a professional, I really like making the mainstream/commercial products work, but I can't understand how these mainstream brands sell so many products that are really bugged and missing many basic functionalities.
I'm sorry if my post upset you, it really wasn't my intention, if it did please accept my apologies. It was just an old nerd's rant.
ciphershort
Getting the hang of it
This did the trick. It's working as expected now.
