Issuing Command Codes to IpCams and other IoT devices

filename: webc1code-to-cam.htm

(I also offer a page with the quirks, often including "fetch-image" command codes for specific IpCams.)

This page was edited heavily in February of 2019. It provides a general discussion of sending command codes to IP cameras and similar devices to, say, fetch an image for use by software other than a browser.

If you are viewing this on a computer, may I suggest, before you give yourself eyestrain, if you haven't already done so, that you make your browser window take up less than the full width of the screen? Everything will flow properly .. and you will have more readable text.

Why you would want the codes...

Yes- You can buy IP-Cams with all of the FarWatch elements built in... but if you go that route, your solution lacks flexibility. And you don't have the weather/ premise systems monitoring, either. FarWatch can use an IP-Cam, and for very little extra expense you get more features, more control. You can also take a middle road: Set up an PC to do the serving, and use WebCam Looker to take care of some of the things that the full FarWatch would give you.

If you just want to "do it", as I said at the top of the page, I have a page for you that is less theoretical and less comprehensive with instructions for getting started with an IP camera. Maybe that will be what you are looking for? I wish I'd had something like it when I started!

Perhaps I should also mention that my only connection with Felenasoft is as a customer. Yes, I liked their product; yes, I sent them feedback. No, I do not get a commission! And those comments are past tense only because, as I said, I've moved on.(2/19)

I offer a separate page with general instructions for setting up IP cameras. (Opens in new tab... just close it to come back here later.) That page speaks of the basic issues of setup. This page concentrates on the advanced topic of sending codes, commands, to IoT devices like IpCams, to make them do things. The context here is making the IpCam send a snapshot of what it is seeing, but the method employed to do that is the same as the method for many other things. Be sure you have a good grasp of things covered on the general instructions page before fighting with what's here.

Once you have a camera working, you may also want my page listing the quirks and "secret codes" (commands) for specific IpCam models

Before you play with codes...

I know: you just want to play with your camera. But...

As scary as doing firmware updates is... and you should be (moderately) scared... I would recommend that you seriously consider doing a firmware upgrade of any new camera, especially if you bought an elderly eBay bargain. Do the firmware update (almost) before you do anything else with it. If you don't know where it's been, do an "upgrade", even if you camera already has the latest, greatest version of the camera's firmware.

Naming of Parts...

Some "naming of parts"...

IP-CAM: An "IpCam" is a device which can be connected to a local area network (LAN), and supply images (at least still, maybe still and moving) to a web browser, e.g. Firefox. These devices often are capable of much more, but for our purposes, that's all we need. And we don't need the camera's supplier's proprietary software cluttering up our PCs, either. Typically, you connect the IpCam with a cable at least once, and then use a browser to go to a URL like http://192.168.0.2 to access the camera's control panel. There, you set various things like the resolution you want, and, if the camera has the feature, the settings for the wireless networking connection. You then disconnect the cable, and if all is well find the camera connected to your LAN by its wireless circuits.

With just an IP Cam FTP'ing to a server, and the free IrfanView, and the free VDub (both on Win7), I made an amusing 3 minute YouTube of the dreadful snow of "Spring" 2015 in coastal Connecticut. Well. It amused me, anyway.

DIGITAL I/O: Let's start with what this does not refer to: When I speak of a given camera having digital I/O (input and output), I am not talking about how the image is rendered. I am saying that the camera in question has places where you can connect external electronics or electrics. Such cameras can, for instance, set off an alarm bell when they "see" movement. They can be "told" to take a picture and email it, or store it, when, say, a PIR detects someone present. I have a page for you with more on IpCam digital I/O. (It will open in a new tab or window. Just close that to get back here easily.)

Here be The Good Stuff- How to use the "fetch image" magic incantations

Hermione would be so proud of us.

What this section is about: Many IpCams give you a way to fetch a "snapshot", a still image captured "now". We can harness that capability for our own purposes.

And once you master that, a whole world of ways to interact with IpCams and other IoT devices is open to you. Once you know how to send the commands, the "menu" of available commands is huge.

Here's how you set things up, and how you send commands...

The "basic" way to use an IpCam is to connect to it via a browser. IpCams are mini web servers, and can deliver pages of "stuff" to you, in the everyday environment of your preferred web browser.

They can deliver a video feed. And usually also an audio feed. The webpages served by the IpCam are also your "way in" to change settings. For example the password for being allowed to change settings, etc. Most IpCams... all?... give you a way to restrict access to the video/ audio feed to people who know a username/ password to authenticate themselves with.

But, usually, there's a way to go beyond the camera's web-pages.

There's often ways to send commands, still using an ordinary browser, to make things happen. The one we are most interested in is the commands to make the IpCam send just a still image.

In the browser, it won't look any different from the "snapshot" one of the buttons on one of the pages of the IpCam's webpages let you collect.

The beauty of knowing the right command, is that we can give that to other software, something other than a general purpose browser, and Do Things with the image.

But start by simply putting what you hope is the right URL (IP address of camera + Fetch-image command) into a browser. That's easy. And unless the URL will work in a browser, it won't work for other software.

(Even when you think you have the right URL, when you have one that puts an image in a browser, you may not have the URL right for what you want. But it is a start! More on this later.)

For some reason, the IpCam manufacturers seem to want to keep secret the "commands" for getting into their cameras to do things. But you need the commands to get into them with products like Xeoma, WebCam Looker, and the FarWatch family.

The camera-specific fetch-image details I've been able to discover in the camera-specific pages listed on my page indexing my camera-specific pages.

Prepare your way

Just before we start to get clever, fetch images directly, I should mention that you may want to do some "set up" work, which there's no need to do by the hard way. I've done a separate guide to general IpCam... in deed most IoT device... setup tasks.

For instance, many IpCams let you overlay some text in any still images fetched from the camera. This text, in some instances, can even include a date/ time stamp.

Setting that up... and setting up everything necessary for the cam to know the current date/ time!) is best done just accessing it via a browser, the simple way.

But, as long as you have some access to your camera, you can leave that to later, if you want to get to the heart of things now. (I'm not a patient person, either.)

So... start by testing what you think is the right URL to fetch an image into an ordinary web browser. (Firefox/ Safari/ Chrome... etc,)

"The URL"- top level description

In every case, what you enter into your browser will be something of the following form....

http://TheCamsIPaddress/SecretCode

The "http://" is generic to the way we are accessing the device. (You don't always need to type it... it is sometimes assumed. If in doubt: type it. When your URL works with it, try leaving it off.)

The two parts of the URL

First- TheCamsIPaddress...

This may be too sketchy for a complete novice. If so, I have some pages explaining connecting stuff to LANs and the internet which may be useful.

Back to the TheCamsIPaddress part of what we need...

In a simple scenario, to talk to a camera on the same LAN as the computer that wants to talk to it, the "TheCamsIPaddress" will be something like...

192.168.0.254

... with the "254" quite likely to be different in your case, and even the rest of it may be different.

I would suggest that you set the camera to use a static IP address.... which is different from having a static IP address for your connection to the internet (!). And you may have to fight with your firewall and anti-malware software to "get into" the camera, or "see" its answers. (Don't be too alarmed, by the way, if your anti-malware software asks if you want to permit an "outgoing" connection... if that connection is for your camera's IP address, i.e. 192.168.0.254 in my example. We aren't using that connection to the outside world yet, but there may be good reasons for what the camera is trying to do. (Don't be too shy about blocking it, for now, if you wish. Just remember you blocked it, because you'll probably want to unblock it, when we get further along.)

... and then there's...

Returning to "TheCamsIPaddress" part of...

http://TheCamsIPaddress/SecretCode

If you have got DDNS up and working for your LAN, have fixed the firewalls, etc, then instead of numbers for "TheCamsIPaddress", you should be able to enter whatever domain name is being "delivered" to you by your DDNS service. (See my setting up DDNS, if you want more help with that.)

Let's say your camera is in your LAN at 192.168.0.254, and your DDNS delivered domain name is FredsPlace.dyndns.org.

Sitting at a computer on the same LAN as your camera, you could use either of the following to fetch an image from your camera. (We will talk about the "SecretCode" part in a moment.)

http://192.168.0.254/SecretCode

... or ...

http://FredsPlace.dyndns.org/SecretCode

(Remember: get things working with the first version before you start trying the second. The second needs all the things the first does... and more!)

In the first instance, you are talking to the camera directly across your LAN... PC to router to camera and back again.

In the second case things are much more "interesting".

First an enquiry goes out from your PC to a DNS (not "DDNS") server out somewhere on the internet. That sends back the numbers which are right for FredsPlace.dyndns.org (as long as your DDNS server is doing its job, which is to keep the DNS service appraised of the periodic changes to what the right numbers are for your router is at, from the WAN's point of view, i.e. it's "WAN IP address".)

Then whatever you wanted to send to the camera goes...

• From your PC...
• through your LAN to your router/modem...
• out onto "the internet" (WAN)...
• back to your router/modem, and finally...
• over your LAN to your camera.

And that's just to start the process of fetching an image! That's what it takes to get your command to the camera.

Then your camera sends the "answer" to your request back, mostly just reversing the first part of the process, skipping the "find numeric address" step. (The "return address" (as a number) was "on the envelope" of the request.)

Whew! But if you understand that, you have a better chance of beating something that isn't working.

Always try the direct access (via numeric address, merely across your LAN) to a device first. Once you have that working, you can start fixing any extra problems you may have due to the extra steps involved in remote access.

A little good news: Mostly, if you can access the camera using a "FredsPlace.dyndns.org"- type IP address, from a computer on the same LAN as the camera, you will be able to access it the same way from a computer out there in internetland.

And when you have all of that working, test your setup from a computer NOT on the same LAN as the camera... some routers are "clever" enough to see what you are up to, and skip the "go out on the net" part. But get access from a PC on the same LAN working first, before you do the ultimate test.

Still on the subject of the TheCamsIPaddress part of...

http://TheCamsIPaddress/SecretCode

You must type the "http://" part if you are using Internet Explorer... at least through IE 10, or it will say "Cannot Display", or similar, even if everything else is right. You will sometimes get away with leaving it out for a place you have already visited, as the computer's "auto complete" may "translate" what you've entered to the equivalent, with the http://. This may be particularly true if you are using a non-standard port.

And at one stage, it was probably best to use Internet Explorer for working with consumer grade IP cameras. Many will "work" with Firefox... but not give you all of the features that you can have if you allow Internet Explorer and it's ActiveX controls.

ActiveX is "old skool", and was frowned upon as being insecure. But, if like me, you use cheap IpCams from eBay, they require ActiveX for some things. (I haven't played with these things extensively for a few years now, at 2/19, when these pages are being overhauled. With all the "improvements" to Windows, you may be stuck for the things that needed ActiveX. But, once you get the "secret codes" for the direct commands, you'll be okay!

ActiveX-needing cameras are particularly prone to fail to display images with non-IE browsers. (Often text-based setup tasks work fine. And often, in a browser, there are ways to see images, but only as a series of jpeg snapshots. That's enough to get through figuring out what we need.

And, whew, a final point on the subject of the TheCamsIPaddress part of...

http://TheCamsIPaddress/SecretCode

I should have called that "TheCamsIPaddressAndPort".

If you enter...

http://192.168.0.254/SecretCode

... then the system will treat that as....

http://192.168.0.254:80/SecretCode

The ":80" bit says "use port 80". Port 80 is the standard port to use for HTTP.

But you will probably be able to change the port the camera uses, and you will eventually need to do so if you have more than one camera on the LAN, or if you already have some other HTTP server on the LAN at port 80. And it is a good idea (helps keep The Bad Guys Out) even if you don't. (The camera is an HTTP server, if you didn't know that. That is why you can "talk" to it with a web browser.) Let's say your other HTTP serving device is on 192.168.0.100.

The good news is: You can start with access via port 80.

If you were only going to communicate with the devices across your LAN, you could leave them both set to use port 80....

http://192.168.0.254

... and...

http://192.168.0.100

... would take you to the other device.

But as soon as you start wanting to access both devices via the internet, you will need to give them separate ports. Let's say you decide on 80 and 81. Then....

http://FredsPlace.dyndns.org:80

... would take you to the camera, and...

http://FredsPlace.dyndns.org:81

... would get the other device you. (Once you've got your router's NAT set up properly (^_^) of course.)

I will continue to use 192.168.0.254 for "TheCamsIPaddress" in the discussions that follow. Remember that you will almost certainly need to change that, if only the "254", on your system.

Remember that, eventually, you will also be able to use your version of "FredsPlace.dyndns.org:port_number" for "TheCamsIPaddress",too. (But if that's not working, always "drop back" to the numeric, local, IP address. Get things working that way. Then investigate what's blocking access the other way.)

Moving on from what you put into the browser, at last...

The two parts of the URL

Second- "TheSecretCode", the "fetch image" command...

Happily, this section is much shorter than the previous.

As I said, the URL will be in the form...

http://TheCamsIPaddress/SecretCode

We're done with the first part

Here's an actual example. It would cause a Panasonic BL-C101E to return an image to whatever software, for instance a browser, had issued the URL to the LAN...

http://192.168.0.205/
    SnapshotJPEG?Resolution=640x480&Quality=Standard

In this example, the material on the second line is the right "SecretCode" for that camera. (The "192.168.0.205" was just the "TheCamsIPaddress" part.)

Remember to separate the "SecretCode" part from the "TheCamsIPaddress" part with a "/". (There may be more "/"s as part of the "SecretCode".)

The "SnapshotJPEG" part is, of course, the heart of this command. The "?" connects that to some options. Playing with the options can be rewarding, once you've got the command working in some form. (Sometimes some of the "options" are mandatory... in the previous example, for instance, if you only send...

http://192.168.0.205/
    SnapshotJPEG

... you won't get anything. Just a blank screen in the browser.

A Gotcha!....

Sometimes it may seem as though you have found the right command to fetch an image.

You issue it, and you get "an image" in the browser... but then the command doesn't work in your other software.

Some cameras have a command which, instead of sending just the image to whatever issued the command, send a very small webpage. A webpage that only fetches an image to itself. So you only see the image, no text, etc.

How can you tell if your command is giving rise to one of those small webpages?

Once the image is on the screen, via a browser, access the "page source". In Firefox, you right-click somewhere on the page. In Firefox, if you right-click on an image from a camera which is just the image, i.e. what we want, the "View Page Source" option is in the menu which arises, but is grayed out, to say there is no page source.

If what you've fetched is the useless- for- our- purposes "small webpage", don't despair. You just have to fine "the other" fetch an image command, which your camera may have. Just because it has the one doesn't mean it doesn't have the other.