oberkc

Hopefully it will work as well for you as it has for me. Remember, though, the hue gadgets can be called by the ISY only via program...no scenes.

Not natively. With the network module, you can send commands to hue devices. Check out this wonderful narrative: http://forum.universal-devices.com/topic/19565-isy-and-phillips-hue-integration-step-by-step-for-dummieslike-me/ Another nice resource to compliment the instructions, above : https://developers.meethue.com/documentation/core-concepts

You are missing no simple trick. One of the regular forum members has created a relatively complicated set of programs to handle this, but I simply go in every so often and update them. If you are interested in giving it a shot, I found the discussion on the wiki: http://wiki.universal-devices.com/index.php?title=ISY-99i_Generic_Calendar_Using_Programs_and_Variables I agree that this feature would be nice. I understand this is available in SW build 5.X, but it is, apparently, not ready for prime time quite yet.

Overhead lights?

To paraphrase paulbates, create a scene with three devices: the switchilinc and two buttons. All should be defined as controllers wihin that scene.

Mine is the 468 "camelot". It is hard to imagine that they would be different other than cosmetically. I will double check later to be sure.

I have been tinkering around with my system and checked on my schlage lock. It DOES appear to trigger programs via "control" condition, and DOES appear to have ability to distinguish between manual and keypad actions.

My limited experience with Z-wave devices suggests that "status" is the only condition that can be use with some. I have a switch, for example, that does not trigger "control" conditions. Whether your particular lock is so limited...I suggest running your own experiment. Create a program based on "control" of the lock and see if it triggers from an unlock event. If not, try status. Much of what I have learned has been by similar experiments. Whether or not this could be limited to just keypad actuation is likely a feature of the lock, and not something that could be distinguished by the ISY separately from some other method (my best guess).

Truth is, I have used the "crawl" option sparingly, so my experience is limited. What I believe happens is that the ISY would, indeed, see the old hub ID and would then try to add the device. Unfortunately, with the hub being gone, it cannot respond to the effort to add it, so I believe it will fail. Hopefully, I am wrong.

The first things that come to mind are lack of communication between legs of electrical system, or lots of noise or interference on circuit with PLM. Have you confirmed phase coupling via dual-band device and instructions in manual? Do you have other electronics on circuit with PLM, such as computer, UPS, modems, routers, etc....?

Alternatives also include manually inputting the insteon device and address. This could come in handy for those inaccessible devices. I am unaware of a method for globally deleting a particular link, such as from the old hub. Having said this, once you crawl your network, it may be useful to perform a link records check of the devices versus what the ISY comes up with. Performing a "restore" device may eliminate the dead records from the various devices.

You could even combine the two programs. If From 11:30:00PM To 6:30:00AM (next day) or From 4:00:00PM To 9:00:00PM (same day) Then Set 'Scenes-Inside / MBath Towel' Off Else Set 'Scenes-Inside / MBath Towel' On

Blueman2, Perhaps your original question was answered and I missed it. I expect you two programs to work fine together. Your understanding sounds about right to me.

johnjces, I am a little unclear on the details. Do you want this to "fire" only once per week, and no more than once per week? Seven day week? Five day? Something else? I believe this can be done on version 4.5.4. It would probably be a brute force approach, with several programs involved. Conceptually, one can create a program to generate a random variable value between 1-7 (alternatively, may be between 0-6, but I would have to investigate). At the beginning of each week I would run that program. Once the variable is set each week, I would create seven programs, one for each day of the week. Each program would check if the weekly variable matched the day of the week. If not, do nothing. If so, run a path which fires whatever event you desire at a random time. This is all experimental for me. These are program conditions and actions I don't use personally. Still, I think it has a good chance of working.

I doubt that they were used, but i dont think you would be the first to have recieved units with pre-existing links.

JayC, Regardless of what happened or how, you may give the advice from MWareman a shot. It might work and is less work than a full reset. Your symptoms do seem to suggest that there are some residual scenes out there somewhere, somehow.

If all scenes involving these switches are deleted yet they still behave strangely, delete from ISY, then factory reset each switch. Does the problem persist? If not, add back to ISY and create any new scenes needed.

Start with determining: - are the lights part of a scene - the specific time the lights come on unexpectedly - whether a program fires at the same time - other activty in the log at the same time

I use it on android and have heard the same allegations. Perhaps the android version is missing some features that the iOS version has. This is probably most significant for those who value being able to look at camera imagery using the same app being used to control the house. Yes, that seems to upset some. Still, when measured on it's own merits, and compared to the other android options, I think it holds up quite well.

I use mobilinc. I am not in a position to say what is best overall...I think it could depend on your needs. For me, mobilinc offers a couple of important features not found in other apps, including widgets and integration with tasker. I have no trouble recommending it. If all you want is simple access to devices and scenes, however, other may be just as good and less money. You may also find one interface more appealing than another.

Get an app. Several are listed in the section for third party products. Or go to google play store and search for insteon and ISY.

hello lithiumus, based on my experience, there are two non-toggle modes: non-toggle ON and non-toggle OFF. In non-toggle ON mode, it will flash then stay on, regardless of starting state. In non-toggle OFF mode, it will flash and stay off, regardless of starting state. I know of no "non-toggle" mode where it simply stays in whatever state it started. I find this experience consistent with the manual for the keypad, as well as the options available from the ISY admin panel. I have no opinion on what it "should" do...only what it does in my house. Either I misunderstand what you are saying, or our experiences and expectations are different. My oldest keypads are about 7 years old. My newest about a year. I have noticed no change in behavior regarding toggle mode.

Lithiumus, Based on my experiences, a botton set to non-toggle ON will, when pressed, flash a couple of times, then stay ON. Based upon that, i find the behavior you describe more like: unexpected and abnormal.

Litiumus, What I find interesting in your post is that, in the second paragraph, you state that the original keypad button is in non-toggle ON mode, yet you say it blinks twice then turns OFF!? I find that to be abnormal. My buttons, configured such, would flash and stay ON (much like your second button). The question, in my mind, is what is different about your first and second button xonfiguration that would cause the.different behavior? Regardless, I can think of no better solution than stusviews suggested approach.

I have no opinions beyond those I have already provided. Yes, it could always be a device failure.