brad77

You can't use http and https interchangeably. If you are connecting to your ISY's non-secure port, you must use http. If you are connecting to your ISY's SSL port, you must use https. There's no getting around that. If you make a non-SSL http request to the SSL https port, your ISY will reject that request. It's not your Blackberry's fault. HTTP and HTTPS don't just specify ports. They are URI schemes that tell the browser (client) and the server how to connect. When you connect to 443 using http you are getting the port right, but the URI scheme wrong. Also, your carrier might not be blocking all "non-standard" ports. It may just be using those ports or reserving them for something else. If you wish to use something other than 80 or 443, I recommend using a port higher than 1024 and lower than 49152. For example, if you used 1780 for http and 1783 for https, you'd address them like this: http://yourip:1780 https://yourip:1783 Lastly, I would recommend that you only use the SSL when connecting from outside your home. Connecting via http will send your username and password in the clear, which could be intercepted by someone sniffing your traffic.

It could be. Have you tried different ports? Perhaps your carrier is blocking ports 801 and/or 806.

As far as I know, you can only use the ISY's web space to serve up static HTML, so unless you can work miracles with Javascript, you're out of luck. Linksys WRT-54GL routers are designed to support custom firmwares that may offer web servers and scripting/programming language support.

Quick update: Installed the fan and it really makes a difference! So far so good regarding INSTEON as well. No reliability issues to speak of while the fan is running...yet. I was wrong about the voltage as well. The switch is rated for 250V in the "high" position, but the fan only uses a standard 110V power source. I'll update if/when I get the timer/programs sorted out.

I suppose that you could poll that often, but that might not be a good idea. Querying does send traffic over your INSTEON network, and it might be possible to cause collisions with other traffic if you query overmuch, which might effect reliability. I'll let others chime in as to whether or not that's a legitimate concern. Regarding the wiring of the "dummy" switches, I misspoke (mis-wrote). The switches need to be hooked up to the line and neutral to receive power and to communicate. You just wouldn't need to hook up a load in this situation as the switch wouldn't actually be powering anything.

You could install a standard INSTEON switch in the room that toggles the unit on and off. That switch only needs to be connected to the neutral (common) wire and could be installed side-by-side with an existing light switch. The on/off commands sent by that switch could be used to synchronize your keypad and vice versa. I'm not as familiar with keypads, but you should be able to put all three devices (keypad, switch, Appliance/OutletLinc) into a scene so that they change together. Alternatively, you could create an ISY program that queries your OutletLinc/ApplianceLinc modules to determine their status and updates your keypad accordingly. That program could run every 30-60 minutes or so to keep things in sync. You just need to ensure that your people don't turn the A/C unit on and off at the unit itself, but via the button on the ApplianceLinc or OutletLinc.

What is it that you are trying to accomplish? It sounds like you have two different questions: 1. Using HTTP GET and POST in the network module 2. Getting content onto your ISY's web server I'll address #2 first, as that's the simplest. As far as I know, the ISY web folders are only accessible via the Administrative Console. There is no FTP server to speak of. As for #1, forgive me if I'm telling you something that you already know. Here goes... The network module is capable of sending requests only. Although you can retrieve the contents of a URL, you can't do anything with it. I presume that any data retrieved is immediately discarded. I think that the main idea behind the module is to send requests to network enabled devices that can respond to simple HTTP commands. Normally, this data is communicated by hitting a certain URL and optionally sending a script parameters to let it know what you want it to do. You send the parameters via the URL with an HTTP GET or using name value pairs encoded into your request with an HTTP POST. The former looks like this: http://somedeviceorserver/somescript.cgi?arg1=value1&arg2=value2 The arguments are passed in the URL itself and are found after the question mark. They are highlighted in boldfaced type above. HTTP POST requests are usually sent by a form on an HTML web page. This form has a submit button that then URL encodes the contents of the form into a request that is then sent to the target via an HTTP POST. The target of the POST then parses out the parameters and decides what to do with them. Since we don't have a form to send the HTTP POST because we're sending it via the ISY, you need to put your URL encoded key value pairs into the body of the request. These values will be in the same format as the HTTP GET. To send the same arguments as are used by the HTTP GET example above, you would put the following into the request body: arg1=value1&arg2=value2 This describes URL encoded text (corresponding to the MIME type "application/x-www-form-urlencoded"). When sending multiple parameters in the body of the request, you must use "Raw Text" mode for the network resource so the ampersands ("&") used to separate your parameters aren't encoded. In some cases, you might have to try using Binary or C-Escaped modes if that's what your device expects. Lastly, I mentioned "URL encoded" more than once. If you are using Raw Text mode, you probably need to encode your parameter values yourself so that you don't send junk data through or accidentally send special characters that mean something other than you intend. There are a number of tools on the 'net that can help you with that. Google "URL encoder" and you'll find something right away. Hope that helps!

To add to marksanctuary, one of the ways scenes are helpful is that they reduce the amount of traffic moving over your INSTEON network. For instance, a program turning on three relay switches could look like this: 1. ISY -> Switch A: Turn ON 2. ISY -> Switch B: Turn ON 3. ISY -> Switch C: Turn ON If, however, you link these devices together in a scene, the ISY only needs to do this: ISY -> Scene ABC: Turn ON I'm simplifying a bit, but hopefully you'll get the idea. In both cases, the individual devices will send their status (think "I'm switch A and I turned ON") back to the ISY, but the original request only requires a single "transmission" on your network, and thus less time to execute.

No worries on the mixup. They are all good ideas. The fan itself has a 1/2 HP permanent magnet motor that operates at two speeds, the second of which requires 220V. After evaluating it, I don't believe that I will be using the high speed mode because of the suction that it might create!

Thanks, IndyMike. The fan install is in process and this is something I've considered. Provided the windows were open, I would love to have the thermostat kick off the fan based on the internal temp. Though convenient, I don't know if it will work as I see a couple of problems with this approach: 1. The windows must be open or the fan will draw air from the fireplace/flue 2. I intend to use a Venstar thermostat with the INSTEON dongle 3. The outside temperature must be lower than the inside temp (or at least close to it) for the fan to be effective. Otherwise, you're just drawing hot air into the house This fan will be an alternative to A/C. In fact, being somewhat close to the coast, I do not even have an A/C unit. As such, I should be able to leave the cooling contacts unconnected (they wouldn't go anywhere anyway) and monitor the "cool" request on the ISY. Then, it would check WeatherBug for external temperature, Elk for door/window open status (requiring the highly anticipated ISY Elk module), and fire up the fan if all conditions are met. Stopping "cool" would shut off the fan. I do not yet have a Venstar thermo. Does anyone know if it broadcasts the cool on/off requests to the ISY?

Thanks for the ideas, dbroere. Once ELK support is fully available, I can use my M1 Gold to detect when windows are open. That coupled with some thermostat information could go a long way to getting the temperature in my home to a reasonable place at night. I suppose that I'd also have to be aware of whether it is raining or not, as I wouldn't want to draw any errant raindrops in through the windows during the half a dozen times that it rains here. Thankfully, I don't really need to check the external temperature after sundown as I live in southern California. It's almost guaranteed that the exterior temperature will be lower than the internal (provided that the internal temp is above, say, 75 F) in the evening. Humidity is rarely a problem. On that note, my fan has two speeds with the higher of the two requiring 220V. Has anyone had any luck with any of the high voltage relays from Smarthome?

No worries. I figured as much. Thanks for the contact info.

This is the second time that I've heard of this device. I presume that it serves to make a smaller version of that double I/O Linc soldered into the key fob. Is that right, or is there additional two-way communication? Also, how does one become a beta tester for this? I've got a couple of these locks and would like to try this.

That's strange. The certificate error is common, as the certificate authority used by the ISY's self signed cert isn't trusted. Can you confirm that the certificate error is indeed coming from you ISY? Try viewing the certificate details when you get the SSL error in your browser. Also, have you tried regenerating your ISY's self-signed cert just In case?

Anything with a browser will work. I've used a Motorola Q before, but the experience is most definitely less than optimal. I currently use a Droid with the ISYAjax web interface and it works quite well. I resume that it would work on any device that supports Javascript, but is optimal on touchscreen devices.

I think that you are still confusing some things. First off, did you use the same external IP address that you are using to access your ISY in your DynDNS setup? If not, that's a problem. I'm a bit unfamiliar with the format of the host name "hostname.ath.cx.dyndns.org". On your DynDNS account, you are asked to enter a host name, then pick a DNS host suffix (the DynDNS.org part). Put the two together and you have the full URL that you should be using. Your computer has an internal IP address. Your ISY has one too. They are different addresses. What we're trying to do here is access your ISY, not your computer. It is not necessary to configure your computer to have a static IP address. It doesn't hurt, but it is not necessary. What Rand and the others were suggesting is to set up a static internal IP address for your ISY. You then set up your router to forward port 443 to that static internal IP address. Then, you set up DynDNS. Lastly, set up a software updater on your computer to keep track of changes to your external IP address. When you do this last part, be careful about how often you update your address. If you do so too much, DynDNS will suspend your account. DynDNS doesn't need to know anything about what ports you plan to forward. It is used to connect an easy to remember host name to your public IP address. Nothing more. As I mentioned before, each device in your home (internal) network has a different internal IP address. However, all of those devices share the same external IP address. That is to say that there is only one public address on the internet pointing to your home network. This should help explain why you can do some of the setup on your computer. Both your computer and your ISY share the same external IP address. Fundamentally, you are telling DynDNS the public (external) address of your entire home network, not just your computer.

Yes. It will not start in the middle of the program. Each time you run a program, it will start at the beginning.

Yes, this is exactly what Rand was referring to in his recent post. Unless you are plugging your DynDNS username and password into this feature on your router, I'm fairly certain that this isn't where you do this. Either way, I'm glad to hear that you have figured things out (mostly).

Yes. When I say "with updates," I am not referring to a box you check when setting up the account. I'm referring to an application that updates DynDNS periodically with your external IP address information. No. I'm really not sure what you're talking about here. Perhaps it's related to quality of service (QoS) or something like that. You shouldn't have to do anything here. You're OK here. The remote port option allows to to translate an external port to an internal port. This is useful if your ISP is blocking a certain port. You shouldn't need to worry about that at this point. You do not need to log into DynDNS to get this information every time you need it. When you set up the account, you entered in a host name. That is the name that you should use to access your ISY. It should look something like this: https://yourhostname.dyndns.org Make sense? In this case, you'll replace "yourhostname" with the host name you set up with your account. One of the points of setting up DynDNS is that you no longer need to use the IP address. If the DynDNS account is up to date, you only need to use the friendly, easy to remember host name you set up. Continuing to use the numberic IP address defeats the purpose of this as it will break as soon as your ISP changes it. You still must set up an updater. It doesn't look like your router supports this, so you should install an application to keep DynDNS' records up to date with your external IP address. Refer to the link regarding the DynDNS updater application in my previous post (hint: it's the last word in the post).

It sounds as if you've almost got it. If your ISY device has a DHCP reservation (see Rand's post) or a static internal IP address, you don't need to worry about your ISY's address on your home network changing. With that problem solved, you still need to address the issue of external access. To solve this, you will probably need to do two things: 1. Set up port forwarding on your router 2. Set up a DynDNS account (with updates) Forgive me if I'm going over ground that you've already covered, but perhaps a different perspective will help. In a typical home setup, you have one external IP address. This means that as far as the internet is concerned, you have only one address that can be used to access your home's network. You can have dozens of IP enabled devices in your home, each with a different internal address, but none of those can be seen by the 'net. Any connections coming from the internet must go through that single external IP address, which points to your cable/DSL modem, which then gets passed to your router. Your router then decides what to do with the request. Most of the time, it ignores it, which protects you from unsolicited requests/access attempts from the internet. Since your ISY is on your internal network, you need to set up port forwarding so that your router knows to send requests meant for a specific port (in this case 443) to your ISY. In order to "see" the ISY from the internet, you must forward the port to your ISY if it is on your internal network (that is, not directly connected to your modem, which it is not in your case). With that done, you can access your ISY from the internet using the external IP address assigned to you from your ISP. However, if your ISP changes your external IP address from time to time, or if you simply want an easier to remember name instead of a bunch of numbers, you'll need to set up dynamic DNS. That's where DynDNS comes in. Set up an account with them and you can then use the address (host name) they provide to you to access your ISY. Your last step after setting up your DynDNS account is to set up your router (or an application on your PC) to update DynDNS with your IP address whenever it changes. That way, you don't need to worry about keeping up with the external IP address your ISP is giving you. All you need to remember is the DynDNS host name that you set up. Setting up updates on your router is different for each router brand/model. It may not even be supported on your router. If that's the case, you'll want to opt for a software updater, which can be found here.

To add to Rand's very comprehensive post, the TTL is an acronym for "time to live." You shouldn't need to worry about changing this value. DynDNS sets this value very low (60 seconds) so that changes made by your router or DynDNS application are propagated to other DNS servers throughout the internet very quickly.

Thanks for posting, io_guy. I'm about to install a whole house fan and I'm considering setting up timers for that to run for a short time in the evening. Once I get that installed, I'll refer back to your examples. Now I've just got to address the issue of airflow. I don't want the fan to draw air from my fireplace! It would be nice if strategically placed vents could be opened in tandem with the fan starting up.

This piqued my interest. Would you mind elaborating on this? Is this because of your specific needs or an issue with Elk systems in general?

I'm assuming that by timers you're referring to programs. Could you please post an example of your timer program(s)?

Good to hear. I just wanted to add that adding FilterLincs and AF-120 filters went a long way to making my installation much more reliable. Not only do they isolate noise, but they prevent "signal sucker" devices from sapping your INSTEON signals.