oberkc

The program I posted i disabled to avoid having it otherwise react to changes in status. The only way it can activate is if called by mobilinc. I hav never noticed any problems with mobilinc sync operations. Your proposed approach to the fan problem is near exactly how I would approach it. Like the first, I would expect these would need disabled.

I do toggle tasks with tasker widgets, if that is what you seek. First, i create program (disabled) such as: If This program is false Then Turn light on Else Turn light off I then create a tasker widget, through the mobilinc plug-in, that executes the program if path.

In some cases, I have become a fan of the harmony hub. This would require no line of site between remote and ISY, so long as one of your hub blasters is pointed at the ISY. Alternatively, I see no reason it could not be used to transmit IR commands to the ISY through an IRLinc. It has been a while since I programmed the IRLinc, but I recall that it could learn pretty much any IR command and execute a program from that command as a trigger. I think the IRLinc directly supports scenes, as well.

I would besurprised if moving the parentheses was the solution to this specific problem. After your second description, I have a different understanding of your symptoms. If the door waited the five minutes before trying to close, began to close, then reversed back open, consider the possibility that something interrupted the door safety sensors.

Good news on the communication front. I remain mystified as to the cause of the original problem...why your door would immediately trigger when opened. Have you seen this again?

My quick review of your programs makes me thing that this is NOT a problem, but I just wanted to point out that when you turn the ALL scene off, it could trigger an evaluation of program 1 as a result of a status change of the mudroom icon switch. I notice that this program can be disabled at times by program 2, and that if program 1 is triggered by a change in status, it will likely evaluate false, which is pretty harmless. But you are most familiar with your programs and intentions. Double check that there are no unintended consequences there.

If you are using the KPL to indicate door status and control door, then the two scenes look about right. In the scene with the relay, I assume the KPL is controller. In the scene with the sensor, I assume the KPL is responder. Sometimes, scenes tests fail when there is a program triggered by one of the devices in the tested scene. Try temporarily disabling any such programs, and re-run the scene tests. Also, run several times. In general, I have come to understand that when you have zero remaining "hops", this can be an indication of less-than-optimum communication.

No...not to my knowledge. As I understand, programs run simultaneously. The midnight program should run normally, even if another program is also running. Question...is 'Island (Mudroom Door ICON)' part of the scene 'All'? If so, when the midnight program runs, it could trigger an evaluation of program 1. I cannot help but be concerned that this may be a problem if it happens at the wrong time. I haven't given it a lot of thought, however. Perhaps your disable commands take care of this problem. Regardless, I don't think that is a factor in your original problem.

No, you understand it just fine. In my mind, if the door is closed (sensor off) and is opened between the prescribed hours, I would expect the timer to start, and initiate a scene command 5 minutes later. IN retrospect, you may need a re-allocation of parentheses in your program, but I don't believe that this is a factor here: If ( On Sun, Mon, Tue, Wed, Thu From 10:30:00PM To 6:00:00AM (next day) Or On Sat, Fri From 11:00:00PM To 7:00:00AM (next day) ) And Status '19.5C.D1-Sensor' is On Then Wait 5 minutes Set Scene 'Garage Door Relay' On Else - No Actions - (To add one, press 'Action') I am having trouble seeing why this program would have immediately sent a command to the door when opened. I, too, expect the wait period to complete before sending the command. I don't believe the parentheses issue would cause this, either. I would be looking for scenes created that include both relay and sensor, or other programs that may be impacted by relay or sensor.

I see nothing that starts any 15 minute countdown or ANY reason that the first (second?) program would run. Are there other things you have going on here not shown? If your second program turned off ALL lights, and the island failed to turn off, then there is likely a scene definition error, or a comm error.

The sensor, possibly, transitioned from OFF >>> ON, triggering the program? Perhaps it good that you step back and define exactly what you want to happen. What are you trying to achieve? Are you, simply trying to create a program that closes the door, if open, at 10:00? Do you want a program which closes any open door between the hours of 10:00 and 7:00? Something else?

Hard to say without knowing the definition of "work". Since you have no ELSE statements, there is probably no reason to have to/from times. It would be simpler to simply have "time is". In my mind, this program, as is, will turn ON a relay scene "garage door relay" at 10:30 on some days and 11:00 on others, but only if a sensor is ON at these times. This program will do nothing at 6:00am or 7:00 am, or any other time.

"What is the reason for this?" I might do that from time-to-time if I were using the TRUE or FALSE status of that program as a condition of another program. For example, if I wanted a program to be true only while executing a THEN clause, then turn false immediate after completion of the THEN clause. Then I could use the status of that program to know whether it was currently executing.

Xathros...do you have any experience changing properties of a scene specifically including a battery powered device? I was wondering if the motion sensor need be put into linking mode for the changes to take effect.

The only difference that I understand between direct linked devices and those created by the ISY would be the presence of the PLM in the device link records. If you have a device that was otherwise added to the ISY, I cannot imagine why a scene that was later created directly would be any faster. If you noticea difference in scene responses, I would dig a little deeper into that problem. Something strange is going on here beyond the scene creation mechanics, in my estimation. Like the others, I find it bad practice to have scenes created outside the ISY.

What is a "direct linked scene"? Are you creating scenes directly from the devices, themselves? For the ISY to work best, all scenes should be created through the ISY. I expect xathros suggestion to be doable, but until we see your programs and scenes, generalities are all we have to discuss.

The options can be a bit broader than this, but if you have a program condition who's status will be changed by the program execution, then, yes, it is often best and easiest to break these into two programs. If your execution has no WAIT statements or REPEATs, then it matters less to break them into two programs.

That is, in the end, how I see it as well. I remain very satisfied with my insteon house. The continued introduction of new-and-improved insteon devices makes me think that things are working out for smarthome. I have no intention of wholesale changes to z-wave, but if I see a z-wave device on a clearance table somewhere, it is nice being able to take advantage of that savings. Other than that, it will be insteon for me.

You are correct. If an IF condition changes during a WAIT or REPEAT state during execution, the program will be halted, condition reevaluated, and program executed based upon the new condition. Please note that you have two conditions. The second condtion (Front Entry Light is OFF) is changed immediately when the program executes. Since your program has a WAIT statement, the program will halt because the IF condition has now changed (Front Entry Light is now ON). For reasons that are probably a simple preference, I tend to program such things without variables when possible (nearly always). If control front door sensor is turned ON and status front door light is OFF then run second program (then path) second program: if nothing then turn on front door light wait 5 minutes turn off front door light I can see no reason why your second program is less reliable in turning on the light. The conditions are near-identical.

There is another sole-source provider that seems to be doing well. Named after a fruit beginning with the letter "A".

OK. I understand having scenes with buttons as responders for the purpose of initiating via program. Yes, this works as you know. I was attempting (poorly I guess) to point out that if a given device is both controller of one scene and responder of another, when that button responds to one scene, it will NOT act as controller for another. Devices behave as controller only when they re acted upon directly.

And, never mind any of the sensors or electronics.

It sounds to me as if you are doing things properly. Clearly, the communication error is a concern, however. Many of the inconsistencies you describe are also consistent with communication issues. Still, I am reminded of my experience the other day. I became aware that I had failed to rename and organize a couple of devices I had swapped around, and lost track of which device was which. Do make sure you are confident in the devices you are programming. If you are confident in devices, my suggestion is to solve the communication problems before doing any more scene creation or adjustments.

clearly, based upon the tag, one would not want to connect it to a voltage other than 120V. Definitely not something to put on a dimmer.

Check the load ratings for the various devices. I think you will find that dimmers cannot be used for much more than incandescent lighting. Some may now say useable with LED lighting. Most inductive loads such as a dehumidifier cannot be used with a dimmer. A relay device....well....that would be a different answer. You could control your dehumidifier with a relay device. Yes.