oberkc

I normally associate this "croos link" expression to the manual (using button or paddle presses) process of linking devices to each other. To be sure, have you define a scene in the ISY including the button and microlinc as "controller"? If you cross-linked these manually, then you need to clear this and create the ISY scene. I cannot help with the REST interface, but suspect the concepts are the same as that for the admin panel. When you want multiple devices in a scene to track the same status, one must send commands to the scene, rather than to a device in the scene (even if that device is a controller). From the admin panel, choose the scene in which you created (or should have created...see response, above) to cross-link the devices. Turn that scene on/off. Observe KPL status following microlinc.

Your originally-stated problem was that one of your lights "turns on at other times". The problem quoted above is a different problem, possibly from a different cause. Are you still getting the one light turning on at other times?

On this point, I have the understanding that these CAN coexist. Whether there is a single controller that speaks all four "languages" is another issue.

I think you will find that these need to be defined as controllers, rather than responders. Regarding the switch ON levels, remember that such levels can be defined differently, depending on controller device is invoking the scene. For example, when controlling the scene via the ISY, they could be one level. When controlled via a switch, they could be at a different level. In you program, make sure you are setting the ON levels when the switch is acting as controller. I hope this is sufficiently intuitive, since I forget how that command appears, or how it is created.

I claim no special abilities to read these logs, but it appears to me that something is causing your ramp rates and ON levels to change. I cannot help but continue to suspect there is some program somewhere that is causing this to happen. I also see a "fast" command in there. I don't know how this would happen other than by direct physical activation or a program. I know you have "combed" through the scenes, but select the device in question from your device tree. At the right side of that page is a view showing in which scenes that device is a controller and responder. Double check to see that there are none.

While I cannot help with the hub app, I have been experimenting around with the integration of tasker with mobilinc. One thing this allows is the creation of a widget which, with a single button press, allow you to send a command to a device, send a command to a scene, or trigger a program. Perhaps this may help with your (and my) concerns about having too many button presses to execute an action. Of course, this works only with android.

Possibly. Make sure that, from the app, you are turning on the scene.

As further confirmation of LeeG's response, I just tried manually sending OFF command to a motion sensor. Can't do it. I created a test program to send an OFF command to a sensor. Did not work. I cannot think of a way to have a sensor go from ON to OFF other than having the sensor send this command.

I had an issue with my morning industries lockset that may (or may not) be related to yours. I started getting intermittent response to pushes to keypad buttons. Sometimes you would hear the faint beep on each button press...other times not. Sometimes you would get the multiple beeps when pressing the unlock button (after entering the correct combination). It turns out that this problem was solved by reseating a little connector inside the lockset. In case you don't remember (I didn't), when you install the lockset, there is a little connector between the interior and exterior parts of the lock set. I assume a bit of corrosion had set in on that connector and that reseating this connector re-established continuity. Regardless, my lockset was NOT working, now it IS WORKING. It took about three minutes and a phillips screwdriver. You might give it a try if you run into this problem again.

For me, my choice of wait or second program depends on duration mostly. If a couple of seconds, I would be more inclined to use a wait. If on order of hours, I would use a second program. Other factors also come into play...powerfailure during wait...conditions that can be retriggered by THEN statements...etc.... All other things being equal, it is a style issue in my mind. Unfortunately, things are rarely equal.

Emphasis on "some". Yes, this can be done. "Blinking" lights is not an inherent insteon capability, but an ISY program can be set up to simulate this, to some degree. Besides the obvious (ISY, mini remote, various insteon switches and modules), I consider two access points and a couple of filters to be near-universally required for any insteon setup beyond a couple of switches. The rest is wholly dependent on what you intend to control and how your house is wired.

Yes, it can be done. Yes, a mini remote can be programmed to change the value. Or you can use an insteon switch or keypad button. Or you could use a cell phone. Wth android, tasker, and mobilinc, you could eve set up a system where it would arm/disarm automatically based on cell phone location.

I am unsure I understand your question. Setting a scene ON will turn each device within the scene to it's pre-defined ON levels. Setting the same scene to OFF turns all devices in the scene to OFF. The fact that you named the scene "all INSTEON off" does not mean that you cannot use that scene to turn this scene ON. -action ON will turn each device within the scene to it's pre-defined ON level, at the pre-defined ramp rate -action FASTON will turn each device within the scene to 100%, instantly -action FASTOFF will turn each device OFF, instantly -action OFF will turn each device OFF, at the pre-define ramp rate

Too bad. I continue to wonder how I got so fortunate.

I have a chamberlain opener, but forget the specific model. The wall opener has buttons for OPEN, LIGHT, and LOCK. The wall unit also has a motion sensor. Given this, I would have assumed that the wall unit is a bit more sophisticated that a simple contact closure. Having said this, mine works fine by connecting the IOLinc directly to the opener terminals. Don't assume that yours won't work without first checking.

Nice. In case I was not clear, my perception about people reading instructions was mostly to wonder aloud whether a sticky post would help, as opposed to an accusation towards any specific individual. I agree with LeeG...the garage door example is about as complicated an insteon device that exists. It took a bit of trial-and-error on my part, for sure.

Good. It seems to me that the program is correct for what you want. If the bulb is coming on during the day, I suspect the reason is something other than the program. Is it possible that the motion sensor was linked manually to the bulb, outside the ISY?

I am not sure whether you confirmed or denied LeeGs suspicion. Do you have a scene defined in the ISY that has the motion sensor as controller and the LED bulb as responder? If so, delete the scene.

A non-dimming switchlinc will work for basic functionality AND can send dim and bright commands. The only downside that I can tell is that the LED indicators won't show a dimmed level. Otherwise, it will work in this capacity just like a dimmer.

It does seem as though garage doors are one of the common themes. In my mind, the "ideal" setup is in the wiki, but I agree with LeeG that personal preferences and setup can vary quite a bit. Given that a measurable number appear not to read the wiki, dedicated forums, or even the user manual, I hold little hope that a sticky topic will fare much better.

Depending on how the scenes and programs are established, toggle modes for the KPLs, and configuration of the IOLinc, it is not hard to get them out of sync. One clue would include whether the status, as shown by the ISY admin panel, is the same or different than that of the actual KPL.

No, I don't believe so. Your "typical day" code is triggered only by time. Changing thermostat values will not retrigger the program, thus will not interrupt on-going wait statements. If it does what you want, then it is good. Whether using four programs versus your approach is better?...well...the only thing that I can think of is power failure. Do you get many (even short ones)? If a power failure occurs, it may interrupt an on-going wait statement and halt executing programs. Perhaps four programs would be more tolerant of this possibility. I also suspect that making schedule modifications, should the need arise, to be a bit more straightforward with four separate programs. However, if you place value on minimizing the number of programs in your ISY, then your approach has merit.

I think it good practice that when one has a large quantity of electronic gadgets in one place, one should add a filter. It is pretty easy to use a single filterlinc to power the various UPS, surge suppressors, and power supplies normally associated with today's home office environment. The cost of a filterlinc is money well spent for this purpose, in my mind.

If you have the motion sensor as part of your ISY system, it is trying to communicate with the PLM, as a minimum.

I am sorry, but I have no idea what you are asking