A while back, I had the need to remotely monitor a house while it was under renovation. A few friends of mine recommended a particular brand of highly-advertised security system. It was not cheap. As I was setting it up, I found out that most of the features that I wanted required broadband internet. This was not disclosed in ANY of the marketing materials. This house didn't have Internet and I wasn't going to purchase it because it would have been $60 minimum on top of the $40 or so the security system was going to cost.
What I did instead: I bought a Raspberry Pi camera, hooked it up to a RPi Zero 2W that I already had, bought an LTE hotspot and a $5/mo prepaid SIM from T-Mobile. On the software side, I used imgcomp (https://github.com/Matthias-Wandel/imgcomp) to take a photo every second and save it to a RAM disk. If the two pictures differed (modulo noise), the Pi would upload the changed picture to a directory on my VPS, which would then trigger a notification to my phone via Gotify containing the link to the picture.
It was all very Rube Goldbergian but it worked quite flawlessly for a couple of years.
I'm having trouble squaring "the security system was not cheap" with "the $40 the system was going to cost". How cheap were you looking for a security system to be?
Very cool! This is, IMO, perfectly in the spirit of all tinkerers and hackers, building their own solutions when they need from what they have. There is nothing Rube Goldbergian about this. My 2c.
Were you expecting to monitor the cameras over the Internet without an Internet connection? This reads like you were expecting the cameras to have built in LTE without some kind of subscription.
Yeah, this post is bizarre. Between "I bought an expensive $40 security system" and "it needed the internet, so I got rid of it and built my own, which also required the internet", I don't know what to think.
The post said that the commercial security system required "broadband Internet", which had a much higher monthly cost than the existing lower-speed Internet connection.
According to the post, the commercial system demanded a $100 monthly cost for the security services and broadband Internet, vs. $5 monthly cost for a lower-speed Internet access that was enough for the custom solution.
Therefore the reduction in the monthly expenses was worthwhile.
I was living in an apartment while building my house. My idea was to have a camera making a time lapse video with the secondary effect of being able to be accessed by me from the internet so I can take a look at how the crew was doing. Unfortunately every single ideia that I have is already had and developed by anybody else. In this case, china. Ali express have some pretty good cameras that does that and more; with a better finish then a 3D print shitty case...
Some (maybe most or all) of these devices require an external service to be used. That means it will work as longs as the service exists. You are in the hands of the vendor. My dream is to make devices like this and make them remotely accessible through Tor; that way it can be fully local but remotely accessible from anywhere in the world.
I bought a few Reolink cameras (around $50 each) and they have pan/tilt and don't require the internet. In fact, I didn't even connect them to it, I connect to them via my Tailscale VPN and they support this mode explicitly, and work perfectly (obviously real-time notifications don't work).
nice use of WebRTC, which somehow is still underutilized.
>If you're self-hosting and you want to access the signaling server remotely via mobile data, you may need to set up DDNS and port forwarding if your ISP provides a dynamic IP.
this also exposes your server to the internet. instead you can use one of the open source solutions which creates a private connection between your Pi and server (so there is no network access to the server - make it unreachable), and doesn't require static IPs or port forwarding.
We need wider IPv6 deployment now. If only someone like Zoom put their foot down and said “our shit doesn’t work without IPv6” we would see 90% deployment virtually overnight.
i believe the p2p strengths should play better with other in-progress tech transitions - e.g. transition of all thick apps to the browser, decentralized identity, micropayments, distributed IoT and IIoT devices. what do you think?
They decided to use the silicon space for other things. The Pi5 CPU is powerful enough to decode most h264 streams in software. The Pi5 has an h265 hardware decoder.
Not true actually. If by offloading you mean to a device that uses a really small model with 8-bit quantized weights you are not actually solving anything.
Neat, I was looking for exactly something like this to run person detection! I'm using yolov3-tiny, not quite a new but very lightweight computer vision ML model, and just right now I'm trying to maximize performance of inference with C++, to perform real-time person detection around my house (I want to know when someone enters the parcel at night so a siren and lights can turn on automatically to deter the intruder) - https://github.com/jmaczan/yolov3-tiny-openvino
Made me think of alarms randomly going of in the middle of the night.
Then had this thought, imagine triggering lights and siren gradually as one approaches. That way it can trigger much earlier and give a could-be intruder enough signal to stay away. I suspect gradual adrenaline in a feedback loop is more effective too. A sudden effect only needs to be considered once.
This is interesting approach! I'd be worried that they would manage to hide in some camera dead zones if I don't react with all-in (siren, all lights etc) quickly enough
I recently built an always-on recording device, primarily for recording audio consistently and constantly - this is not for surveillance purposes, but rather for musicians and creatives who don't want to have to remember to press the Record button in the middle of a great performance. I used the Zero-W and some tricky shell scripts pushing arecord/aplay around, with a turboLua front-end, and .. it works pretty well!
I set it up to record continuously, deleting audio content only once it gets 'stale' as per the users preferences, with options ranging from 1 minute - 5 minutes - 15 minutes - 30 minutes - 1 hour - 3 hours - 5 hours - 24 hours .. and built a front-end to allow the user to Keep the time-period they feel they might have captured something great. This heuristic is somewhat similar to the deadman-switch/security-camera mechanism used in a lot of surveillance products.
It works so well, I kind of wonder why its not really a standard already. I guess there is still a kind of 'economy preference' where folks don't really want to fill up their storage space, but these days 128Gigs can go a long way.
I'm pretty sure this heuristic should become a norm, one of these days. Its so inspiring to set up, forget, and then - after a few hours of jamming - come back and find the stuff you want to keep, having all the rest of the house-keeping done for you.
Let's not forget the old RPi Cam web interface project. It's a really old one but it's still running on my Pis. It's running in a perinneal environment so it doesn't ruin the SD card it's on, while saving to a server. The interface is also neat. https://elinux.org/RPi-Cam-Web-Interface
I've been using https://github.com/TinkerTurtle/Sentry-Picam for a similar purpose with great success. The recorded images/videos folder is syncing up with 3 other machines for redundancy using syncthing, and I hooked-up a push notifications script based on sendxmpp to have alerts on all my devices in real-time if something happens.
A WebRTC implementation for my microcontrollers exist https://github.com/sepfy/libpeer it requires more work to use then most want (but it is the perfect building block for higher pieces)
Early versions of https://github.com/pion/webrtc used lots of cgo its an enjoyable read I find. The glue is higher level (interesting part) but the parts you don’t need the details on (DTLS, SRTP….) are abstracted away
What I did instead: I bought a Raspberry Pi camera, hooked it up to a RPi Zero 2W that I already had, bought an LTE hotspot and a $5/mo prepaid SIM from T-Mobile. On the software side, I used imgcomp (https://github.com/Matthias-Wandel/imgcomp) to take a photo every second and save it to a RAM disk. If the two pictures differed (modulo noise), the Pi would upload the changed picture to a directory on my VPS, which would then trigger a notification to my phone via Gotify containing the link to the picture.
It was all very Rube Goldbergian but it worked quite flawlessly for a couple of years.
The one-time purchase price of all the hardware was north of $200 with all the sensors and things.
According to the post, the commercial system demanded a $100 monthly cost for the security services and broadband Internet, vs. $5 monthly cost for a lower-speed Internet access that was enough for the custom solution.
Therefore the reduction in the monthly expenses was worthwhile.
I was living in an apartment while building my house. My idea was to have a camera making a time lapse video with the secondary effect of being able to be accessed by me from the internet so I can take a look at how the crew was doing. Unfortunately every single ideia that I have is already had and developed by anybody else. In this case, china. Ali express have some pretty good cameras that does that and more; with a better finish then a 3D print shitty case...
1 https://youtube.com/watch?v=5E7_40PWqiQ
[0] https://www.onvif.org/specs/stream/ONVIF-WebRTC-Spec.pdf
https://github.com/bluenviron/mediamtx?tab=readme-ov-file#ra...
>If you're self-hosting and you want to access the signaling server remotely via mobile data, you may need to set up DDNS and port forwarding if your ISP provides a dynamic IP.
this also exposes your server to the internet. instead you can use one of the open source solutions which creates a private connection between your Pi and server (so there is no network access to the server - make it unreachable), and doesn't require static IPs or port forwarding.
Why do you think it’s had trouble? Poor software, educational materials etc… always looking for new projects
I'm not sure I get the point of that... they go through the effort for video decoding, but why doesn't it have an encoder?
overlap exist in encode/decode. When working on a Opus codec I did have a fair amount of code distinct to one path still.
And maybe the pi5 has enough cpu to do the decoding. But how much would be left over for more interesting AI tasks ?
Then had this thought, imagine triggering lights and siren gradually as one approaches. That way it can trigger much earlier and give a could-be intruder enough signal to stay away. I suspect gradual adrenaline in a feedback loop is more effective too. A sudden effect only needs to be considered once.
I set it up to record continuously, deleting audio content only once it gets 'stale' as per the users preferences, with options ranging from 1 minute - 5 minutes - 15 minutes - 30 minutes - 1 hour - 3 hours - 5 hours - 24 hours .. and built a front-end to allow the user to Keep the time-period they feel they might have captured something great. This heuristic is somewhat similar to the deadman-switch/security-camera mechanism used in a lot of surveillance products.
It works so well, I kind of wonder why its not really a standard already. I guess there is still a kind of 'economy preference' where folks don't really want to fill up their storage space, but these days 128Gigs can go a long way.
I'm pretty sure this heuristic should become a norm, one of these days. Its so inspiring to set up, forget, and then - after a few hours of jamming - come back and find the stuff you want to keep, having all the rest of the house-keeping done for you.
A WebRTC implementation for my microcontrollers exist https://github.com/sepfy/libpeer it requires more work to use then most want (but it is the perfect building block for higher pieces)
I am trying to make it easier with a SDK for LiveKit https://github.com/sean-der/embedded-sdk
I tried to capture that with webrtcforthecurious.com breaking it down by subsystem.
I should do a companion piece ‘Build yourself a WebRTC’ that shows how to build WebRTC yourself in Python or other popular language.
Early versions of https://github.com/pion/webrtc used lots of cgo its an enjoyable read I find. The glue is higher level (interesting part) but the parts you don’t need the details on (DTLS, SRTP….) are abstracted away