ASI Internet Communicator

This is what I meant when I said Internet downloads should be easy. Done right it should be no more trouble (often less) than working over a phone line.

No it would be more difficult, you'd have to have a module on your end and know the IP address of his module which usually changes

Actually it all depends on what your are talking about. This particular module is just for reporting. Not remote programming. Now, as to an example of a module that allows you to program like Napco has (for their high end panels)... No you don't need a module at the other end. Just the latest release of the software that supports it loaded on a PC with a broadband connection. You do have to be able to find the module however. That requires either a static public IP address or a dyndns service application running on one computer on the network so you can easily determine the public IP address at any given time. (some routers also support dynsdns services directly).

Easier vs more difficult... that is relative. Depends on the knowledge and experience of the tech doing the job.

It depends on the equipment, for example a week or so ago someone brought up LoBenn which requires you to use a module connected to your standard download modem to connect, if the module is a dialer capture setup then it will be difficult

A static IP is fine however it won't be available for residentials, as far as determining the ip address it's not hard getting the ip of the computer however most computers use a router and few people have ever dealt with that. Add to that the need in many cases to open a hole in the firewall for incoming ip traffic and you've got lots of fun going.

Honeywell gets around all that by having everything go through them and their servers track the IP's of whatever connects to them, I've done a number of IP downloads through them

Since we're talking about future systems it's safe to assume the systems will include a means of locating the dynamic address. The most common way of doing this is the same as is used in cheap web cams. Each time the cam logs on the app contacts a dedicated site, sending it's ID information and IP address. This is simple stuff that's been in use on very inexpensive hardware for years.

Even if the module were for programming and/or remote control, finding a DHCP device is trivial.

Precisely. What I've found is that the

*average* DIYer is more capable or at least more inclined to acquire the skills and the knowledge to do it than the *average* alarm company customer. Very few who could install their own alarm would have trouble handling Internet functionality.

"It's so easy even a Texan could do it." (apologies to Geiko)

Steve's right... You *are* a Troll.

or even better than that is to have the unit send an email every time the ip address changes. you want to know what the ip address is check your email and there it is. no xtra dedicated sites needed.

Nice idea. One problem I can see is it would require that every device be assigned an email address. With a dedicated server you only need a connection. For an enterprising alarm manufacturer it could become an RMR stream.

Nope, any e-mail address with a pop server could be used easily and directly. The unit just includes a unit ID in the e-mail. Better yet, the remote client software automatically retrieves the e-mail from the pop server on opening that account and sets the IP address automatically before trying to connect. That part can all be done with software.

Using a mail server adds a lot of config. Many ISP's block outgoing port 25, so you would have to configure each unit with server, login credentials AND the destination email address. The mail server(s) becomes just as much an "xtra dedicated site" as what AZS has.

We've arrived at a similar architecture as ASZ, although we built it into our controllers directly and also moved the whole config UI out to our hosted web servers, so no need for any client software - just a browser.

Sounds like basicaly you are running a dyndns server or analog thereof.

Kind of. Similar in purpose anyway. Our servers keeps track of the controllers end point, and we use NAT punch-through to provide a bidirectional link. From the users perspective you're looking at all your controllers - live - from a single login on a single web page..

Why can't it work the same way as when you set up a DVR?

The Mfg hosts a site at no charge and keeps track of the DVR. When you want to log on from anyplace in the world, you use your browser to enter your pass word and you're looking at your DVR'd cameras. It can't be that hard to do. The central would have the server and ..... etc. Right?

I can't come up with a reason why that would not work...

We're moving all data through our back-end server, and bandwidth is not a big concern for us (we're just moving config, control commands and some audio streams). To get higher throughput for the video you'd probably want to to a hand-over to the client instead of relaying everything through the server, but there are proven methods to do that (P2P clients), so there is nothing that needs to be invented.

I'm not even sure why you are using a third party server for DVRs. All you need is reliably IP info and to setup the router. When I install a DVR I setup dyndns for them transparently, and if they don't already have a router I provide one that supports it directly. They always connect directly to their DVR. So far I have been able to talk many a client through setting up and using client software over the phone. I've got DVRs in two countries that are viewed all over the world.

Obviously DynDNS also uses a third party server, so it's really the same thing. The big benefit with a more integrated system is that don't have to convince the paranoid IT guy that you need to reconfigure their firewall...

yep

one I'm already paying for.

so this roc will forward alarm panel communications over phone, cell, or net?

The ROC is a controller in itself. It's built for technical/industrial alarm applications. It's not intended as an add-on for a burg panel, but we have one application where a panel maker asked us to interface to a serial port on their system and suck out the reporting data, which works of course, but is a bit overkill... The technology we have developed would be perfectly suitable for a burg panel though, and since we have our roots in the burg industry, we hope to apply our technology in a panel someday -- just looking for an opportunity :)

Thats how Napco does it with their video module however that's easier said than done and why at not charge? Bandwidth isn't cheap.

One problem for the manufacturer is someone hacking into the website and viewing your customers, very unlikely to happen with a direct to DVR path