oberkc

These two statements conflict with each other, as I interpret it. Combining your newly-revealed requirements with your old requirements, it appears that if the fan (or fans) are off, you want them to stay off. If the fans are on low, you want them to stay on low. If so, then the only thing you end up doing is toggling the fan (or fans) between high and medium, based on the state of the AC. Given this (only two possible states), variables may not be needed. What method or device do you wish to use to "set" your fan mode to automatic or manual? A keypad button? Time? iPhone? How do you want your system to respond in each mode? I may not be smart enough to understand what it is you are trying to do.

Which fan?

Which "fan"? How do you manually control this fan? How else would this fan be set to "low"?

, Then you need, to start, a controller and a couple of outlets. While it may not be necessary to start, access points and a filter or two should be on your list of items to get sooner rather than later. . Cameras operate completely independent of insteon. Otherwise, add switches and motion detectors as you see fit. The ISY-994 provides for internet access. You will need to download an app for the iPhone. I use mobilinc, and it works fine. Sending text messages is within the capability of the ISY-994. Triggering a message from a camera is going to take some pretty serious tinkering, if it is even possible. (Perhaps someone has done this, but I don't recall any post on this forum claiming this ability). Triggering from motion detectors is child's play. Viewing cameras from an iPhone is completely independent from insteon, though I understand the iOS version of the mobilinc app includes the ability to view IP-enabled video cameras. Alternatively any other camera viewing app could be used.

I can't be sure, but is your third line of the THEN path turning on the device, or the scene (both have the same name)? You need to turn on the scene, and I thought scene commands had the syntax: set scene "xxxx" on Your fifth line in the THEN path is, I expect, NOT doing what you want. This is the statement used when you want to redefine the response levels to a device within a scene, not to turn on a device or scene. If you correct the third line, however, you will not need the fifth. If I am mistaken here, another possibility is that you have the ON response for the swamp cooler keypad at zero.

I was wondering if, somehow, you had #1 and #2 in a scene, with #1 as a controller, with #2 having ON levels at zero. I guess not. I suppose you could still check the admin panel device listing, choosing either #1 or #2, and further confirming there are no scenes with #1 and #2. But it sounds as if you are confident in this. Given no scenes involving #1, the only other explanation I can think of for a reaction to double-tap and no reaction to single tap is a program. But there are no programs. This continues to be inexplicable to me. The exceptions that I can think of: X10. Do any of your devices #1 and #2 have an X10 address? Did you ever create links manually between these two devices, separate from the ISY scene process? This is not inconsistent with a scene or program involving #1 and #2. I got nothing here. How far into your system are the tentacles of these three devices? How hard would it be to remove them from the ISY, perform a factory reset on the devices, add them back to the ISY and incorporate into your scenes and programs? I would check each step along the way, after factory reset, that this behavior is gone. Short of that option, you could try a "restore" device for switches #1 and #2. Perhaps there are some lingering links remaining in these two devices. I forget the exact steps, but there is also a way to compare link records in a device compared to what the ISY thinks should be there. If there is a mismatch, I believe restoring the device would solve this.

Like LeeG, I am also unsure how your variable is controlled. Is it an integer or state variable? How does it change value? You say I believe you are on the right track, however.

Seems weird to me, also. When you turn on switch#1, nothing happens to switch#2? What happens is switch#2 is already on and you turn ON switch#1? You have no programs triggered by switch#1?

I see NOTHING in this program that would cause anything to stop. I also see nothing that would cause anything to START. This makes me suspect that there are factors outside this program causing your problems. Are there other programs which call this one? Are there other programs which call on sprinklers? What are the "zone3" sprinklers?

There are folders for organizing devices, and there are folder for programs. Which are you questioning? Regardless, I like the idea of program folders when you have multiple programs that you want to run under certain conditions. For example, you might have several programs that you would want to run only when home, and several other programs that you would want to run only when away. Programs that you may want only to run when away could include: random lighting, garage door opened notification, front door opened notification, HVAC at reduced levels. Programs that you may want running only when at the cabin are a different set of lighting scenes, garage notification only after one hour after sunset, HVAC at increased levels). I like using scenes (rather than programs) to cause response to local control of Insteon controllers. They are faster and, generally, more reliable. I also like creating multiple scenes for different conditions such as a HOME scene, AWAY scene, GUEST scenes, MOVIE scenes. Am unfamiliar with the concept of flags in the ISY-994. Control v Status matters for all devices, I dare say. It is important to understand the difference. It affects when programs are triggered, and the results of the evaluation. This is, possibly, the single-most point of confusion with ISY-994 programming. I don't know it, so I am pretty confident to say it can wait. I found it interesting that you purchased the network module...why did you do so?

Given this, I wonder some forum of logic (in pseudocode) such as the following would work: If status party scene is ON* (see note) then turn secrurity lights OFF else turn security lights ON *NOTE as discussed, there is no such thing as scene status, so you will have to replace this with the proper device status, whether you want to use combination status of rope and patio lights, or a controller from the party scene controller or something else. Also, I have missed it if you have any element of time (sunset? sunrise?), but one could add this condition relatively easy.

punctuation and capitalization please it makes it easier to read

Is it silver, as so many have said?

Yup. It may not be THE problem, but it is almost certainly A problem. Filters are cheap.

Xathros, This is turning into a mobilinc clinic. Thanks. Unfortunately, I am beginning to suspect that the differences in iOS and Android (my version) versions are starting to come out. I don't believe I can change the icon of a program. I also don't see custom "status" (at least for programs). Hopefully BriG can take advantage of this.

I agree, that this tends to suggest that the thermostat works. Unless you have a direct scene relationship between the remotelinc and the thermostat (do you?) then this tends to further isolate the problem to communication between the B buttons and the PLM. Unless you have watched the event viewer, confirming reciept of B button commands, THEN confirmed that a program failed to run (still unlikely, in my mind), I would focus on this. Is the problem happening with a specific B button, or all B buttons? I also wish to re-engage here. Your "B" scene includes ALL B buttons (and the remote button) ALL as controllers, correct? No responders? What do you mean by "secondary" buttons?

Indeed, it is. I had failed to realize that program status was shown in mobilinc listing, nor to recognize how to exploit this. Cool, indeed. Which led me to ponder using a widget for this, since widgets allow use of neat pictures and icons. Unfortunately, it appears that widgets do not show status. Too bad. That would have been nice.

Yes. However, I would focus on the PLM and the circuit in which it is plugged. Because the PLM is so critical in the operation of the ISY and your insteon system, I filter everything on that circuit. Better yet, add a dedicated circuit for the PLM. And this is the point of so many of the earlier questions...is the thermostat not adjusting because the program is not running because the ISY is not seeing the button presses (sounds likely)? Or is the ISY seeing the button presses but not running the program (unlikely in my mind)? Or is the program running, but the thermostat is not seeing the commands issued by the ISY (possible, and possibly the same as causing the failure to see the button presses)? Answers to these questions will help isolate the cause and course of troubleshooting. Perhaps not as rare as you think? I recall cases where this ISY would issue commands, the device fail to respond, and getting no error messages. I would not get too hung up about this. I think your root cause is comm issues. I suspect it is centered around the PLM. Make sure you don't have lots of other electronic gadgets (UPS? Surge Suppressor?) plugged in the same circuit, or filter them.

I started my system before there were folders available in which to organize devices, so I used a naming convention: DDD RRR Description DDD is a three-character designation of device type RRR is a three-character designation of room Description is self evident Were I to do it over again, I might swap DDD and RRR. Or I might simply use a short description. Using mobilinc, devices show up with truncated names, and using a naming convention such as this often results in ambiguous device names displayed. Since the introduction of folders, I have created one for each room, including "exterior". All devices now go into a room folder. I expect that "best" will be in the eye of the beholder.

Nice. Then I ammend my suggested program to: if status "any button A" is on And Program 'MH Driveway Timer' is False then wait 10 minutes set scene "buttonA" off else With this approach, of course, if one turns on the lights manually at 8:59, they will still go off at 9:00.

No. If you set up the scene as I suggested, then use any one of the five buttons. With the scene, all would by synced together, so if one is on, they are all on. Are you now adding the condition that the security lights only come on between sunset and sunrise, regardless of whether one presses the A button or any other condition?

I don't know that I would describe it as "disconnected", but rather as failing to think bigger. I percieve that they are limiting thier view of Mobilinc as a PHONE program (with inherent risks/rewards when one is physically away from the house), and failing to consider how tablets can be used as dedicated whole house controllers, unconstrained by any concerns about unintended-and/or-unkown presses of widgets and icons. But it does not even do this. If it did, your problem (and mine) would be solved. A physical switch can both display status of one scene and act as scene controller for another. A physical switch can issue a command by a single press. A physical switch can be part of MANY scenes. Mobilinc devices can do none of these things. I actually think a virtual insteon switch, duplicating an insteon switch or insteon keypad button, would be a HUGE improvement. I don't use the iOS version, but I find that the very core of apple products often trade function for pretty (ever notice where the power button is on a Mac?) iOS apps are almost universally "prettier" than the android counterparts. I have often wondered if iOS tends to make iOS apps also biased in such a way. Yup.

I believe the solution to this problem will require a program. Scenes will not be sufficiently powerful. You don't see one because there is none. There is no such thing as scene "state", or "status" with insteon or with the ISY-994. Variables cannot be part of scenes. It takes a program to change the value of a variable. This observation begins to suggest a reason why there is no such thing as scene status. Is your party scene on only when rope lights are at EXACTLY 43%, and not 42 or 44? What if the rope lights are at 43, but patio is at 71% (or any random value)? This observation also reaches the same conclusion that most of the rest of us have reached...one could use a surrogate device as indication of scene status. The question you need to ask yourself is how you want the security lights to behave when the combination of rope/landscape/patio lights are at a combination of levels other than the descrete values of the three scenes? Do you want the security lights off? At what levels must the rope and patio lights get to before the scene ceases being "party" and becomes "cleanup"? 70%? 90% 100%? Instead, would you rather have the security light turn off as rope/patio lights are in some state of brightness between the party scene and cleanup scene (unlikely, I assume). Questions like this need to be answered for all three scenes in order to come up with proper program conditions. One thing that I am unclear on, but may offer a solution, is whether there is any device within your three scenes that act as "controllers"? Are the keypad buttons part of these scenes as controllers, or do you use a program to turn on the scene, triggered by the keypad buttons? If the former, you could use one of the keypad buttons as an indication that the scene has been turned on or off. Are there other ways (besides manually) that these scenes could be turned on or off, such as through a program? If so, this may limit our programming options to "status" if we choose to use a keypad button as scene status? I notice that, in general, the security light is on. Only stated exception is when party scene is on. Are there other exceptions, such as daytime/nightime, motion? What do you think about restating your view of the world in a different way, such as: security lights are ALWAYS ON, except when party scene is on? Does restating your goals in this way suggest a solution? In the end, you will need a program. The conditions of the program will be based on answers to many of the questions, above, and to other questions yet asked.

No. Your progam, as posted, should turn the upstairs scenes on or off, if at least one (which is a logical OR) of the three conditions are met. If one of the keypad B buttons is pressed, status of the remotelinc (and other B button) should be irrelevant. Are you saying that you saw examples where the event viewer registered an ON or OFF command, yet one of the programs did not initiate!? How are you judging whether "it works"... based on status of upstairs lights, or based upon program status as shown in the ISY admin panel?

Like with your B buttons, I universally prefer scenes to accomplish this goal. Create a scene (I will call it "buttonA" and put all A buttons in, as controllers. You want the IOLinc relays to turn on and off when one of the buttons A is pressed on/off? Put the relays in the same scene "buttonA". If, in addition, you want the relays (and buttons) to turn off automatically after ten minutes, create a program: if status "any button A" is on then wait 10 minutes set scene "buttonA" off else A few notes about my suggested approach: - I assumed that you wanted your two relays to come on when you press EITHER of the two A buttons. BTW, I don't believe your approach would accomplish this goal. - I assumed that program "MH Driveway Timer' is your posted program - I assumed that you wanted the two relays to go off immediately when you turn off either button A (this was not clear to me). - there is no such thing as scene "status". Therefore, there is no program condition based on scene status. - given that all buttons A are in a single scene, all will be simultaneously on or off, never mixed status. Therefore, it should be sufficient to pick any single button A in that scene as a representative indication of scene status - the scene, itself, will take care of manually turning on, and off, the relays. The only thing you need the program for would be the automatic turning off of the lights after 10 minutes. - keypad buttons have the unique characteristic (at least in toggle mode) that it is impossible to turn on a button that is already on, or to turn off a button that is already off. Given this, I see no reason to include your second condition "And Program 'MH Driveway Timer' is False".