oberkc

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".

Yes. If a relay can only be a responder, then there is no way for an operator to initiate a control command from that device. Responder will be fine.

Me, too. Bring it up in the mobilinc forum. The company response has always been a little cool towards the idea, either because a percieved lack of demand or out of concerns that someone could accidentally activate something without knowing.

Ah! So the C and D buttons are the ON and OFF buttons of a single scene. I am glad you have it working. I am not sure that I understand the difference between primary and secondary keypadlinc. However, when I hear things like not "that well" or a "couple times", this makes me think intermittent problems, to which I instantly wonder if your ISY is, or is not, seeing the commands from some of your keypads. Programs usually work always, or not at all. Communication problems, on the other hand, can be quite hit-and-miss. To test for this, I would open an event viewer and press the mis-behaving keypad button a few times. Does the event viewer always register the button press?

To my knowledge, this cannot be done with Mobilinc. I believe you will need to observe the sensor for garage status and use the relay for garage control. Perhaps there is someone who has figured this out and can report. If so, I will learn along with you. As an aside, I use the android version and my wish is for widgets that can be configured for one-touch commands, for things like garage doors.

To my knowledge, this cannot be done with Mobilinc. I believe you will need to observe the sensor for garage status and use the relay for garage control. Perhaps there is someone who has figured this out and can report. If so, I will learn along with you. As an aside, I use the android version and my wish is for widgets that can be configured for one-touch commands, for things like garage doors.

If it is working, it is not "wrong", but I believe there are benefits to using a single scene, rather than two programs. Put all buttons, including those two relays powering the lights, into a single scene, all as controllers. I think you will find the response faster, more reliable, and still working in the unlikely event of a failure of the ISY or PLM. Any button in this scene that you prefer not acting as controller of the global scene, set only as a responder, rather than controller.

I believe you have answered your own question. Yes, all three must be defined in the scene as controllers.

For this, I would remotelinc buttons C and D to your existing scene "Sceme B", as controllers. Once added, select button C from the scene and define ON levels for the two B buttons as 0%. Then select the D button from the scene and define ON levels for the two B buttons as 100%. For this, I would simply update your existing two programs: If Control 'Remotelincs / Upstairs Remotelinc / Upstairs RemotelincC-D' is switched On or control "KPL button B1" is switched on or control "KPL button B2" is switched on Then Set Scene 'Upstairs On' On Else - No Actions - (To add one, press 'Action') Make the same change to your other program, except for the condition should be "is switched off", rather than on.

And if, after running the quick test suggested by LeeG, you find it the UPS that is causing the problems, yes, a filter should work (and is THE solution I recommend). Moving the PLM to a different circuit may also work, but I would rather eliminate the problem that the UPS represents to my entire insteon system.

I takes a little while to get your head wrapped around a few of these concepts. Triggers, conditions, waits, etc... Neither is it easy to describe it in words, even if you think you understand it.

I think there is a misconception here. Folder conditions do not DICTATE when a program will run. Folder conditions do not force, or cause, programs to RUN (even with folder conditions enabled, a program still requires a trigger to run). Folder conditions do not prevent programs from running (can still be triggered by conditions external to the folder, such as by another program). Folder conditions simply ALLOW or PREVENT program's IF conditions to trigger itself. In effect, program conditions ENABLE or DISABLE programs. Your current folder condition (pump is off) allows included programs to run ONLY if the pump is off. If the pump is on, NONE of the included programs will trigger, including the program to turn off the pump.

Something needs to tell your program (then/else) sections to execute. This is either a program condition (if), or being called by another program. If you have an empty IF section, and this program is not being called from another, it will never run. I suspect you are making this harder than it needs to be. Why not try: if time is from 8:00AM to 1100AM or time is from 3:00PM to 6:00PM or time is from 9:00PM to 11:00PM. then turn pump on else turn pump off No folders. Simple (hopefully it works)

Yeah, we went all over the map on that one. In everyone's defense, however, a lot of this discussion was arguable initiated by, and addresses, your initial "side note" about continued use of insteon. As the ISY becomes multi-lingual (adding zigbee, z-wave, etc...) this gives one options to introduce other types of devices in the hope that they are more reliable (as you hoped). OK. that was a stretch.

if you don't want a control, on what basis do you want the system to begin and end the 15-minute cycle? Temperature? Time of year? Or...do you want it simply to run a continuous duty cycle, 24/7, 365 days per year?

Woa!! That response sure caught me by surprise. In addition to the other responses, I also recall that nikki specifically asked about our thoughts on the subject of whether or not to continue with insteon. I thought we were all simply offering honest response to that question. I actually think it nice that we can be open about such a topic. The openness adds weight and confidence to the responses that are more positive.

I have experienced few insteon device failures, but I would be lying if I did not admit to being a little nervous about the prospects of this in my future. I can also tell you that one of my older keypads is behaving as you describe...it appears to go completely dead (no LED indicators, no function). I pull the little tab out for a short period (a few minutes), press back in, and the keypad works again. It has been working for a while since last incident, but I wonder if this is early indication of pending failure. That type of behaviour makes me intially think communication problems. Have you performed any diagnostics (formal or otherwise) to check for this? Do you ever get an indication when first logging on that the ISY cannot communicate with one or more devices? Have you ever performed a scene test? How many insteon devices do you have? How many are "dual-band". Do you have access points? Are these confirmed on opposite legs of your electrical system? Do they still appear to be working? Have you added any new electronic devices to your house? Where is the PLM plugged in? Next to (same circuit) computers, UPS, other peripherals? Sorry to throw a bunch of questions, but these are the kinds of things I would be asking myself if I were experiencing the problems you describe. I can't help with your decision about whether to continue or to abandon insteon. I suppose it would depend on how many devices I had, how many had failed, how much discretionary funds I had, and the value I placed on automation. I can tell you that I have had no problems with smarthome covering warranted items, and most of the time the sales and service reps are quite easy to deal with. Every once-in-a-while, (once in person) I run across a rep that has a bit of an attitude that I find offensive, but I am not sure that this is unique to smarthome. One consideration is the newly-introduced (actually not quite available for general release, I understand) Z-wave support in the ISY-994. If this becomes broadly available to folks like you and me, then this may offer a graceful exit from insteon over to Z-wave. If one is unhappy with insteon, and as insteon devices fail, one could try out a z-wave replacement.

I agree. This program cannot, in my mind, produce a notification at 3pm, as written, regardless of which day it is. Another program notification? Another program calling this one then path at 2:45?