oberkc

Besides not being sure why you break this into two programs, I don't see anything wrong programmatically. Is the first program disabled? Does the "Christmas Lights" scene turn on if you manually run (then path) the second program? Does the program log show the first program having run at 4:30 (and being true)? Does the program log show the second program as true and run at 4:30? Do you have any unsaved changes to either of these programs?

I have thought this to be a comms problem from the beginning. Unfortunately, I have no idea why the comms problem (if, in fact, that is what it is) would be present at one particular time consistently but not another. I will add, also, that I generally don't experience communication problems as a result of other insteon communications, as you suggest. As things in the house age, perhaps they are more interfering with insteon comms. Perhaps insteon devices, themselves, as they age, become more prone to being interfered with. I continue to believe this to be a programmatic problem. Perhaps a new insteon device may have more sensitive communication ability and may solve your problem. Certainly, it is not easy trying to find these sources of interference and a new device may be the least painful solution.

Interesting question. I do not recall any program action that could modify the settings of a z-wave device. In my specific case (schlage zwave lock) the only action I can perform is lock or unlock or query.

What problem are you trying to avoid? Is there some harm in turning on some lights that are already on? my understanding is that disabling a program (including putting the program in a folder that is disabled) would prevent any condition from triggering at any time. Since a WAIT statement would be interrupted when a condition triggers, if a condition is not triggered (disabled), the wait statement would not be interrupted. I am not sure I understand that question. Use a WAIT statement when you want to pause the program for some reason. This works whether the program is disabled or not. If you desire some condition to interrupt a waiting program, either write the program(s) in such a way that disabling is not necessary, or call it from another program. I cannot think of another option. In your case, I think I would employ a program folder, with condition: if $sXmasLightsOn is 0 then run the programs in this folder In the folder, put a program like this: If time is sunset Then Wait 30 minutes (Random) Run Program 'Outside Lights-Manual' (Then Path) Else - No Actions - (To add one, press 'Action') My understanding is that were the folder to become disabled during the wait statement, the program would halt.

Correct. A scene controller operated remotely will not trigger the scene. It is better to control the scene remotely, rather than individual devices, if it is the scen you desire to turn on or off.

stusviews has the solution I would recommend. I believe Gary Funks approach would work as well, but have the slight preference for stusviews' approach. your single program does not work because the condition "Control '.Fam Rm Rem - E (Movie Time)' is switched On" is triggered only by an ON command, and can never run false.

Yes, but it showed consistent activity up to that point of trying to log in. This suggests to me that it was doing something, at least, up until that point when you tried to log in at 4:53.

I am not going to be much help with the logs, but it appears to me that it logged events all the way through 5:01. This suggests to me that something, at least, was still working. Do you know the LAN IP address of your ISY? Is it a static address? Have you tried accessing the ISY via the IP address from a web browser during these moments? If you can, perhaps that would give access to other troubleshooting options, including looking at whether there is some program in a loop.

I am thinking same thing as I suspect is stusviews, Unfortunately, I am not much good with the log, so I tend to prefer the program status list. I sort them by 'last run time' and look for things that ran near the same time as this program. I would find the time to be there at sunset-30 and check immediately. Given that your devices respond to manual program activation, I tend to discount device failure as a cause. I still am having trouble believing that the program did not run (all indications from the admin panel are that it ran, and ran true). If nothing else shows up, my next instinct would be to change the program time from sunset-30 to something else. Alternatively, delete the program and re-create. Very strange.

The fact that the lights do not turn on is not necessarily conclusive evidence that a program did not run. Perhaps the program ran, but the lamplincs did not respond. Perhaps they turned on, but something else turned them off. Personally, I have never knowingly had a program not trigger and run when it should. This is why I suspect something else is going on. Were this me, I would check status at admin panel right after program run to see if three devices match actual status. If not, there is a problem with communications most likely. Failing that, I would be looking at the program log to see if there are other programs being triggered immediately after this one. Is it possible that the change in status of one of these devices is triggering a program somewhere? But, maybe there is some bug somewhere. I can only say that a program so simple like this one is one I use multiple times a day and it fires every time.

I agree with apostolakisl. This should work. The program should run. There are no ways it cannot run. Why do you think it is not running (is it based on lights being not on)? After it runs, what does the ISY admin panel say about the status of the three devices? Does the ISY believe they are on? Is it possible that something is going on near sunset that is not going on when you manually run the program? Is the ISY sunset time accurate for your area?

Hey, Jack. If the switch is turning ON to a scene command, but not OFF, I would tend to discount (for now) a faulty switch. I did not see it asked, but what is the load on the switch? Can you temporarily remove the load to see if the switch starts responding to scene-off commands? (I am wondering if the load is causing the communication problem.) I do not believe that this is a programmatic problem. It sounds like a classic case of the ISY assuming a switch responds, but does not.

Yes. You can also check status (true/false) of the program. If true, that is a pretty good indicator tat it ladt run THEN path to completion.

Programs are triggered by events, based upon the conditions. Programs do not automatically re-evaluate based solely upon completion of an action clause.

I suppose it depends on what you would like it to do, and whether "closed" = "off". It may also be affected if you are using the sensor reverse mode on the IOLinc. In general, if the query causes a change in status of 'garage closed', the program will re-evaluate. A program in a wait state that is re-evaluated will be halted and run from the beginning, based upon the newly-evaluated status (true or false).

Good question. I do not know for sure. Do you actually use all eight scenes, or could you get by with four?

Gary, Perhaps I don't accurately perceive these hubs, but I understand that few have the automation power of the ISY. Yes, they may better support Z-wave links and scenes, but lack the logical power of the ISY. Is this inaccurate based on what you know?

The current status shown, I understand, is the last recieved command. Like I said, I don't believe you can change the status externally. Larryllix has the best idea I believe, which is to put the remotelinc into non-toggle mode and create a program (triggered by the proper button command) to turn the lights off (if on) or on (if off).

You are welcome, jedi yodallix

Like most, I see no reason to remove perfectly good insteon device and swap with z-wave. I am happy with insteon at this point, and if I could not continue with insteon, for some reason, then the ISY offers me an option to retrofit with z-wave as insteon devices fail. Otherwise, all is good.

My perceptions are that the sole purpose here is to avoid having to press a button twice, rather than a direct display of status. If a scene for which the remotelinc button is controller is turned on by other means, pressing the remotelinc could first send an ON command, rather than OFF command, apparently, forcing the operator to press twice to turn the scene off, or vice versa.

I control only one hib at a time. I thought stusviews mentioned four, but was not cerain whether he has all four linked to his alexa account simultaneously. Like you, I would not mind controlling more than one, but did not find a way to do so in the short time I have spent playing around with it.

My recollection was that they can be set to four- or eight-scene mode. In the four scene mode, there are discrete ON and OFF buttons for each scene. In the eight mode, buttons are toggled. I did not recall a non-toggle mode, but I quickly checkef the manual and it appears to have one. Good thought.

I don't believe so. Remotelincs typically transmit only...no recieve...no status.

Th Well, I already had a couple of Harmony Hubs in use around the house. Controlling them via the Echo was pretty simple. Like you, it seems I have less time now, after "retirement" than I did before. All that time I thought I would have seems nowhere to be found.