oberkc

If it were me and I wanted insteon (or z-wave or similar) at the switch location and all I had was a switch loop, I would go to the fixture box (where the switch loop is initiated) and repurpose the wires to the switch as hot and neutral. In the fixture box I would add a micro module, to which the load would be connected and by which the load would be controlled. At the switch box, I now have hot and neutral and I would install a standard insteon switch, capping off the red "load" wire. Once everything is installed, I would link the switch to the micro module. Done. No wires. No mess. No fuss.

I also suspect it could depend on whether the “device” you added, and are now trying to control, is an individual device or a scene (or an alexa group).

This would probably require some type of variaable. Without thinking too hard (it is a Sunday afterall) and without worrying too much about exact syntax, perhaps this could provide a useful starting point for you: if button is pressed then lock door wait a little bit query lock run check program check program (disabled) if door is unlocked and variable is less than some number then query lock increment variable Run this program again (if path) else run notification program notification program (disabled) if door is unlocked then reset variable send message else Reset variable

I would want to experiment around here, but I wonder if there is a place for a query action? An early conceptual approach could be something like: if button is pressed then llock door wait a couple of seconds query door run check program check program (disabled) if Door is unlocked then send notification

Usually, that forces one button within the group to be on, and all others off. Also known as “mutually exclusive”. I would not expect this to solve your problem. I guess I was wrong.

If the button light comes on when you press it, watch the admin panel from the ISY. Does the status of that button change as you toggle it from off to on? If so, I dont think you have a bad switch. I am still leaning towards comm issues given your belief that the scenes are properly configured.

Re-read my earlier post. Already answered. Anything is possible. I suppose the little switch behind the button could have failed.

I would probably remove them from the scene and delete the devices if you don’t use them, but I am doubtful that this is the source of your problems.

Which suggests to me that it is NOT a device failure. I would focus on - faulty scene definition - corrupted links - commnication problems

Yes, I believe it is possible for scenes to become corrupted. Restoring the device should normally fix that problem. You could try that again. You could delete the scene and add it back. If those steps dont work, consider: - communication problems - faulty device What happens when you turn on that scene via the admin console?

Create a new scene, adding both buttons, with the right button defined as a controller and left button as responder. Make sure the responder level is set to 100%. of course, the answer is also dependent on what you want to happen to button B when you toggle button A on/off. Also, It could matter what do you want to happen to button B when you toggle button A on/off.

I pated it as a link, but it seems to have been converted to something else. I am glad you found it.

Ok. For. Upper right button to control anything, there must be an associated scene or program. To identify your problem, you would have to identify which approach you took and double check the settings. Furtermore, something could have changed that would introduce communication problems that would cause key devices o fail to respond. You could certainly try the suggestion of jec6613, but I am not sure that I would be quite as quick to condemn the switch if it does not work.

Seeking clarification here... you press the top-right button and it does not turn on?

Make sure you understand the priorities of the logical conditions "and" and "or". Because of those priorities, the logic would evaluate as (parentheses added for explanation purposes): ('Inside / Stairs / _Sensor_Motion' is switched Off) Or ('Inside / Stairs / Staircase_Sensor_Motion' is switched Off And 'Inside / Stairs / Staircase_Sensor_Motion' Status is Off And 'Inside / Stairs / _Sensor_Motion' Status is Off) It is not unlike a math problem such as 3+2*4*4. Is the answer 96? Is the answer 35? Something else? In logic, like math, some operations occur before others.

No. While "control" conditions will trigger a program, so will most other conditions, including "status" conditions. The real question is WHEN will a condition trigger a program.

Which four? (I don't keep track of such things, sorry.)

Well, other than choose somebody beside the USPS?

Don't disagree with this. I think many of the instructions were written before Polisy (based instead on polyglot or something else) and don't match approach with Polisy. There has been too much assumed, in general, and too little detail provided. While I have been able to get working the few nodeservers that interest me, it took far too many hours to do so, having to spend a lot of time on trial, error, experimentation, and exploration. Don't disagree with this, either.

No, it isn't. It's set so that once one of the motion sensors OR the other sensor AND...AND... Are the two sensors close by? Are they typically triggered within seconds of each other? It seems to me that this set of conditions runs the risk that could run FALSE (else path) pretty regularly, including an interruption of the 5-second wait. My concern is that this is more complicated than it needs to be and introduces unexpected results. For your upstairs motion timer program, why not: if 'Inside / Stairs / _Sensor_Motion' status is Off and 'Inside / Stairs / Staircase_Sensor_Motion' status is Off then same else same

And as soon as I wrote this, I recall a nice little program called "conductor". This was an app that had an associated fee. Unfortunately, the fee did not guarantee the same fate. I had a TV remote control app also that cost about $20. Used it for about a year, then the developer got bored or tired or lost his free time. I guess fees are no more a guarantee of continued support than lack of fees a guarantee of near-term obsolescence.

I agree. I think a bug is highly unlikely. I never had any trouble with this in v4 software. I also thought scene controllers were red in the list, but I may be remembering incorrectly. This is an indication of communication failure, if I recall correctly. Also, this can potentially fail if there are programs that are triggered by any of the devices in this scene. Communication failure can certainly cause the symptoms you describe.

For me, the concern about fees or lack thereof is that I see it as an indicator that this is a hobby and passion for some, rather than a business venture. Don't get me wrong, I very much appreciate all the effort that goes into it, but I cannot help but be concerned about the long-term viability of these node servers. I understand that Homeseer and Hubitat may be examples where the community builds these interfaces to various devices and protocols. I also read stories where some of these interfaces have been abandoned or left unsupported (insteon for homeseer is one example that comes to mind) as the developer gets tired or moves on to other things. I don't want to see these same results for Polisy. Maybe this is just the nature of the business. Maybe there is just not enough demand for this stuff that one can make money supporting it. Having said all that...Thanks to all who have contributed.

That would also be a barrier for me. This makes me suspect that they have access to my ISY. No thanks. Having said that, I have already given all this away to amazon and alexa, as to Google, not counting the portal, itself. What is one more?