oberkc

In this mode, the button will not turn itself on. If it comes back on after turning itself off, then something is commanding it to do so, either by it being part of a scene and a program turning on the scene, or someone toggling that scene somehow. I strongly suspect you have something funny in one of your programs that is commanding this button to come on. I doubt that resetting and restoring this device will solve this problem. I would take inventory of this button in two ways: - identify all the scenes that this button is part of, and whether there are any controller devices part of those scenes. - identify any program that triggers any of those scenes. Feel free to post the results of your inventory and of the programs. I suspect someone can find the problem.

I still get things wrong and continue to learn (or relearn) things here. Questions are usually welcomed and helpful. Besides, your question was completely understandable....the wait (and repeat) statements can be tricky until you learn to exploit them fully.

I am sorry, but I am unfamiliar with a couple of these settings. From where do you access these settings? Are these paraphrased from the "options" available via admin panel selection of the IOLinc? Why did you enable the "relay set via sensor input"? What do you believe this option does that benefits you? (it sounds like a potential cause of your door opening by itself.) It sure seems that things have gotten complicated in your case. My suggestion is to back up a step and describe WHAT you want to happen? Do you want the button B to consistently reflect door status (is open=ON or open=OFF)? Do you want a single button press to trigger the door? Have you read the wiki article describing the suggested setup for this?

I suspect otherwise. If the status of the sensor turns off during the wait period, the program will retrigger, evaluating false, and the message will never be sent.

Does the program not work? For a door sensor, "ON" and "100%" should be same. Alternatively, you could try "NOT OFF".

Why not: if status IO sensor is on then wait 15 minutes send notification else nothing

If your PLM includes RF capability, then it might be enough, indeed. It would depend on how far apart are the PLM and leak sensor, as well as what is between them (walls, floors, etc...). Have you successfully added the leak sensor to the ISY? If not, and it turns out you are unable to based upon the location of the two devices, then I would temporarily move them closer together and link them. Once added, a couple of range extenders might be a good addition to your insteon system.

No, not too hard. Someday, i may try it.

If you dont want to add KPLs, and if you have access to andoroid tablets or cell phones throughout the house, you might be able to create a screen widget to toggle an ISY program to act as a unique device. This may require apps that you dont currently have. Others have mentioned the echo, but this requires a portal subscription or extraordinary effort.

Yes, check status of key devices in a scene. That would work. Dedicated device certainly would work. Motion in certain rooms? Doors open oe closed? You will have to identify certain key events or conditions as indicators that you want to halt execution. No, you are not overthinking this. This will take a few extra programs.

I have never viewed the routine use of a cell phone to control lighting to be a "simplification". Automating the lighting to come on correctly and without (or limited) human intervetion is my idea of smplification. Perhaps having the ability to control things,while away is a nice convenience, but even that is, arguably, an increase in complexity rather than a simplification, offering a capability not available before. I must be in the minority...I still find mobilinc (android) the superior app for my purposes. Tasker integration and widgets are a major selling point for me that the others lack, last I checked. Neither do I get all that upset because an app does not keep up with the ever-evolving tastes of jony ive, but is otherwise functional.

oooh! Never wrap wire nuts with electrical tape. I also read that on the internet. The rest sounds really good. I should hire you to do my electrical work.

I will be checking out your service panel, so be sure it is nice and organized.

I will have to try it the opposite way to see if I can get mine to fall apart. For some reason, I have never tried to twist them in the opposite direction but I am always interested in expanding my experience. I have always found it interesting to open up some wiring and find conductors beautifully twisted together and cut at the same length afterwards. I always felt that I was looking at the results of someone who took pride in their work. Perhaps that, alone, is enough reason to twist them together (in the correct direction, of course) beforehand.

Clearly he would be an advocate of pre-twisting, yes?

In my limited (but sufficient to also have a superior point of view) this about sums it up. I have had enough connections pull apart that I always tug on them after initial assembly. More important, I have found it good to ensure that the conductor ends a the same point and fully engage. Like Larryllix, I have found that, once twisted together via wire nut, regardless of pre-twist or not,upon inspection I found the conductors twisted together quite well. Still, from time to time, I twist them together beforehand. It just depends. I must not be religious, either.

Oh no. Another religious argument. To pre-twist or not. My perceptions are that both have strong advocates, and both work if done properly. At least that is what I read on the internet.

I dont use any portal, so I will refrain from offering second-hand knowledge. For remote access one can use one of the apps, with or without a portal subscription, or a web browser. Avoiding the portal requires a bit of extra work with router settings.

I use mobilinc on iOs and android for the limited times I desire remote access, but believe you can log into the native admin console or dashboard when away, just as if you are at home if you have access to a laptop or similar. Doing these things requires one to do a little port-forwarding magic with their router (a step rendered unnecessary when one uses the portal subscriptions) and a static IP address is always nice from you ISP (or using a service for this). There are also security certificates one must deal with if wanting to use a secure connection. If you have done all the port forwading and other stuff, you can also use a web browser and log into a web-based interface from a mobile device and access an interface that I think they call UDAjax, which is built into the ISY. Read about it here: http://wiki.universal-devices.com/index.php?title=ISY-994i_Initial_Browser_Screen For a discussion on the port forwading, IP addresses, and security, read: http://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:Remotely_Connect_to_Your_ISY I do not consider this stuff easy for the faint-of-heart or one unwilling to spend sme time figuring it all out. It seams there are a lot of posts about this topic.

For each controller device, there is an option to "copy scene attributes" if you want to make responder levels same as that for the scene (PLM) level. Perhaps this is the accident you found earlier?

I would think that removing the device from any folders then deleting the device would work. My recollection is that it is not necessary to remove a given device from scenes or programs prior to deleting it completely from the ISY. Once deleted, perform a factor reset on the device and re-add it.

My best guess is that responder levels are not correct for each of the KPL buttons. As a refresher, insteon devices can respond differently in response to different controller devices within a given scene. If your scene responds properly to control from the admin console or via program (basically, PLM is controller device), but the scene responds differently when activated by a different controller device, compare ON levels for each responder to the scene level versus the KPL button. To do this, select the scene and take note of the responder levels in the main window. Now select another controller device (such as the KPL button) and compare responder levels. Pay special attention in each scene to the responder levels of the other three KPL buttons. Are they zero? Full on? Different when the scene is selected versus the controller (red letters) KPL button?

I have had no trouble with my fanlincs, but this problem sounds similar to those posted by others. Yes, it sounds like a defective fanlinc.

I dont believe raising or lowering the number has any affect on sensitivity of the motion sensor. This number only affects the level of light needed for the dark sensor to trigger.

I can tell you that there are different configuration settings where one can specify that the sensor send signals only during periods of darkness, and settings that can set darkness level. I can think of no settings that would cause "false" readings or make them more likely.