oberkc

For what it is worth, I just updated to 4.1.2 (is that the latest?), including the UI, and experienced similar issues...the automatic write updates toggle buttons were not there. Interestingly, when I logged back in later, they returned, only to go away and come back in subsequent visits. I observed no particular relationship to any other event.

I suspect what you desire is not possible without extraordinary measures. Still, I am curious what you mean by "the standard HMI". Are you talking about the ISY admin panel or dashboard? (BTW...I want virtual devices for my android desktop. I have been unsuccessful so far.)

Like Xathros, I find the IOLincs quite reliable....it is the communication that can let you down from time-to-time. There are several considerations, I believe, to having confidence that your door is closed (or open, or whatever). First, one must decide which status (open or closed) is a priority of knowing truth. You have chosen CLOSED. So have I. Then one must decide how one wants to indicate CLOSED on a keypad button...do you want it ON, or OFF? I have chosen OFF = closed. Once chosen, I believe it best to continue with the sensor, both type and mounting location. Choose the type where sensor in contact is OFF (or ON, if you prefer ON = closed). I believe it best to avoid the sensor reverse option of the IOLinc, out of concerns that this may get reset during power outages. Then locate the sensor in such a way that it is in contact only when the door is FULLY closed. Then, put all the keypad buttons into NON-TOGGLE ON (or non-toggle off, if you want ON to indicate closed). Putting your keypad button in non-toggle mode will ensure that there is no way that someone can manually put the button in a status that would falsely indicate door closed. Link your sensor and your keypad buttons in a scene, with sensor and buttons all as controllers. Make sure you have no programs that can turn OFF your keypad buttons.. Configured this way, there is ONLY ONE WAY for any of your buttons to be turned OFF: if the door is closed. If you find one button on, but the rest off, you can be near certain that the one button is an anomaly. Having said this, I remain a fan of webcams.

Make sure you set the button responder levels to zero for EVERY controller.

This tends to suggest, in my mind, a keypad failure. Hopefully, it is not a sign of things to come.

Temporarily remove power from ISY?

I don't have the time right now to sort through everything, but I noticed a few items off the top: This program might be better using "control" rather than "status". In it's current form, it will trigger when the doors are closed, also. I would be surprised if this program evaluates true EVER. To run TRUE, this program must see the simultaneous receipt of two commands (one control statement AND another control statement). I am not even sure that this is possible. Perhaps whatever troubles you are having are related to these concerns?

If the folder condition is false, programs within the folder will not self-initiate. They can, however, be called from other programs outside the folder.

Yes. I missed that. Thanks.

Be aware, also, that what constitutes a "scene" is defined a bit different with the ISY that with the basis insteon devices. If you see "scene" used in the manuals of individual devices, that generally refers to a relationship between two devices. With the ISY, a scene can have practically unlimited number of devices. Are you suggesting that you have manually linked insteon devices without using the ISY...by putting one device into linking mode, and adding the responder manually. I generally find this a bad idea when one has an ISY in their system.

Perhaps, more importantly, do you know WHY this solved your problem? Understanding the difference between control and status is a key concept.

Xathros is correct, and I could have misunderstood your intentions. If you plan to initiate light levels at certain times, then I stand by my original assessment. If, however, your intention is to change the levels that your lights turn on in response to a local button press, then there would be a noticeable delay if using separate scenes and programs.

All my outdoor flood lights are LED. I have noticed no problems, though I make no attempt to dim them.

EricK beat me to it, but his is the approach I suggest, as well. Set up two scenes and invoke the proper scene based upon time.

This is all very doable. However, I am not sure what this has to do with a camera.

It also depends on what you mean by "integrate with insteon". What insteon function do you desire a camera to possess?

When you say that one is working locally but the other is not, are you saying that you the switch fails to respond to the button presses? If so, I tend to think wiring problems or failed device. Does the LED light stay on constantly, or does it ever go off? Which switch powers a fixture, if any? My first instinct is to check to make sure that I have the line (black) connected to the constant hot supply, and not the load (red).

I am in no position to check right now, but I thought the repeat could be defined for X number of times. Combined with a one-hour wait would , in my mind, accomplish your goals.

And that is the only reason I can think to have such a condition. Balance that with the possibility of comm error such that the ISY may believe a light to be on when not, causing a light not to turn on when I motion is sensed. I would prefer having higher confidence that the light goes on, rather than avoiding what (at least for me) would be inconsequential comm traffic. Still, it sounds as if your understanding of how things work is good.

Since you want to limit response to motion sensor between specific TIMES, this tends to suggest a program. Furthermore, I don't believe a Dakota Alert sensor, itself, can be set to respond only during certain conditions, which also re-enforces the idea of using a program rather than a scene. Bernman's example from his earlier post is probably more complicated than what you need, but there are some good ideas and concepts there. Because I don't own a Daokot Alert (not sure of the exact syntax), because I am unfamiliar with your current lighting devices and scenes, and because I think it is good to experiment around a bit, I will offer only a conceptual program as a suggestion: if control Dakota alert is set on and time is from sunset to sunrise (NEXT DAY) then turn on floodlights wait 5 minutes turn off floodlights else turn off floodlights This approach makes certain assumptions about what you want to happen if the Dakota alert is triggered when the lights are already on, and what you want to happen to the lights at dawn (regardless of any countdown in progress), but I suspect you will find it pretty close to what you want.

Program "porch light off" will shut off scene at midnight and sunrise+30. This seems straightforward and as you say you want. Program "Porch light on" will turn on scene at sunset and 0400. This seems straightforward and as you say you want. Program "Porch motion on" can, perhaps, be simplified, depending on your goals (and assumes 'Porch Light Switch Front Door' is part of scene 'Porch Light 3-Way'). What happens if you delete the second condition? What is your purpose for this second condition? Otherwise, I see nothing obviously wrong.

The only way that I can think would be to add the devices to the ISY, choosing: "add devices found in links and keep existing links" Still, I expect this to be problematic, in that it might try to add the smartlinc. Your best bet might be to factory reset the devices and recreate the scenes.

I think you are correct. It would work like you describe. I did not look close enough earlier, I guess.

I was unclear....I would probably include short wait periods for each keystroke, reverting back to the beginning if not executed on time.

My response would have been similar to KMan, but I would have included provisions for the sequence to time-out after a certain period. If that intersts you, and if you care to respond to my initial questions, I would be happy to offer a suggested set of commands.