oberkc

To continue the thought process started by LeeG, you may also consider a combination of things... Perhaps you would choose to use a scene to directly turn them on from a motion senso (perhaps a little quicker responding) and a program to turn them off. Make sure you explore the "options" for the motion sensor. You can configure the motion sensor to only send an ON command, using the ISY to shut them off after a period of time. But...you don't want both a program and a scene to turn them off. But, my preference is like Michel's: keep it simple. I would even go simpler than his example If Control 'Main Bath Motion.1-Sensor' is switched On Then Set Scene 'sMain Bath Lights' On Wait 4 minutes Set Scene 'sMain Bath Lights' Off Else - No Actions - (To add one, press 'Action') Like LeeG suggests, make sure your motion sensor is not part of any scene, and make sure it sends only ON commands. Unless you have some specific concerns (such as power failure during 4-minute countdown or need some type of manual override), I would expect this to work fine.

Yes, you would do this via a scene. Make the sensor a controller and rest responders. Depending on other factors (such as whether you want ISY to turn them off or take other action) you may need to configure the motion sensor to send only ON commands.

I see continued development. Micromodules have been recently released. 220V50Hz devices are now available. Over the recent years, we have seen the migration to dual-band devices. I see no signs of a near-term demise of insteon. Still, it is hard to predict the future.

If the EZIO is similar to the IOLinc in this regard, "Inputs" cannot control anything. Only the relay outputs can.

Yes, I think that is a unique capability to the iOS version of mobilinc. With Android, one can use the tasker app, now integrated with mobilinc, to initiate such triggers. I am not entirely sure if the iOS version allows location based on proximity to certain wifi networks, but tasker does this.

Yes. This is generally consistent for all programs. Conditions are triggers. One needs to understand how each condition triggers a program evaluation. Once triggered, it will either evaluate True (run then path) or False (run else path). Well, then, you will have to decide how to tell the ISY that you are home. I use a keypad button. I have experimented around with using cell phone location. Perhaps motion sensors? Garage door status? However you decide to do it, you would have to update your program: if I am away and time from 530 for 2 hours then....

I had no idea. This is not the case with the IOLinc. Plug it in. Add it to the ISY. Go. I guess I would consider this an advantage.

I also suspect that sending an insteon command from the ISY is more tolerant of local interference than listening for a status message from a remote device. Given this, do you have other insteon devices? Does the ISY have any trouble hearing from them? Is it possible that you have some devices on the same circuit as the PLM which might be obscuring the status messages?

It sounds as if you have asked all the right questions. I might perform a "show links" from one of your devices and compare to the ISY records. If there reveals a mismatch, the only thing I can think would be to restore one of the devices to see if this solves your problems. I have no idea if this would help, but it is not overly difficult to do, and with little risk.

I use an IOLinc, but have no EZIO-anything, so have no first-hand experience which could indicate one being better than another. I can say that my IOLinc seems to communicate pretty consistently, and that I recall reading no posts around here to suggest speculation that the IOLinc is more robust than one of the EZIO-series modules. One thing that strikes me as strange is having "isy991 with 3.3.10 and 4.05 ui ". Do you have an ISY-99 or -994 (I am not familiar with a -991). If -994, my temptation would be to update to latest software, in the hopes that this would solve your problem.

Not that I would expect. Purchase a second filter. Plug the HDMI matrix/switch into a filter, which would then be plugged into an appliancelinc. Plug the appliancelinc into an outlet outside your power strip (possibly even the same outlet as the PLM). I suspect this would be cheaper than purchasing one (or two) more access points.

The only one that I know about is on the wiki: http://wiki.universal-devices.com/index ... r_Messages

Phase test sounds performed correctly to me. My understanding is that nearly all houses in the US have two legs from the electrical system. Numbers of electrical panels does not matter, so long as you have bridged those two legs...which you have done. Your testing of the PLM is quite revealing. Since you prefer the mechanical room location, I would focus there, and on the six suspect devices. First, run the scene test several times. If it passes some, I would declare victory and move on to other things. If it failed consistently, I would take the time to search for a cause. First, I would filter your computer stuff. That type and absolute quantity of stuff is almost certainly causing some problems, and I would hope to knock it all off from a single filter. Once done, identify the circuit(s) on which the failing devices reside. Seek out other suspect electronics on that circuit. Temporarily unplug any to see if the situation improves. If so, filter those. Finally, given how important is the PLM, I would take extra precautions to ensure a clean circuit for it. Temporarily unplug all devices and run some scene tests to see if there is any improvement. If so, filters are cheap!

I believe you got bad advice from smarthome. Odd and even circuits are not necessarily on different "phase". My suggestions stand....perform the access point test in the manual to confirm and check to see what other devices are plugged in the same circuit as the PLM.

As Brian H mentioned, there are instructions in the user manual to determine whether your access points are on opposite phases. It is worth confirming. The other common problem is that folks can install the PLM on a circuit with lots of other gadgets and electronics. This can interfere with insteon communications. Yes, there are solutions if this is your case.

Program folders are really nice method to keep things organized.

My experience is identical to Xathros'

You can remove the remotelinc from the ISY. Instructions for this are in the wiki: http://wiki.universal-devices.com/index ... ice#Remove You can "factory reset" the remotelinc. Instructions for this are in the manual, as well.

I did not confirm on my devices, but I believe you make sure a given device is out of all scenes and folders. Once out, right-click on that device and remove from ISY. Factory restore the device, then add back to ISY. My favorite method is to put ISY into linking mode (add insteon device) then put the to-be-added device into linking mode. This should create a new entry in your "my lighting" tree.

I am still a little fuzzy on the relationship between firewalls and antivirus to the ISY, but anything new here in your setup?

My understanding is that insteon is intended to be "scene" driven. If you already have a scene with button A and a load controller, then, rather than your program turning on individual devices, such as the water heater and button A, have your program turn on the scene which includes button A and the water heater. Same approach for the other buttons/scenes. If Control 'KeypadLinc - HomeAway' is switched On And Control 'KeypadLinc - HomeAway' is not switched Off Then set "water heater scene with button A" on set "audio system scene with button B" on etc.... else set scenes off.... Alternatively (and potentially better), you could simple create a master button scene that has main button as controller and all the other devices and secondary keypad button as responder. Taking this approach would require no program.

I don't recall whether I have used this, but there is a program (true or false) condition which I assume can be used to trigger an email message. I can only assume (without refreshing my memory) that is works similar to a "status" in that it would trigger only when changing status .

andrew67 Unfortunately, when we left the world of dumb switches, I believe we accepted these types of problems as the cost of admission. And it gets worse. What happens if smartlabs goes out of business and takes with it insteon? Until we can convince the rest of the world that insteon is the correct way to go, and until insteon becomes open source, and until we can convince people that new features and capabilities are not needed...this is the world in which we live. It is still worth it to me, but I mitigate this risk by wiring in such a way as to allow reverting back to dumb switches. The biggest benefit of the -994, to me, is the growth potential into protocols other than insteon. I just hope that this potential is realized.

One reason that it may not run is tasker. Watch for your location profile as you near home. Does it become active? Are you using gps? WIFI? Cell towers? I think, too, that there are settings governing the frequency that tasker checks for proximity. It could be that this setting is too long, and it is simply not triggering the mobilinc command quick enough.

To expand upon LeeG response... From tasker, you can specify which program path to run, either IF, THEN, OR ELSE. No need to enable the program. If you want a program to run whenever you enter you specific geographic area, simply run run the THEN path of the program.