oberkc

Good. My best guess up to this point has been that the ISY thinks one of the devices from the program condition is still ON (when it is actually OFF). This causes the program to turn your KPL button ON. In your new program, it would surprise me if the query was necessary. I believe a program will send an OFF command even when a device is already OFF. I wonder if it was the increase to 5 seconds (from 2 seconds) that helped more. In the end, there is only one way for your KPL to be ON: this program. And this program will only turn on the KPL button if it thinks one of the conditions is true. I am with you in that I don't fully understand how the timing of the communication works, and also wonder if the amount of time it takes for your devices to turn off are affecting this program.

Everything that I see here appears correct (or at least how I would do it). The only thing I begin to wonder about is whether ISY status for some of these devices does not match actual device status due to some communication issues or similar. I would still try my suggestions from a couple of posts prior, but I am running out of ideas, besides checking to confirm ISY is accurately tracking device status.

Your analysis of the log was deeper than anything I have ever done. I have looked for gross indicators of programs triggered or comms issues, but never a line-by-line analysis. Certainly interesting and seems accurate. What is not clear to me is why you have a program that turns OFF the KPL button? Is this a program that simply checks the status of all the pertinent devices and turns the KPL ON if at least one of the devices is on, and turns the KPL OFF if they are ALL OFF? Is that the program 001D? If you look at the programs list is this the only program triggered by such a series of button presses? Care to post this program? My inclination would be to try a couple of things. 1) Toggle the kitchen fluorescent lights and observe the KPL button. Does toggling the switch from on-to-off cause the same reaction to the keypad button? 2) Temporarily disable program 001D. Does your problem go away if you perform similar experiments?

Wow. I would have never thought this could happen. Is this device a controller or responder in the scene (responder, I assume)? How easy would it be to temporarily remove the load connection from the switch and see if the problem goes away? Have you watched the event viewer for clues? With the switch still part of the scene, press the "Bedroom KPL - Kitchen Button" and immediately check the program log to check (triple check?) to see that there was not a stray program running out there triggered by the fluorescent light switch which might cause the KPL button to come on.. most that I have seen add a screen shot or snippet of the admin console.

It is not your understanding of the "IF/THEN/ELSE" logic that has me concerned. Do any of your programs have any "waits" or "repeats"? Before fully restoring it, check to be sure the non-toggle mode works as you expect. Make sure you disable any program that may affect this device, also. What do you mean by "link it directly"?

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?