Before this project, I had heard the word Git, but I never really understood why programmers seemed so attached to it. In simple terms, Git is a system for keeping track of changes in software. If you improve some code, Git remembers what changed. If you make it worse, you can go back. If several people work on the same project, Git helps combine their work without losing track of who changed what.
For programmers and geeks, that makes Git almost essential. GitHub is simply one of the most popular places where Git projects are stored and shared online.
I did not set out to learn Git. I bumped into it because the ONVIF node for Node-RED — the software I was using to connect cameras — was hosted on GitHub. That became important when the Tapo cameras refused to stay connected.
Why Does It Work Here, but Not There?
The strange thing was that the same Tapo cameras behaved very differently depending on the software. Inside Node-RED, the ONVIF connection kept dropping. But when the same cameras were connected to Shinobi, the open-source NVR software, they stayed connected much more reliably.
That confused me. The camera was the same, the network was the same, and even the Ubuntu server was the same. So why could one piece of software hold the connection while another kept losing it?
Then I had a thought. Both Shinobi and the Node-RED ONVIF node are open source. So instead of changing cameras again, why not look at how Shinobi maintained the connection and borrow the useful parts?
A few years earlier, that thought would probably have gone nowhere because I would not have known where to start. But after Tuya, AWS, APIs, encryption, Pulsar, Node-RED and TTLock, I had become much less afraid of opening somebody else’s code and asking, What exactly is this doing?
Darren Finds Another Clue
I asked Darren for help again. He found another open-source program called ONVIF Device Manager, or ODM.
We tested the Tapo cameras with it, and they stayed connected fairly reliably too. That was the clue I needed. If Shinobi and ONVIF Device Manager could both maintain the connection, then the problem was probably not the Tapo cameras themselves. It was more likely the way the Node-RED ONVIF node handled the connection.
So now Darren and I had three pieces in front of us: the existing Node-RED ONVIF node, Shinobi NVR, and ONVIF Device Manager. All open source, and this time I also had ChatGPT to help compare them.
Borrowing the Good Bits
We asked ChatGPT to help identify how Shinobi and ONVIF Device Manager handled camera connections, then compared those parts in the Node-RED ONVIF node.
From there, we started modifying the connection logic and testing the cameras again. After quite a bit of trial and error, the Tapo cameras became much more stable.
That felt like another small milestone in the journey. I was no longer just using software somebody else had written. I had actually modified an open-source project to solve a real problem in my own business.
Since the Tapo C100 is such a popular camera, I thought other people might have the same problem. So I uploaded the modified version to GitHub.
That became my first Git.
Not exactly the Linux kernel, but something can solve a real problem.
Everything Finally Worked
By this point, I had somehow ended up with a heavily customised system linking smart lighting, smart CCTV, customer access control, TTLock, Node-RED, AWS, and Storeganise.
For the first time, everything seemed to work together. Customers could book, access codes could be created, doors could open, cameras could detect movement, lights could react, and events could be recorded automatically.
After all the failures, late nights, strange error messages, and piles of discarded hardware, the system finally felt mature enough that I could stop watching it every five minutes.
So I decided to give myself a treat: I took my family abroad for a three-week holiday.
For about a week, everything seemed fine. Then I received a very angry message from a customer. He had arrived at the storage site 6am, entered his access code — and TTLock kept rejecting it, and remember I designed Birmingham Self Storage to be a humanless facility, no staff would be onsite outside normal office hours.
I stared at the message. The system had been tested, the code had worked, and everything was fine before I left.
Apparently, it had decided to wait until I was thousands of miles away before revealing its next problem.
Next Chapter: The Unhappy Store Manager
free to follow my BSS journey — a real, unfiltered account of building an independent self-storage business in the UK, one problem, mistake, and hard-won solution at a time.
Leave a Reply