oberkc

Perhaps I am missing something here, but let me clarify how it works at my house. If I am on wifi or ethernet on my LAN, I use only one address: http://192.168.0.33:88/ or https://192.168.0.33:555/. Both get me to my dashboard. The secure port gives me a certificate error, but I have never attempted to resolve that issue. Both of these ports match what is in the ISY and router. External access is through an entirely different IP address. When I connect externally, I use the external ip address https://70.aaa.bbb.ccc:port , using the SAME port numbers as when internally. Now that is appears you have both secure and non-scure ports working internally, do you continue to use the https://50.xxx.yyy.zzz:59876 address externally? Have you checked this address more recently through whatismyip? Is it possible that your ISP has changed it?

you might try https:// rather than http://. Is port 443 a secure port? In case you missed it, there is actually a sticky topic under how to. In that sticky topic is a reference to: http://portforward.com/ Where this likely describes the setup in your particular router. Both are worth checking out.

Yes...each motion sensor has three: motion, light, and battery. For this project you only need worry about motion. For future reference, you could use the light sensor to identify when it gets "dark" and you can use the low battery as a trigger to send you a message telling you that it is time to put in a new one. Yes, I suspect this might take more than one program. I am not convinced that a variable is needed, but sometimes that is a programming preference for some. I suspect that the use of variables makes the logic easier to follow in many cases, but I have found few cases where they are truly NEEDED. The first part is to get your sensors located where you want and confirm that they react as you expect, and that they communicate reliably. Beyond that, a program would probably look something like if control "motion sensor 1" is on <<<"motion sensor 1" would be the name you give it then wait 15 seconds run "this program" else path <<< "this program" would be the name you give it else A second program looking for motion on the next motion sensor if control "motion sensor 2" is on and status "this program" is true <<< "this program" refers to the first program, not the second then do whatever you want else nothing There is a suggested approach that can, potentially, create some ideas in your mind. The syntax is not exact, but the ISY will create the right wording. No variables...no mess...fun!

in those pretty, little icons along the top left, the two right-most symbols are where one enables and disables the mode to write changes to devices. One is for battery powered devices, the other is for the rest.

Unfortunately, we are reaching the limits of my knowledge and experience. In your port forwarding rules, I note that 59876 is listed under "range". And you have 443 under "local port". None of these terms show up in my DLink port-forwarding rules page. I am also curious what it is that your ISY settings for secure and non-secure ports are? Is one of them 59876? I believe these need to match. Have you tried 443 as a port number: https://50.xxx.yyy.zzz:443/

It is a simple program. The problem that typically comes up is when a path (THEN or ELSE) retriggers the program, but unless the scene "basement LED off" or "hutch LED on" includes devices that are part of the programs condition, then this should not be a factor. Have you tried any experiments to further isolate the problem? Have you tried manually executing the THEN or ELSE paths to confirm that they work? Have you watched the program state from the ISY to see whether it is executing? Have you confirmed the ISY-presumed state of your devices match reality? If the program appears accurate (and it does to me), then I start looking for other potential issues.

My experience is that, in addition to the steps described by kman, one must set up port-forwarding rules in the router to match the ports defined in the ISY. In doing so, be aware of the other devices on your network and ensue that there are no other devices trying to use the SAME ports. It is likely best to use ports other than 80 and 443. Once established, the address for your ISY when outside your LAN would be: Https://myipaddress:mysecureportnumber/

These are all good questions. Yes, your understanding is accurate I believe. Unfortunately, reality collides with theory based on my experience and what I read around here. Xathros ably explained many of the benefits of access points. I would add a couple more: flexibility of placement for phase coupling, and flexibility of placement for RF coverage for use with other RF-only devices such as motion sensors and remotes. Theoretically, once you have two access points, you can add as many more (even having an odd number) as you need for the coverage concern. My experience confirms theory in this case.

That is the general approach I would take. My only concern with this is how consistently the motion detectors accurately sense motion. For me, I have found the insteon motion sensors are pretty good when a body crosses the field of view, but less reliable detecting cars. In what way are the motion sensors driving you nuts? Are you looking for thoughts beyond confirmation of the approach?

I see two things that immeditly concern me. First, then version of one of you switches is v0.0. This suggests to me that your ISY did not recognize the device. What ISY firmware version are you running? The second is that you appear to be getting response "sometimes". My first reaction to inconsistent response is to suspect comm problems. Do you have two access points confirmed on opposite LGS of your electrical system? Do you have your PLM plugged into an outlet or circuit that includes lots of computer stuff?

That makes it simple...and even more puzzling. I see nothing that would cause your tree lights to cycle on and off. Yes. If they are a scene, you would see a scene definition with a combination of controllers and responders, from one to many. In other words, these would be devices that are linked together. How long have you had the ISY? Did you manually create any scenes before you had it? Did you clear those scenes away once you added the ISY? so the spot program is staying true, but you continue to see the tree lights cycling?! Something very strange is going on, and I cannot help but suspect it is unrelated to these two programs.

This is still not an exact paste of your programs. Is front spot a device, or a scene? If a scene, what are the included devices? Is X-mas tree a device, or a scene? If a scene, what are the included devices? Honestly, I am unable to identify anything that would cause your programs to loop, at all. Is it possible that you have other programs that are calling your spot progam paths, causing it to toggle between true (then) or false (else)? I think I would watch the program summary tab, and see if there is any evidence that your spot program is changing status from true or false at times other than your expected times near sunrset and 11XX

In the case of android, tasker handles the geo-location duties. When tasker senses crossing some threshold, it will call on mobilinc to perform the insteon duties. My experience that the state of mobilinc matters not at all. Tasker runs in the background.

Since you did not respond to my, or purdueguys, suggestion to post your programs, I can only offer generalities and assumption that may or my not be accurate. I would delete this program and I corporate you Christmas tree into the spotlight program.. If Whatever conditions you currently have Then Turn on spotlight Wait 10 minutes random Turn on Xmas tree Else Turn off spotlight Wait 10 minutes random Turn off Xmas tree

With insteon, there is no such thing as scene status. Mobilinc, however, creates an artificial status. It is my understanding that the ON level represents the percent of devices that are in the scene and ON, and may also further be proportional to the level at which the devices are ON. I have not had a lot of use for scene status in mobilinc, and recommend you do not put too much stock in it unless you understand exactly what it means and how you intend to exploit this information. Basically, if the scene level is at something higher than zero, you can conclude that some or all of the devices are on at some level. Your experience appears consistent with mine. You have two switches in a scene. One is on. One is off. This sounds about like 50% to me. Have you been controlling the individual switches? They will only act as scene controllers when activated manually. Yes. If your intention when controlling the scene is that both lights go on full, and this does not happen, then I would check the ON levels in the scene definition. From the ISY admin panel, select the scene in question. In the main panel you should see all the included devices, and the ON levels for each. Is one set to zero?

Since these are obviously not the exact programs, it is hard to tell whether we are dealing with scenes or devices, status or controls. It would be extremely helpful to see both programs in their true syntax. It would also be useful to know the devices in any scene mentioned in the relevant programs. When one have a device or scene which turns off and on and off and on, I tend to suspect that something in the THEN and ELSE paths are changing one of the program conditions, which re-triggers the program. Is it possible that when you turn on and off the Xmas tree (device or scene?) you are causing the spotlight program to change states?

In case it was not clear, controllers in an ISY scene are, by default, also responders. There is no such thing as controller-only, except for when the device, itself, is so limited. So...yes, a KPL button as controller in a scene will respond to other controllers in that scene. The concept of a "scene" has always had a little different meaning, in my mind, when comparing an insteon scene to a scene created in the ISY. Insteon scenes struck me as a link between controller and single responder. In this construct, controllers could control multiple insteon devices, or scenes. With the ISY, the scene is the entire group of devices controlled by a common controller, or multiple common controllers. I found it pretty easy to get used to.

This is, actually, quite simple, requiring no program. You have an ISY scene that includes your dimmer and socket...correct? Simply add to that scene the remotelinc, as controller (only way it lets you, I believe). Be sure to eliminate the programs you created.

I misunderstood. I would not count out this keypad quite yet. I don't believe these problems are related.

Yes, this is the correct access point. Don't forget your filterlinc.

I agree with the assessment regarding the KPL being defective. You can try factory resets, however. Sometimes one can get lucky. Does ANY button work or is it non-responsive to all button presses? Since you use mobilinc connect, you may also try contacting mobilinc to see if they have any suggestions.

BAsed upon what I am thinking from your posts: a) you should filter your computer equipment. The fact that your system worked when you located it away from there suggests that your computer stuff interferes with the ability of insteon to communicate. make sure you have two access points, on opposite legs of your electrical system, in order to communicate between the two legs. You should be able to add your IOLinc continues to suggest marginal communication. If you cannot add your IOLinc via the "start linking" steps used with the appliancelinc suggests upcoming problems when adding manually.

Ok. The next thing I would try is, within mobilinc, to sync with your controller. I believe it is under settings>>>controller (or similar). Syncing with your ISY is necessary any time changes to a program are made. The may also be other times.

I just checked mine, and it DOES allow manually setting ports in the ISY configuration tab. Please note that mine does NOT have automatic DHCP selected. See you when you return from your missions.

But just to be sure... When I choose "start linking", the choice to "remove existing links" is already selected. It is NOT something I have to select afterwards. If your devices continue to flash, I tend to start thinking comm problems. My experience is that being close to the computer is BAD, due to proximity to lots of power supplies, UPS, surge suppressors, etc. I consider it near mandadory to filter these kinds of things. Instead, get an extension cord and plug it into another outlet on another circuit. Plug the PLM into the extension cord. Plug the appliancelinc into the same outlet. Try linking again. Hopefully this will help.