oberkc

Nice!

Logically, i suppose you could try: If $allowtorun is 1 Then Repeat 4 times Set outlet on wait 2 hours Set outlet off Wait 1 minute Repeat Run next program (then path) Else Halt next program Next program: If Nothing Then Wait 16 hours Run last program (if path)

Chris932, I apologize. I was, apparently, remembering things that did not exist. The user manual and wiki are definitely a good resource, but I cannot find a specific example regarding fanlincs. The problem, oftentimes, with smarthome instructions, is that they are often based without automation in mind. The instructions that come with the insteon devices are all based on having no controller and linking devices directly (manually). The problem with the instructions you linked is that relying on the mutually exclusive relationship (called "radio buttons" in the keypad manual) will cause the keypad to become out of sync when you want to control the fan via another method, such as a second device, from the ISY control panel, ISY program, mobile app, etc... You see, the radio button relationship is enforced only when manual presses on that specific keypad are used. Otherwise, the buttons are free to get out of sync. Stusview started to hit on the issue. In this case, I believe it best NOT to use the mutually exclusive options here, and handle the button relationships via scenes. You will also have to put the buttons into non-toggle (ON) mode. I am out of time, but I hope you are making progress and this little hint helps. Otherwise, I will be back.

I use a ketpad button as the key indicator for home/away. I can certainly control it rematelt, but I have not automated the status...all manual. If I were to automate it, i might do so via mobilinc ad location. I might actually prefer it based on schedule, but i do not see a practical solution to make that happeb. I have decided it is simply too easy to press the button when i leave for vacation.

Chris932, I add also that the instructions you used will work fine so long that the keypad is the only method you ever use to control the fan. Should you ever desire to turn on the fan via a program or another device or via some app, I expect that yoy will find that the keypad lights will not stay in sync. Is his support site by smarthome (I am not sure I have ever seen it)? If you are using the ISY controller, you may be better off using the universal devices wiki, where you can find user guides and articles for common use cases, including a ceiling fan example.

If you have an unswitched hot and neutral at this location, plus two travelers, it may be possible to identify the traveler that is currently routed to the common\fixture at the unidentified switch location and hook that traveler to the switched output from the new insteon switch. Still, I am curious about your wiring configuration. How many cables are there entering the switch box. How many conductors are in each of those cables? Is this the only switch in this switch box? Do you have a voltmeter and know how to use it? Are you able to identify a neutral (color is not conclusive)?

Is it possible for the 3:00 am query to cause a change in status on any given device? Yes (an indication of communication problems). Is it possible that the change in status causes a program to run? Absolutely. It is likely that a change in status at 3:00am caused a program to run at 3:03? Unlikely, in my mind. Is this happening at your house? Hard to say without seeing the programs and logs. Were there any programs that ran just prior (seconds before) the 3:03 program? Does your event log show activity at 3:02 or 3:03? So...I would be starting with the program in question and asking myself what could trigger it. From there looking for other programs that may cause such an event that would trigger it. I would be watching also for devices with inaccurate status.

I would state it slightly different. While it may be true that the ISY has no way of knowing the state if a scene, I would go further as to suggest that there is no such thing as a scene state within the very definitions of insteon. Regardless of yhe controller chosen, there is no concept of scene state.

I like it, too. Personally, I probably would not include the first two conditions of the second program, but I am funny about such things.

A few quick thoughts: Keypad buttons in their default state will toggle between ON and OFF. There is typically no logical statement that is equivalent to "keypad button is pushed". One can put the button into a state where each push is ON or where each push is always OFF. In such a state, the program would then look for the ON or OFF command, as configured. Furthermore, you might actually be able to do this in a single program. ISY has THEN and ELSE paths. In the logical form, it might be something like: if keypad button is pressed ON (keypad button configured to always send ON commands) and status outlet is off then turn on outlet push relay else push relay wait xx amount of time turn off outlet turn off keypad button I suspect, however, that you will want to add further stuff which could drive you to multiple programs. Things always get more complicated after you try things out and come up with new requirements. Also, if it is imperative to wait for direct feedback from the computer being off, this will likely drive you to a second program.

Clearly, you have not been around many electric guitar players.

Yes, i looked at the 1608 mackie. The one that best matched my interests was the behringer x18 air, but it was only a rumor when I was upgrading. I have used one of the yamaha boards like that one, and also regularly use the 32AI Presonus boards (really like the workflow and ipad app). Sound mixing is one of my hobbies and passions.

Hijack alert!!! Turning myself in. Cannot pass this one up. What mixer? (I use the Behringer X32 rack, and it has been very nice.) Sorry I could not help myself. Alert terminated.

Logically, the second (outside) set of brackets is not needed.

Xathros, $fanspeed is an integer variable accordong to original post, but one does wonder. I suspect all programs are running because the are all triggered by the same remote button.

Sorry, mango. Lost track.

First, i am not sure that I can accurateli infer you full intention fron the program. Is it your intention to turn the fan from low to medium when you press the remote OFF?! Personally, I would probably use scenes to control the fan via keypad and a program to relate remote commands to the scenes. One think that appears suspicous is your parenthesese. (I believe the last one is in the wrong place...should be ahead of AND statement.) I am also suspicous that, somehow, your variable is defined as a STATE type, but without seeing all your programs and knowing what buttons you pressed, it would be speculation on my aprt why your other programs would be running

Mango, if you decide to try the program solution, I want to emphsise the last pont made by larrylix: make sure the buttons are NOT in a scene that includes the iolinc as controller.

Well, broken is relative. Insteon is a known commodity. Broken, to me, suggests that it does not do something that it claims to do. This is like claiming that since insteon does not wash your car, it is, therefore, broken. There are no claims made about scene commands such as discussed. Perhaps a better way of putting is it that insteon is not well suited to meet everyone's desires...not suited for all purposes. Of this, I am more confident. This could be done with a program(s). Then, one would have create the echo>ISY command relationships. There may be some around here that can help with that. I am not one of them.

Yes, it could be done with logic. Yes, trigger reverse is an option. Both have subtle downsides. I prefer the alternate sensor. This is a topic that comes up pretty regularly.

From a purely intellectual and logical perspective, one would want to do this for the same reason that one would want to set a scene members level to something LESS than the pre-defined ON level. If we accept that there are times that one may want to turn on a scene a reduced values, it seems logical that there might also be times that one might also want to turn them on at increased levels, no? Fortunately, I find stusviews assessment spot on....nothing is broken. The insteon design allows for this by allowing the creation of multiple scenes. Pre-define scenes at the levels desired and call it a day. I would add, also, that insteon DOES include the options to redefine scene responder levels, correct? Given this, another question that could be asked is why echo cannot properly interpret a request to set set scene levels to something other than pre-defined levels is not properly executed using the tools at hand...ie, when is the echo going to get fixed? Ultimately, neither insteon, echo, or the ISY is "broken" in this case and expectations of any being fixed are misplaced. Instead, there are existing methods to solve this problem and that is: scenes and more scenes.

Without providing detais and explanation, your best bet is likely going to be to replace your sensor with a different type: normally closed, or NC. I dont believe they are very expensive.

Perhaps I misunderstand your problem, but I have not experienced a case where a program ran but the ISY status did not update. From where are you observing the status? Admin panel? Mobile app? But then, like larrylix, I don't use "fadeup" commands.

No need. Barring comm problems, status is maintained automatically. Switches report status when changed. Programs will update device status.

Further thoughts....is it possible that other program or insteon activity is happening between the separated programs? Might this activity delay the response of the subsequent programs? Have you ever opened an event viewer while executing the goodnight action?