oberkc

I do not recall problems sending direct x10 codes (don't do that much anymore). I am wondering if the "repeat 2 times" from the earlier programs cause some sort of signal clashing. But, like I said, it has been a while. Did you try the "belowcabs" approach in the original programs at one point (or just a single x10 command)? I am a little curious about why the original programming did not work. Glad you got it working.

So, you want a physical press of button A of a keypad to trigger an x-10 device, correct? if control buttonA is switched on and control buttonA is not switched off then send sppropriate x10 code (on) else send appropriate x10 code (off) Create a similar program for the B button. No need for variables. No need for multiple programs. I don't see anything jumping out at me regarding your current programs. If I were there, and interested in troubleshooting, I would be watching each of the variables to see if they are responding as you expect, and watching the program logs to find out which were not executing when you expect and whether other ones WERE triggering that you did NOT expect. I would watch the event viewer to watch for unexpected x-10 commands. I have no clue how or if the houselinc is affecting all this. I can tell you that I consider it highly likely that there is something else yet undiscovered coming into play here. I do not consider it likely that there is a programming bug. Do the keypad buttons have any x-10 addresses assigned, possibly? Are there other programs being triggered? This should not be too hard to troubleshoot if you want to take the time.

An example? Of what? A little more detail can help, perhaps. First, you must have the network module. It is an add-on to the ISY software. It cost $50, I believe. Do you have it? If not, you must purchase it (from "help" >>> "purchase modules".) Once you have the module, under "configuration" tab, you will now see a "networking" tab. You will have to "add" a network resource for every action you anticipate. You would need a resource to turn on a hue light to a certain color and intensity. You would need a different resource for a different color or intensity. You would need an additional resource to turn it off. You would need those resources added for each hue device. Do you know how to find the IP address of your hue hub? Do you know how to establish a static address for the hue hub from your router settings? These things will be important. To add a resource, from the network resources tab, select "add". Give it a name that will help you remember what it is and does. Double-click the URL associated with the newly-named resource. Fill in the fields in the pop-up, consistent with the instructions from the post linked earlier. Once you have established the network resources, create an ISY program which calls the resource. It can be as simple as: if time is sunrise then resource "myhueresource" You may need to create mulitple programs, depending on your needs and resources created. From mobilinc, find that program and run "then" path to manually turn on (or off) your hue lights.

I must admit that I would like a better description of what you WANT to happen. I find it difficult to look at a set of programs and try to figure out why it is not working as expected without knowing what is expected. It might also help to better understand what devices are....are "above sink" and "under cabinets" insteon devices? These are different than A1 and A2 x10 commands? Having said these things, the only thing that strikes me as unusual is the same as larryllix. Why did you disable the last four programs? I also cannot escape the suspicion that these programs are more complicated than need be. For example, program ID 0012 has two conditions, a variable and a device status. In essence, these conditions are redundant, since the variable is ultimately based on the status of the device. When the "above sink" is ON, the variable will be 1 and, when OFF, the variable will be zero. Basically, both conditions are the same.

Yes. Set up programs to call the hue configuration. From mobilinc, call the program. Unfortunately, you will have to pre-define the hue settings that you can call.

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.