Skip to main content

Writing a home-monitoring system using python + internet...

Hmmm, what's that, you say? A Python home monitoring system? Why would anyone want to subject themselves to that kind of abuse?

Well, I , for one, amd lazy ... it shows in my work, it shows in my lifestyle, it shows in my weight .. and it shows in the way I write code. I'm the guy that will spend 2 days writing an app (which is available for purchase on the Google App Store) because I'm too lazy to get up and get myself a credit card ... because I'm too lazy to get up and scratch in the drawer for my old credit card so I can purchase stuff from Google Play ...

Before you go ranting that I expend time and effort to write an app which costs $3 ... you must remember that I am a programmer .. code it like water to me - extremely bitter, and mostly salty water, but water nonetheless ...

I eat code, I think code, I dream code and I can churn out code if I want to because it has become second nature to me. So it's simpler for me to just write it myself than it is to actually expend some physical effort to go and find something ... you cannot grep in the real world. You cannot hit [Ctrl][F] after opening your drawer. Frankly, I should patent some kind of "Reality Search" function which would apply itself to real-world objects ... but I'm too lazy to go down to the patent office to get it filed in person... Even if I could file patents online in my country, I would be too lazy to get up off my ass to go and use my new function...

Which brings me to the crux of my post ... why would I use python for such a serious task? What I am trying to do is definitely non-trivial, but surely PYTHON?

Well, the truth is that I am too lazy to go back to coding things in C++, I am not an Environmentalist, nor am I a packer ... I am more of a "mapper" who likes to interpret and adapt information into some kind of "view" which can be applied to knowledge ... and my "view" of the matter is that if I need the blazing speed to shoot myself in the foot a trillion times while simultaneously being bitten into millimeter sized pieces, then C++ is the way to go for every project.

If I were to use C++, then I would have to either write little command-line programs which did something specific with some command line input ... and tie that into my server (I'm using Apache - it's easy to set up, and doesn't require any movement on my part) ... or I could churn out some high-level code using a high-level "interpreted", "dynamically typed" language like Python... which saves on compile time, debug time, the amount of keystrokes I have to bang out ... it saves on heart rate as there is less agitation, and it saves on breathing since there is less cursing...

It's kind of a simple choice, really. For anything web-related, use web technologies ... for industrial "blazing speed", specialized applications, then get closer to the hardware with C or C++ ... For the record, I prefer the straightforward nature of C (I have spent several years coding industrial apps using C - if it's not straightforward, then you misunderstood something) but I love the speed you get when you can bang out a couple of object, an interface between them and then set them loose on the world of C++ ... so it's a trade off really. You just need to know which hammer will beat which nail, then all should be fine.

So back to the app - it's a very simplistic application:

  • Set up a "service" running in apache which allows an authenticated user to receive a screenshot containing all visible web cams on the home network.
  • Send these screenshots at some interval to the authenticated user.

This is fairly simplistic - since I will not even get into the hair raising mess of authenticating a user...
The simplicity is in how one would collate the images and send them over the network ... it's fairly straightforward to get the images - leave the DVR software running all the time, and periodically take a screenshot using this function:

import win32gui
import win32ui

def screenshot(_filename):
  wDC = win32gui.GetWindowDC(HWND_DESKTOP)  #hwnd
  _w = win32ui.GetSystemMetrics(SM_CXSCREEN)
  _h = win32ui.GetSystemMetrics(SM_CYSCREEN)
  dataBitMap = win32ui.CreateBitmap()
  dataBitMap.CreateCompatibleBitmap(dcObj, _w, _h)
  cDC.BitBlt((0,0),(_w, _h) , dcObj, (0,0), win32con.SRCCOPY)
  dataBitMap.SaveBitmapFile(cDC, _filename)

  win32gui.ReleaseDC(HWND_DESKTOP, wDC)

This would give me some image with a predetermined name which I could look up on the drive when I needed it ... I would probably store the images in a folder which represents the images from a specific cam on a specific day ...

Loading up the image is easy ... displaying it to the user is equally easy ... write a little JS function which requests an updated image via Ajax at some interval... Embed an <Object> into the HTML, tie it to the JS and VIOLA! You have a bandwidth-friendly solution to a home-surveillance problem...

This is obviously a gross oversimplification of the whole app, but it would definitely work along these lines ... I would obviously write some code (using PIX or Pillow) to convert the images to JPEGS on the fly either before saving, or at request time ... but the basis is the same. Obviously I would have to port forward on my router to allow that to happen ... but luckily DynDNS has made that much simpler, and all the grunt work of getting it set up , and obtaining a DOMAIN with a dynamic IP has been taken care of .. I have even assigned a static IP to my "surveillance" box which runs the apache server .. so most of the setup work is done .. all I need to do is to tie in some way of getting screenshots at a specified interval - which is equally easy ... write a "backdoor" into the system whereby I can leave a browser window open on the same machine running some periodic Ajax function which would force the server to respond at some predetermined interval - when I get a specific Ajax request, then do the hard work ... very hacky, but sufficient for my purposes - I could hack this together in a day. Now, imagine doing all of that, AND writing the C/C++ code to back it up? Can you imagine the pain and agony and suffering you would go through simply debugging why X won't initialize before Y?

If I wanted ultra-secure 128bit encryption and blazing fast real-time RTSP streaming web app, then I would be forced to resort to a C/C++ HTTP server which relies on the live555 media streaming library somewhere... and then write a C/C++/wxWidgets-backed client side which decodes and displays using FFMPEG... but, thankfully, I don't need to go that route just yet :-)

Thanks to pyfunc over at StackOverflow for the screenshot function, which I am generally going to plunder from the SO site - as much as I plunder many lines of code from awesome coders who are not as lazy as I am.


Popular posts from this blog

XBOX ONE Game Dev is supposed to be hard.

So I recently took the plunge and joined the Xbox One Creators Program with Microsoft. It turns out that it's supposed to be incredibly hard to build these little games we see all the time, and for the most part, it is. Not only do we have to deal with the fact that the XBOX One does not use the stripped down PowerPC architecture that the Xbox360's used to run on, we now have to contend with the fact that it's basically running Windows 10. I remember the good old days when win32 and GDI (Graphics Device Interface) were sufficient to get a decent game running on a Windows PC - especially if the game wasn't too resource intensive. Then came Direct(X/3D/2D/11/12) with all its COM (Component Object Model) Glory -> which, perhaps most asinine of all -> is still being used today. Getting into the creators program costs a little bit of money, and that's mostly to keep the chancers out and cover administration fees. After that you really only need to abide by the

Finding a Game Engine is Hard

Well, if you're new here - congratulations on finding the most useless blog on the planet. If you're not new here, thanks for coming back to another installment of "And he just keeps moaning!", this weeks episode deals with how hard it is to select a Game Engine for your development needs. As I've mentioned in the past, there are many things to consider when developing a game: Storyboarding Specification document Game Engine Resources (art / sound / levels) Time constraints Return on Investment Since I've preached about the Specification Document all throughout my last post , I'll save you a little bit of reading by saying it's nearly the most important part of the entire process - nevermind having a compelling game - without the specification document, nothing gets built. Storyboarding is kind of like the specification document, but it allows you to draw little screens of the game as you imagine it to be, without too much detail.

A few thoughts on Game Development

For those of you who follow my blog, you'll notice that I talk about building games, but I never really release anything useful or fully playable. I'm more interested in studying the individual parts of game development, without really caring about building a game as a whole. Well, for the most part this is perfectly acceptable, as I'm not a game developer by trade, and my bread and butter comes from being a utility developer. I've defined utility developer as someone who codes a variety of things without specializing in any specific discipline. As a self-taught developer, it's been hard for me to pivot into a role where I'm classed as a game developer by trade. This is all good and well, but I still want to talk about game development as a whole - specifically how to get a game off the ground. If you've been following any blog about game development, or any programming course which walks you through the process, you've most likely heard of all the jar