oberkc

Yes, scene size would also be a contributing factor I expect

Short of reducing the number of devices, the only thing i can think to do would be to reduce the number of scenes.

As an aside, i also find it interesting that relatively few questions on this forum are related to programming issues anymore. Just looking at the active topics of the last couple of days (about 20), this may be the only one. I am not sure what one can conclude from this, but it is at least interesting to me.

The trigger part confuses most of us, I suspect. For example, i offer the following program... If Time is from sunset To sunrise (next day) Then Turn on a light Else Turn off a light Many would assume that such a program is in a continuous evaluation mode and would force a light to stay on at night and off during the day. Should the light be manually turned off during hours of darkness, they believe this program would automatically turn it back on. In truth, this particular condition has two triggers: sunset and sunrise. It is only at these two trigger points each day that this program would run. The rest of the time, this program sits idle. Each statement in a condition could be a trigger. A program will run when one or more individual triggers is met. once triggered, the entire condition is evaluated, either ligically true or false. There are some other subtleties, but this is the big one. Looking over the manual and wiki again, I agree that this could be made more clear.

Yes, i understand your points. Unfortunately, those sources I mentioned are, in response to your earlier question, all that I know. I dont even remember where I learned most of my ISY programming skills, but i suspect it was a ombintion of all those resources you mentioned. I also assume that the amount of activity on the forums is an indicator that others also find them less-than-comprehensive. Just as likely is that many dont bother to read them at all, so I applaud your hours spent studying this stuff. I find the big thing is to realize that each program condition is also the program trigger. I find the conditions and actions, themselves, to be relatively intuitive. It is in the understanding of what triggers a condition to be evaluated that took a bit of practice. Unfortunately, I doubt that this is much help for you.

I dont know what you have seenor missed. There are quick start guides, user manuals, the wiki, and videos.

DerekN, in retrospect, I wonder if switch B was, in fact, a controller, but the responder level for switch A was somehow set to zero.

I have noticed that some of the insteon devices have a "resume dim" feature. I do not know which switches you have or whether they have such a feature, but I could imagine that enabling this feature could solve your problem. Unfortunately, I have not done much experimenting with this, so I cannot offer a lot of help here.

I agree with jratliff here. There are lots of ways to do it. There are also questions you should probably ask yourself. - do I still want motion to turn the lights on, even when my keypad button is ON? - what do I want to happen when the lights are on and I turn OFF my keypad button? - what do I want to happen when the lights are OFF and I turn ON the keypad button? - is the motion sensor and switch part of a scene together? Depending on answers to questions such as these you could try variations like: if control motion sensor is switched on then turn on light else nothing if status keypad button is off and status motion sensor is off then turn off lights else nothing

Not true (at least not true for insteon or zwave devices I use). Status events WILL trigger a program....any CHANGE in status will trigger evaluation of a program "if statement". I don't use insteon thermostats, so I am extrapolating here. But if you want a program to trigger when fan changes from OFF to ON, If status fan is on then do something There may be problems with such a program if you have wait statements, but otherwise I would expect this to work.

It is simple, if not intuitive. To use an example, let us say you have a dimmer switch called switchX, and you want the local ON level (the level to which the load attached to switchX goes when you turn on switchX) to be changed at a given time during the day. The program would take the form: if it is a given time of the day then in scene deviceX set deviceX to new local level Of course, exact syntax would be generated for you from the dropdown boxes. Let us assume that you want adjust the responder switch (call it switchX) ON level when responding to a scene controller switch (call it switchY). The form of the statement would be: if .... then in scene switchY set switchX to new level

I really don't know. If the device responds normally, then I tend not to worry about things. If it does not, then I start troubleshooting. I have never found the error messages to be of much use in the troubleshooting process. The big thing, I believe, is that I don't think one can query device, perform a link check, write updates, etc.. on battery devices without first activating those devices (puts them into programming mode). My perceptions are that funny things can happen when the PLM is in a bad mood. First, however, I would ensure that your PLM is on a good, clean circuit. Are there lots of other electronics on that circuit? Have you ever tried the plm on the end of a long extension cord, plugged into another circuit, to see if that helps?

Yes The only place I can recall that defined error numbers is: http://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:Errors_And_Error_Messages I never found it to be overly helpful. I never discount a device failures. But, I have had very few. I would tend to look elsewhere.

I think stusviews identified the proper solution (use "control" versus "status"). Still, I am curious why you have the duplicate ON and OFF commands (separated by 15-sec waits)?

When two devices are linked via scene, such as your remote and switchlinc, the PLM is not involved. I would not expect moving it around would matter. Besides the suggestion from Larryllix, it is worth double-checking the ramp rates and ON levels for the reponder device/miniremomote scene. Within that scene, click on the mini remote button that is controller. Do you still see the expected ramp rates and responder levels for the switch?

I would differ from larrylix (perhaps better described as an attempt to clarify) on the response to question 1. I would definitely NOT (no maybe about it) describe the evaluation of program conditions as "continuous". Program conditions are only evaluated upon triggerining events, with those events being driven by each of the statements in the program condition. To offer an example...a program condition such as: If time is from sunset To sunrise (next day) will be evaluated exactly twice each day.

I have been playing around with the echo a while. I am not convinced that I value voice control much, but still find the whole thing interesting, so this has been an on-again, off-again activity for me. I have several Harmony hubs around the house, and have a spare IRLinc receiver, so I was curious whether the harmony could be used as an intermediary between the echo and the ISY. I have come to believe that a dedicated hub for lighting would be best, because the harmony is very much into "activities" and tends to turn off one activity when another is turned on. (I really did not like it when my TV turned off when I turned on the lights.) The other day, I noticed one of the original hubs (without the HA buttons) available for $50, so I thought I would try that, dedicating this hub exclusively to lighting control. The harmony has, in its database, the IRLinc 2411R, which basically simulates the CC remote that comes with it. The harmony can, therefore, be programmed to imitate the CC remote commands. Unfortunately, when added to the ISY, the IRLinc shows up as only four scenes, A-D, even though the included remote has many more scene buttons beyond A-D. This means, as best I can tell, that the IRLinc is limited to controlling four scenes, or triggering programs based upon the four buttons. Thus, the harmony/echo will be equally limited to four scenes/programs. With all the hardware in place, I found that my little echo can now control my insteon system. Basically, adding the correct hub to the echo, and enabling the harmony skill, I now have scenes A-D that I can control via echo. Adding those buttons as controllers for key scenes in my house, I can now control those scene with voice commands. No monthly fees. Even better, it works with the blue harmony skill. Alexa, turn on lights. No need to say "alexa, tell harmony to turn on lights" Let me know if you want any more details. One has to pay attention to device power settings, and set up custom start and ending macros for the harmony, but it was not very complicated, and works very well.

I have not had this happen before, but cannot help but wonder if this is a PLM issue. Does your PLM show as "connected"?

I tried simple control (just renamed from roomie) a couple of years ago. I really liked it. It found my connected TVs and I could use it with my global cache devices. I find myself much opposed to monthly fees, however, and having devices that operate only with the support and permission of the company. The echo support makes me want to re-consider simple control, but I am not sure that I want to have to remember and speak such long phrases as "alexa, tell simple control to do something..." Lack of android support is also near-disqualifying for me. I have several harmony remotes, including the elite. I have played around with the echo integration. While turning on/off activities works well (alexa, turn on TV), the skill for some of the of the other functions require the longer phrase "alexa, tell harmony to turn up the volume". I find it just as easy and, perhaps easier, to simply pick up the remote or tablet. Another major shortcoming for me is that I use roku devices on a majority of my TVs, and have yet to find alexa skills that allow me to navigate through the roku menus and channels, and doubt that such skills, were they to exist (alexa, tell harmony to press the left button) would be an improvement over the physical remote. In my mind, the echo will be of little use to me until there are context-senstive commands (such as, simply, "left" or "louder") Given my aversion to monthly fees, I don't have the ISY portal. Out of curiosity, mostly, I have played around with using the harmony as the glue between my alexa and ISY. I have the IRLinc reciever, and found that device in the logitech database. I found it relatively straight-forward to control some lighting scenes (four, at least) with the harmony remote. The next step was to see whether alexa could do the same through the echo. The short answer is, unfortunately, no. While I could set a lighting activity and the echo could easily turn on and off, the result was an equivalent of an ALLON or ALLOFF command...not what I wanted. Activities are also not independent. Turning on one activity turns off devices in the other activities. Thus turning on the light activity would turn off the TV activity. Yes, there are power settings in the harmony, and I started playing around with those, but decided that this was becoming more work than it is worth, given that I was not convinced that any of this was an improvement over a simple button press on a keypad or remote. Still trying to figure out if I have an interest in voice control or a use case for the echo. Maybe I will try it as a morning alarm. Maybe it is good for morning weather reports? I am having trouble seeing a compelling use for this echo thing, more than just a technology curioisity, justifying the work and expense. We will see how I feel when sonos skills come.

I think the term "signalinc" has been used for different devices. Old signalincs are those predecessors to the access points/range extenders. Current models are those passive couplers. Perhaps that is from where some of the cofusion comes.

I believe one CAN replace ZigBee board with zwave.

I like the flexibility that the zwave board gives. I use several zwave motion sensors. I cannot say whether they are more reliable than insteon, however. I have had no failure of any motion sensor, including x-10, insteon, or z-wave. Neither am I confident a zwave sensor can be used in a scene relationship, so there may be those program delays so many seem to dislike. The other hesitancy I would have about a "new-and-improved" insteon motion sensor is compatibility with the ISY. It seems to me that there can be a delay between release of the new device and ISY ability to recognize it. Most of the time, however, it seems pretty quick.

This is all from memory, but I recall that the ISY would also write updates at next opportunity. I understand that such opportunities can occur during a short time after motion triggers and, once triggered and the write-update window opens, the ISY would initiate the update. I assume, also, that the automatic update buttons would need.yo be enabled. Or...It could be a looming device failure.

My understanding of the meaning of these little icons appears is same as yours. The only thing that I can think might have recently changed would be that you have disabled automatic write updates at the ISY admin panel. This assumes you have the pro version. This setting is global and there is one for battery devices and one for external powered devices. It is a little icon along the top menu bar.

Yes, there are such settings and, yes, they are configurable via ISY. Check out, also, the jumper settings as described in the motion sensor manual. One (believe it to be jumper 5) need properly set to allow configuration control via software such as ISY.