oberkc

Given your description of your wiring, supply is almost certainly introduced at the fixture box. Google is your friend when trying to understand different wiring approaches for three-way circuits.

True, there could be a global use for "daylight hours", but (being the fan of simplicity that I am) there is no need for variables in some cases: If Time is from sunrise To sunset Then Nothing Else Nothing This program will be either true or false, based on time of day, and could be used as a program conditon as well (no variable needed). If, however, one wanted a program condition that was not a program trigger, then the variable has an advantage, yes.

You would need to repurpose existing conductors by changing connections in the fixture box. If each switch location has only a single 3-conductor cable, then it is a near certainty that both cables terminate at the fixture box. If so, you will not need a micro module at all. At the fixture box, identify supply hot and neutral. From the 2 cables from the switch boxes, you would connect white to supply neutral and black to supply hot. This would give you hot and neutral at both switch locations. Using one of the new insteon switches, connect red wire to the red conductor in the cable. At the fixture, connect the other end of that red conductor to fixture hot. Cap unused red wires and conductors

A normal switch, insteon or zwave, will not work here without the micro module. There is no neutral in this box. (White is not neutral here...do you see any black tape or paint on this white wire?) Yes, this would be where the two wire switch would be appropriate, assuming compatible with the load. Halogen is, by the way, a type of incandescent and should be compatible with the two wire switch.

I am equally upsdt that I did not think of this approach.I would have taken your approach, except for the variables (use program status instead...variables seem unnecessary for this application). As one who sees elegance in simplicity, my admiration goes out to apostolakisl.

For example OTL = Outletlinc KPL = Keypadlinc IOL = IOLinc Etc....nothing special here, in my mind. I just like three character codes, I guess. I probably like xathros' codes better than mine

I use a convention DDD RRR NAME, where DDD is three-character device code, RRR is three-character room code, and NAME description narrative. I am not sure that this is a perfect solution, but it is the way I started it (before there were room folders, I believe) and I am too lazy to change it. My biggest (only) hangup is the one identified by416to305...using mobilinc and tasker, any widget I create on the homescreen shows the first few characters of the name from ISY. This is not especially useful for this purpose to have a widget with a name of OTL FRM north (rest truncated).

Rudy, I suspect you will be more satisfied with your system if you avoid your two programs (with the SET SCENE and FAST ON actions) and use ADJUST SCENE actions in a 9-6 program, as suggested by LeeG. Given your two posted programs, I continue to believe there to be some confusion on scenes and responder levels. One of the main characteristics of insteon is that responder levels for a given device can be different based on to which controller it is responding. A less obvious factor here is that the PLM is, technically, a controller device for all your scenes. For example, in your scene "main hallway upstairs", switch "main hallway upstairs master" is responder to three devices: main hallway upstairs 1, main hallway upstairs 2, and the PLM. When you created the 30% scene, you likely created a scene where the three switches were set to 30% on level when responding to the PLM...the scene level responder level. (In that scene, if you mouse-click on the individual devices, I susect you will find the on levels for the three devices to be something other than 30%.) I suggest re-reading LeeGs latest suggestion in detail. That single program will accomplish your goals and I expect you will find your system to be much more responsive, reliable, and robust.

I am confused. The manual states that applying more than 5v across the sense input can damage the sensor. I thought the sensor was more to detect contact closures rather than presence of voltage. Am I misunderstanding something here?

I misunderstood your request, then. You could further modify your program to look for kpl OFF commands and turn the light off manually.

You want them to turn OFF in response to an ON command from the switch? Adding the suggested condition would simply retrigger the timer.

I would activate the motion sensor and see if you get a command to the ISY. The event viewer will show all commands recieved by the ISY.

I think the best option is to replace the garage door sensor. Early versions had both NORMALLY OPEN as well as NORMALLY CLOSED configurations, where one could wire the sensor as needed. Mine, for example, is OFF when closed, like your hidden door sensors. This is the way I prefer. I believe the older "3-wire" sensor is still available.

ADd To Program: Schedule Schedule: choose "from" in the window which shows "time"

I know of no easy way to troubleshoot communication issues. Unless you have one of the classic problems (failure to couple phases, lots of stuff plugged into same circuit as plm), there is not much I can offer that doesnt take time. Only you can judge whether the amount of time is unreasonable.

Yes, it can act also as a time range. If there are other program conditions, the from/to will still be considered TRUE. A program will be triggered by its conditions. From/to conditions are triggered twice only. Status conditions are triggered at any CHANGE in status. Once triggered, however, ALL conditions are evaluated, and the from/to condition will always be evaluated as TRUE between the specified times.

I think were I to desire to do what you described, the best approach I can think (until isy v5) would be a combination of mobilinc and programs. Create a program for each interested condition (dinner guests, weekend away, overnight guests, etc....). Each program would be completely blank (if triggered entirely from the phone) If Nothing Then Nothing Else Nothing Once established, these programs are visible from mobilinc. Using mobilinc "run then" or "run else" clauses for any of these, you would be setting the programs as TRUE or FALSE. This program status could then be used as conditions for other programs and react accordingly. It is an approach only a mother could love, but it would be functional.

Or, even simpler, forgo the program and variable. The folder condition could be as simple as If status kpl button is on Then Enable programs in this folder to run This is how I do it. Unfortunately, this does not solve the virtual button problem. I use a combination of tasker and mobilinc to create buttons on one of my android home screens, but I have yet to find a way for that virtual button to change (light/dark) as an indication of current status. I understand tasker widget icons are static images. Perhaps I am missing something.

I should have been more clear. When I suggested apps and computers talking to insteon, I was thinking broader than a dedicated app or software. I was thinking more universal integration, where all apps can trigger insteon events, not just one or two apps, or vice versa. For example, my mail and calendar apps could trigger an insteon scene. Or the ISY could send a text message from hangouts. Or the ISY could trigger the remote control app to turn on the tv or music. With regards to the original request, it seems an ultimate goal would be for the ISY to integrate with whatever calendar application one uses, allowing one to define a given day as a work, holiday, vacation, weekend, party, and have the ISY react in a coordinated fashion without having to recreate the calendar in the ISY. But, for now, I think annual and monthly days in theISY would be a great start.

If I had to identify the one shortcoming with ISY organic programming capabilities, it would probably be in this area. I have always wanted the ability to be more generic in specifying times and dates, such as If april first of any year If holiday, If on vacation Integration with a shared calendar such as outlook or google or ical or whatever would be wonderful. I understand this is "on the list" of improvements, by not as high a priority as I would prefer. Someday, I may take the time to do what you are about to do, but not now. I agree that this has broader implications than a simple trash notification. Perhaps, too, that a smart home is not a single device that does everything, but a well-integrated ecosystme where your phone, apps, computer, calendars, hvac, all can talk to each other and trigger events.

Good. I am glad you found that wiki article. This is one of those cases where I have decided that the the payoff is too low for the amount of work required. My approach would simply be If Thursday Send notification In the notification, I would simply include a reminder to self to wait an extra day if there was a holiday this week.

There is no reason that I can think of to avoid using the else path of a program. So long that one understands program triggers and evaluation logic, they are a powerful tool that would be silly to ignore. I suspect most of the reason you see empty else statements is based on need rather than some inherent flaw. Coneceptually, I see nothing wrong with your "not a holiday" program. Yes power failure could be a practical concern. Another might be how you intend for the ISY to know whether it is, or is not, a holiday. That is more complicated than it sounds. If you desire to be somewhat tolerant of power failures, I would simply break this into two programs If not a holiday And thursday Then Send notification Else nothing If a holiday And friday Then send notification Else nothing But, your bigger problem, I suspect, is programming the ISY to know what days or weeks are holidays.

Perhaps accessing the admin console from a browser would avoid the problems. My use of the dashboard has been limited to device and scene control. I have never experienced your problems using the browser method.

Not necessarily. I would try control. Hopefully, the fix is this simple. (I note your test program uses control.)

Perfect!