Sheepdog Software HOME
NOTES FOR DIFFERENT IPCAMs, INCLUDING "Harvest Image" CODES FOR SPECIFIC IPCAMs
First Steps: Setting up an IP Camera
filename: webc1setup1.htm
To every question, there is a simple answer.
And it is wrong.
There are simpler answers... not much simpler... to setting up an IpCam and if you use them, what you can do next, or alongside your camera, is limited.
Much of what is in this essay will also apply to most IoT devices, by the way.
The "answer" I am going to present here does not have all the bells and whistles you could employ, but it does do a few "extra" things which will pay dividends.
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.
Where we are going
As I was working on the following, I could feel it unraveling. Sorry. The content here should be "good", i.e. not wrong... but the organization is a work in progress.
What I'm trying to do is give you an overview of the basics of getting an IoT device set up, using an IpCam as an example. Each device/ camera will have its little quirks, but there are certain fundamental tasks which always need attention.
This page gives you a "check-list" of things to at least consider doing, and general advice. Keep this page open... but for some reader's needs, also my index of some details of specific IpCams, one page per camera, may be where you'll find what you are looking for. (The link should open in a new tab or window, so you don't lose this one.)
In the next few paragraphs, I am going to try to briefly list those basic setup tasks. (I find that I use my own webpages, by the way. They help me not miss steps I should do.) Then the rest of the page will go through the list again, discussing what each entails in more detail.
The "short list" is in one color, and the "long guide" in another. (As much to help me compose this, as anything!)
Not every one of my suggestions is the only way something can be done. When was that ever the case? But I've been playing with IP cams and similar for more than ten years, and with computers for a lot longer. The prime target audience here is the home user, or small business. If you found useful things, I would be grateful to hear what was useful, and a bit about your circumstances. Am I serving my audience??
I am trying to supply ways for you to jump around in this document. From the "Overview section", there are links to the related material in the "Details" part, and at the end of each "Details" part, a way to go to back to where you were in the overview.
Here we go... Overview section
Start by trying for no more than to get your camera working well on your LAN. Get all the challenges of THAT sorted out, and you are a long way towards being able to see the camera across the internet. There is no aspect of the latter which is needed for the former.
Some first- of- all advice...
Until further notice I would do the early steps with the camera attached to the LAN by a cable, i.e. not wirelessly, if possible. (I'd certainly do the firmware update across a wired connection.) That's a option with most cameras. If you want, eventually, to connect it to your LAN wirelessly, i.e. by WiFi, that's fine. But I would save setting that up for much later in our list. Be sure it works nicely over a wired connection first.
But it doesn't particularly matter to our discussion. If you are using WiFi, just pretend you are using cables when reading this guide please.
Remember that you might have to tell your anti-malware protection let the camera do things. Sometimes blocks by your anti-malware service won't be immediately obvious. You'll be scratching your head saying "Why isn't that working?" Remember to consider the anti-malware software.
I would do a firmware update on the camera as soon as I could. (That link will take you to an external page, but in a new tab. Just close it to get back here.)
Most links from this page merely take you to another part of this page.
To do the suggested firmware update, you'll first need to get the camera working on your LAN, even if only on a basic level.) But as soon as you can, do the firmware update.
I would certainly do a firmware update, very quickly, with a camera bought second hand from eBay, even if it had the "latest/ greatest" version of the firmware already. (I might unplug other things from my LAN until after the update.) This device will be on your LAN, and connected to the internet. That should scare you. Not too much. But enough to take easy precautions. Like making sure you have "clean" firmware. There is no "details" section further down this page for this topic because the details are in the separate page the link above takes you to. If you are not "an old hand" at doing firmware updates, I really recommend that you read my page. There are things that can destroy your camera if you don't do them right. It isn't hard to get them right, but know what you are doing, if you embark upon a firmware update.
Keep careful records. I give each device in my inventory a unique identifier- that is a big help. It simplifies making other records. At the same time as I create the identifier, I record when, where, for how much, and from whom I bought the device. Not hard. Useful data surprisingly often. In a moment, we will be talking of assigning an IP address to the device, and a port. You should change the admin user's name if possible, and you absolutely should change the password. You may, eventually create multiple users for the IpCam. All of this "stuff" should be written down... securely in some cases... for future reference. (I have a page with suggestions about passwords. (Of course!))
Set some LAN addresses aside, out of the range used by your router's DHCP service....
Optional, but strongly recommended):Once, for any LAN you are putting IoT devices on, to be accessed via the web eventually, set aside part of the LAN's address space for some devices with a static (local) IP address. Depending on your circumstances, you might well want to put the majority of the available addresses aside for assignment to specific devices. Go to details of set addresses aside
First things to do in a preliminary session with the device....
This is the time to do a firmware update. Put the device on a static IP address, within the LAN it is on. (Typically starts "192.168...") (Optionally... but there are reasons to do it... put the device on a non-standard port.) (Other than that, I will expand this entry in due course. For now, everything is in the "details" section.) Go to details of preliminary session
Here beginneth sections relating to two things I've treated separately. The first is a task for your preliminary session with the device. (After the firmware update.) The other might as well be done now, but can be done later if you would rather.
- Setting the IpCam to "sit" at a static address, and
- Changing the port it serves webpages on.
You can, of course, if you have even a little experience of these things, do both in one session inside your IpCam's settings pages.
Further thing to do in a preliminary session with the device: Put the device at a static LAN IP address....
Optional, but strongly recommended: Tell the IP cam to, henceforth, connect to the network with a static IP address. When you've told it this, you will need to reconnect to the LAN. Some very clever cameras do this for you, but you will probably have to do it "by hand". Go to details of assigning the device to a static IP address on the LAN. (The device's IP address on the WAN... the internet... is something else.) The "details" section for this is unusually big. Sorry!
Another thing to do in a preliminary session with the device: Put the device on a non-standard port....
If you will have more than one IoT device on the LAN, and want to connect to more than one of them, you will have to tell each to serve webpages on a different port. ("Ports" will be explained in the longer discussion below.)
Until you try to use the camera across the internet, using nonstandard ports isn't important. Even then, depending on how you use your router's NAT, you might leave all of your devices on port 80. (But I wouldn't recommend that.) I wanted to get this port setting business "in" because I hope you will eventually want to access the camera's images across the internet, and if you do, my advice is: Use different ports for each device. This is an easy time to tell your camera what port to use. Go to details of putting the device on a non-standard port
The log files: It may be high time to mention of the log files in the device, be it a camera or other IoT device.
They won't help you before you are able to connect to the camera across your LAN, but once you are "in" help is available to us that I often forget to use: The camera's log files.
Once you find your way into them, they can be a help to figuring out why something isn't working. Suppose you are trying to get the camera to sync its time with an NTP server, and it Isn't Working.
If after a few tries you go to the log files and see, say, "tried to access ntp.from.xyz.com- failed- password required", that tells you lots of Good Stuff. Yes! You've set the camera up to try to go off to "ntp.from.xyz.com". It even reached there! But that server now requires a password, if you want to get your time from it.
Setting up IoT devices can be frustrating, because success depends upon a long chain of things being right. And it isn't always easy to see which link is broken. To go back to the NTP example: Suppose the log file said "npt.from.xyz.com not found." That's a very different situation than the one we were in previously. (Let's assume there IS an NTP server called "ntp.from.xyz.com".) Without the log file, you only know... and you don't "know" that for certain!... that the configuration to sync with the server isn't working. (Maybe it IS set up properly, but your camera was badly designed, and only checks the NTP server at the camera's current midnight?)
Can you see what was wrong with the configuration that resulted in the "... not found" in the log file?
Highlight the "blank" space below....
There was a typo in the server's URL! The user
had entered "npt..." instead of "ntp...".
... to see the answer.
Log files can be helpful!!
Once all of the above is sorted out, accessing the device over your LAN should be straightforward. Now is the time to set up a WiFi connection for the IpCam if you want to use one.
If later you go back, to do further configuration tasks, I'd re-connect a wired connection, if the changes were complex. It just reduces the number of things that could go wrong. (You don't have to "turn off" the wireless connection if you want to use a wired connection too.)
Onward to connect to the world... and beyond?
After you have the above accomplished the further work to make that camera visible (and, if you wish, configurable) across the internet (aka the "WAN" (wide area network) doesn't much directly involve the camera (or other IoT device.) "All" you have to do is to "open the paths" (but not too many, not too far!) into your LAN, so that outsiders can see what insiders see. Just as you would for any other IoT device. Not much, if anything, will need changing within the camera.
You'll need DDNS "Dynamic Domain Name System" services. You'll have to deal with your router's firewall and NAT. I've covered the subjects many times, on many pages... rationalization of those would be a better use of my time than new essays! I'll try at least to put links to those pages before too long. One is a a general article about servers, DDNS, etc, etc.. This link opens in a new tab or window. Just close that to get back to here.You've done some of the early stuff in this, but if you skim down you will come to stuff that isn't here at this stage!>
Bigger! Better! Further!....
Fun "advanced" operations: Once you can access the camera across the LAN, depending on your camera, you will have various things available to you. Few (none?) of these need WAN access, but if you've set up WAN access, then some of these become even more useful, interesting... fun?
These advanced, optional opportunities depend in one way or another on the basics. Get the things we've talked about before working. (You can still leave out the things flagged as optional.)
Most "clever" cameras can be "programmed" to do things.
As with any programing, there are "inputs" and "outputs". The IpCam administrator works with them, crafting "programs" of "if this... then that..." using the cam's web interface "settings" pages.
If you are really adventurous, you can build systems of which the IpCam is but a part, one that interacts with other hardware, running other software. E.g. my Arduserver/ FarWatch family.
IpCam "inputs":In the case of IpCams, the "inputs" are often called events. The events a particular camera can respond to, and how much you can do in terms of tweaking them is varied, of course.
IpCam "outputs":Typical events include schedules ("It is noon"), motion detection based on analyzing the image captured by the camera, motion (or other events) detected by external hardware which then sends a digital signal to the camera, which it can detect.
The "outputs" in this context include: Storing an image on an SD card you can plug into (and remove from!) the IpCam. Sending an image away to another device, by SMS, email or FTP. Sending a digital signal to some external hardware, typically an alarm bell. Besides images from the IpCam, you can send simpler things, maybe just a message- "Camera detected motion."
"Programming" "If this, then that" behavior: Once you're on top of the "inputs" and "outputs" of your specific camera, you then have to master its provision for putting together the "programs". The options here can be vast, in a good camera. Schedules can also be used to set the active hours for some of your programs. You might, for instance, only want to collect images, or be notified by email, from motion during certain hours of the day.
Given that I've used the phrase "If this, then that...", I should make it clear that in this essay, I am not addressing how you would "connect" an IpCam to the excellent IfTTT.com service. An IpCam could almost certainly be part of a bigger system which did involve IfTTT.com, though!
Not all of these things are covered in detail here yet... but, again, I've talked about them in other pages, if not in a well organized manner. Hurrah for Google! What topics do you particularly want looked at more closely? (Contact details below.)
Send images from IpCam to FTP server If you have access to, or set up for yourself, an FTP server, then you can configure your IpCam to send images to the server. (An FTP server is a bit like a NAS device, but you "talk to it" differently. It can be on your LAN, or out there somewhere in internet land.)Go to details of using an FTP server with the IpCam.
-----------------------------------------------
That's it for the overview of the tasks we might want to complete when adding a new IpCam or other IoT device to our system.
Now for some details....
-----------------------------------------------
First steps in IP camera deployment... The details
((WHAT FOLLOWS NEEDS EDITING... sorry...))
Okay... I've run through the steps in broad terms. Now we'll do another pass, with more details.
Remember that a firmware update is recommended as soon as you can do one. (The camera has to be working on the LAN for this.)
So first get your camera onto your LAN, and visible in an ordinary web browser, e.g. Firefox, on a computer connected to the LAN.
In doing that, you will have to overcome a few hurdles... all hurdles which have to be overcome, anyway, if you want to do more than just check live images via LAN.
Sidebar: I'm assuming that most of my readers will be home users. Even if you are from a different constituency, this should be useful, but you may need to "translate" bits. (A bigger problem is that you may not have authorities you will need.)
Your "switch/ router" is "the box" you use to get to the internet. Now it will also be at the heart of your LAN, local area network, if you didn't have a LAN before this. Or one you were aware of, anyway.
I'll work from the premise that you have a laptop or tower computer connected to the internet. There's a "box" someplace in your environment to which the computer attaches on one "side", with wires to (and from) "the outside world", the internet, coming out the other side... probably to a phone line or cable service. That "box" is your "switch/router"... perhaps previously referred to by you merely as "the router". It is a remarkably clever bit of kit, even though most of us "just use it", and miss the glories of all the stuff it does.
I'll explain in a bit why I was sticking that "switch/" bit on at the front, and for now just call it "the router", even though it IS doing some switching, too, probably, and may also have modem circuitry. (A story for another time.)
Prepare your LAN for the new arrival
If this is the first "special" thing you've put on your LAN, you may need to go into your switch/ router and make some adjustments there. You're probably using DHCP without even realizing it. And I wouldn't want to stop you using it for many things. But not for things like IP cameras... although if you only want to view them "locally", i.e. from devices connected just to your (local) LAN, then you can skip this. (You can also skip some of it if you use the "assign IP Address by MAC" route, mentioned in the box a little way below here.)
So you'll need to go into your router's configurations, and set some of the LAN IP addresses aside, put them "outside" of the range of addresses used by the DHCP controller in your router.
This is so that you can assign a "static IP address" to the IpCam.
It may be that your router has a facility to "dedicate" an IP address that is "in the gift" of the DHCP service to a specific MAC address. (Every device that connects to a LAN has a unique MAC address. The MAC address is often printed on the device.)
If your router offers that option, you could go that route, if you would rather. Instead of taking some LAN IP addresses out of the DHCP service pool. (I once met a camera that I couldn't set up to use a static IP address. The "by MAC" trick saved me.)
I'm not a fan of this solution, but that's mostly a matter of personal preference.
Go back to Overview entry
First session with the IpCam or other IoT device.
(More details to come!
When something is "on your LAN", it will have a "local IP address", aka "LAN address", aka (my term) "LIPA" (Lan IP Address).
This will usually look something like 192.168.0.23. The 23, and perhaps the 0 before it, may be something else.
The device will also have a "MAC". This is a bit like the device's "serial number", will usually be unique, and may well be printed on a label on the outside of the device. ("MAC": "Media Access Control")
I had to say "usually" unique, because if you have written the code inside the device, you may have had a chance to set a MAC. I'm not sure that a LAN will be "happy" if you put two things with the same MAC on it, by the way. I'd try to avoid that... but I don't know what MAC addresses are set aside for hobbyists to use! Good luck. I'm dodging any further comment on this detail for the moment.
When you first plug a sophisticated IoT device, like an IpCam, into your LAN, your router will probably give it a LIPA via the magic of DHCP.
Thank you DHCP... you are great for SOME things. Not so much for IpCams... at least if you eve want to be able to access them from "outside" the LAN, e.g. from "out there" on the internet. (The WAN.)
But you have to start somewhere. You have to be able to "talk to" the IpCam to set it up for the alternative: a static IP address on the LAN. (Assuming you don't want to go the "LIPA assigned by the IpCam's MAC" route. I'll try to write that up another time.)
So. You plug in the IpCam to your LAN, and then you "go to it" via a browser.
Wait a minute. How do you "go to it" without knowing the IP address?
Some anti-malware suites will help you here. (eSet has a nice tool, as standard, always running.) Or your router's web interface may have a page to help you.
One of both may have a way to see what's attached to your LAN at any moment. (Beware- some "attached" things "come and go" from such lists. But the lists are still useful.)
Before you attach the camera, go to your "what's attached" viewer. Get an idea of what is there now.
THEN attach the camera. If you are lucky, it will be easy to see the LIPA it is "on".
Open a web browser, if one isn't already open. Put the camera's LIPA in on the address bar, and something should appear on your screen!
That's hasty and incomplete... but may help some readers. I hope so!
Go back to Overview entry
Put the device at a static LAN IP address....
Long item. It will take some explaining to set the scene. Happily, actually doing the setting is usually a trivial chore.
Have you ever accessed the internet from your home on something other than the computer? (Other than some probably expensive direct connection to the internet via a smartphone?)
It isn't hard to do. If you have a tablet, or smartphone, and have connected to the internet by a means that only works when you are near (100 meters or so) your router, you are doing it.
And again... even if that isn't the case for you... Imagine you've done it? Please?
Hurrah! You've used a LAN! (Or imagined using one.)
The tablet and the computer are connected to one another. Just because you haven't used the connection doesn't mean that it isn't there. They are on the same LAN, a LAN created by one "side" of that "switch/router" box thingie.
The router has just one connection to the internet. Have you ever thought about how really cool it is that two devices (the computer and the tablet) can "talk to" the internet across one connection to the internet, and not even know the other device is present? That's where the "switch" part of the "switch/ router" name comes from.
When there is more than one device on the LAN, things that go across the LAN to the router to go off to the internet have to be kept distinct from the things coming from the other device. And when answers come back, they all arrive through one wire, to one place... the switch/ router. But it sends the right material to the right device. Magic! (Do you really want me to try to explain that, too, in other terms?)
You don't have to use connection to the internet
I have, at a quick, off the top of my head count, ten things all connecting to my switch/ router. And sometimes they are only "talking" to each other. They are all on one LAN, some with wired connections to the switch/router, some with WiFi connections, and, with the right commands, I can have them talk to each other with no "talk" going out of the house, off to the internet.
For instance, there is an Arduino which watches various weather things (windspeed, light levels, temperature). But it is a bear of little brain. One of the bigger computers uses it as the source of some sensor readings, and saves what the Arduino is seeing into a datafile.
A more typical local use of a LAN might be to have a shared printer. Now, you can have a printer connected to one of the computers on the LAN, and print "through" that computer. A more elegant solution (with problems I've never wanted to tackle, because the inelegant solution meets my wants) is to have the printer directly connected to the LAN. Then any device on the LAN can send something to be printed across the LAN to the printer, and out it comes.
The secret of addresses
"Things" in our modern, connected world, have "addresses". "Phone numbers" might have been a better term to extend, but "they" chose "addresses".
There are (at least) two sorts of address that are important to us.
The devices on your LAN have "addresses". They will look something like...
192.168.0.204
Four numbers. Separated by "."s Each less than 256.
Everything "on the internet" has an address. It will look something like...
157.12.121.27
Again: four numbers. Separated by "."s Each less than 256. (Although that is being expanded to be six numbers.)
When you go, say, "to Google", although you might put "http://google.com" into your browser, behind the scenes, "goggle .com" gets translated into one of those numbers. (It is, as I hinted before, a bit like telephone numbers... although the phone company has never rolled out a system to let us use "Joe Smith" instead of his number.
How does a poor chip know if an address is a device on the LAN, or out on the WAN??
Partly by context. Partly by the number itself. Something beginning 192.168.0 will always be something on the LAN. The LAN the "poor chip" is on. That's the beauty of LANs... MY LAN may have my printer "at" 192.168.0.72 while YOUR LAN may have your games console at that address.
These numeric "addresses" are more fully called IP addresses. ("IP" for "Internet Protocol".) In terminology I find useful, but I must admit I've never seen anyone else use, I add the terms LIPA and WIPA for "LAN IP Address", and "WAN IP Address".
We can leave the WIPAs for another day. Remember I said I was showing you how to put an IP cam on your LAN?
In simple circumstances, your router assigns a LIPA to any device when that device is plugged into the LAN. If your laptop comes and goes from your LAN, its LIPA might be one thing one day, and another a different day, and it might all work just fine.
Managing LIPAs this way is called using DHCP.
With an IP cam, there are advantages to saying "No thanks, I don't want this device given a LIPA automatically when it is plugged in. I want it to use the LIPA I've set in it."
You can't help the camera asking for a LIPA to be assigned by the router when you plug it into the LAN for the first time after doing a factory reset to the camera. (And new cameras come with a recent factory reset.) But once you've "got into" it the first time, I would suggest changing the settings, telling the camera to use a specific LIPA from now on.
That will mean that before you plug the camera in, you have, as talked of earlier, to tell your router to set aside some address for the use of devices which have been told DON'T ask for a LIPA to be assigned. Use the same LIPA every time.
And then you just give the camera a LIPA from the range of addresses the router has set aside.
You will need to keep a careful list of the LIPAs you are using for various things. If you have two devices on one LAN which both try to use one LIPA the result will be Very Tedious. (No harm will arise, but things will be "crazy".)
If you put things on more than one LAN, unless you have LOTS of LANs and lots of devices you want to assign static LIPAs to, you might want to consider reserving the LIPA for "camera A" across ALL your LANs for that camera. Yes! It is only on one LAN at a time... but if you have reserved the LIPA across all your LANs, you won't have to do any LIPA (re) setting chores if you decide to move it from one LAN to another, will you?
Enough theory! Let's do that bit.
Okay... here we go...
You've told your router to set aside some addresses for static LIPAs. (In other words, words you router might use, you have excluded those LIPAs from the pool of addresses used by the DHCP.)
That prepares the way for you to say to your IpCam: "Don't use the LAN's DHCP services, use the following IP address..."
MORE TO COME! Sorry for the sudden end... for now..
Go back to "Put the device at a static LAN IP address" overview entry
Put the device on a non-standard port....
Ports. I haven't explained THEM, have I? Sigh. If you know about ports, I don't have to say much. If you don't, and you're pretty sure that someone more knowledgeable hasn't been "putting things on" your LAN, you are probably okay with ports 1024 to 1032 for your initial work. I will use 1024 in this, but just like the LIPA: If you have used something else, use THAT where ever I use 1024.
If you haven't managed to change the port, (or have funked doing so!), you can put 80 where I put 1024, or just leave it out, along with the colon (:) which I will usually be putting in front of it. Go back to "Put the device on a non-standard port" overview entry
Configuring for WiFi connection to LAN
(stub for ConfigWiFi) Go back to Configuring WiFi overview entry
IpCam "inputs"
(stub for IpCam "inputs") Go back to IpCam "inputs" overview entry.
IpCam "outputs"
(stub for IpCam "outputs") Go back to IpCam "Outputs" overview entry.
"Programming" "If this, then that" behavior
(stub for "Programming" "If this, then that" behavior.) (I should repeat what I said in the overview entry: I'm not, here, talking about using the excellent IfTTT.com service. Go back to "Programming" "If this, then that" behavior overview entry.
Sending images to an FTP server
You don't need to be Google to set up a system where the images you camera captures are archived on a hard drive somewhere, by the protocols known as FTP.
An ordinary home user, with an ordinary domestic internet connection could do it.
In theory, if you use FTP to upload webpages to a web hosting service, you could have the camera send the files there... but I'd be reluctant to "play" with those ideas, because of security implications, and potential violation of your web hosting contract.
I'd start by setting up an FTP server on the same LAN as the IpCam. All you need is a computer (it could be doing more than just the FTP serving... but it would have to be on whenever you wanted to send images to it.
For software I would... indeed I do!... use the free Filezilla FTP server software. (Not be confused with the more widely used Filezilla FTP client software... the software I use for uploading my web pages to my web host.
I said start with an FTP server on the LAN the camera is on.
As with the cameras themselves, get this much working first. There will be challenges, and they all need solving anyway, if you decide to go further....
Further being having the FTP server at a different site that the cameras. Again, an ordinary domestic internet account is adequate. You'd need DDNS again, just as you did for WAN access to the cameras.
A detail...: If you embark on this, be very careful when deciding what permissions to give the user that you set up on the FTP server for the camera to use. Some cameras, hurrah, give you a "test settings" button in the part of the web interface where you configure the FTP settings. That test may very well always use the same name for the file it is, if the settings are right, saving on the FTP server. For that to work, the FTP user that the IpCam logs into the FTP server as must have permission to delete files, mustn't it? Obvious when you think of it. It took me a while to think of it. Sigh.
Another detail...: This is similar to the previous one: If your IpCam starts a new folder for each day's images... a new folder on the FTP server... be sure the user you set up for the IpCam's "use" has been given permission to create new folders! That was another "gotcha" that got me for a long time. (I wasn't following my own advice: The answer to why it wasn't working was there in the log files, when I finally went to look at them. Sigh.) Go back to saving to FTP server overview entry
Where did you have trouble??
I would be very grateful to hear from you. Where did you have trouble getting your camera working? What bits of this should (particularly!) be re-done. Any help you can offer could spare the next novice pain you had.
Page has been tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.org. Mostly passes.