apostolakisl

Ditto on LeeG. The scene should have been there with just the single kpl button in it. I have several such scenes whose only function is to trigger a program when pressed.

I never turn the power off. I just pull the power disconnect tab on the Insteon device to prevent arcing which can damage the switch. If that makes you nervous then don't do it. I take no responsibility for you if you do it and get shocked so do it at your own risk if you like. I have done it hundreds of times and have a standardized approach that keeps bare hot wires exposed only while I am actually uncapping/capping them. It is possible to handle hot, uninsulated wires directly if your body isn't not part of a path to ground. I rarely do this but have. You must have rubber shoes and can't be touching anything at all that is grounded. That includes the chassis for the switch. I watched an electrician once handling my hot 220 main house feeds with his bare hands. I don't do that personally. As long as your body doesn't provide a path to ground you won't get shocked. The biggest trick is when you have regular switches in the same box since they have exposed lugs on the side. Again, I have a standardized approach which moves them out of harms way, but you can also do a wrap with electric tape. I really hate turning the breaker off as it tends to mess with all kinds of stuff and furthermore my electricians didn't do the greatest job of labeling so there is that pain to contend with. Plus, when the breaker is off you need alternative light source. Also, I have had troubles getting my v35 switches replaced. How do you get them to do it?

Exactly, but just to be a little more clear, even if you don't have a multi-button scene, still create a scene for the kpl button and just put the button in all by itself.

I replaced all of my switches as well. It is probably best done one at a time anyway and it really doesn't take longer. I found that I would get things messed up one I tried doing a bunch at once. If you carry your laptop around with you to each location you are changing a switch, then, as soon as you get it wired in add it to ISY without any name. Then use the "replace with" command. While it is writing the links you can be putting your swtichplate cover back on and taking the cover off of the next one. Unless the switch has tons of links, it is usually done by the time you finish putting the switchplate on the previous one and get the switchplate off of the next one.

I can't confirm the changed part since I only recently started using this part of ISY. I can confirm that the \r\n does dissapear when you hit update and it does seem like it is replacing it with a carriage return.

Can't help you on the circuit breaker except to tell you that my panel is square D and it doesn't cause any problems. As far as whole house surge supressor. I have a Leviton model. I have no idea if it was a waste of money or not. It is a self sacrificing deal that dumps the extra current to ground to save your house (or at least that is the claim). So far it just sits there with two green lights. Perhaps one day I will come out and the green lights will be off indicating it died saving my house, or my house will be fried and I will know it was useless. It certainly wasn't hard to install at least.

check out this thread. http://forum.universal-devices.com/view ... highlight= I very much like my itach. I have learned several remotes so far and have asked that they create a database on the wiki to share all of our learned remotes so others can just download them. Hopefully that will be comming soon.

Michel, Great, thanks. So, let me make another suggestion. On that screen that comes up asking you to confirm the restore, you might include a note that says "During the restore your ISY console will not function, you will not see progress bars, nor will you be able to log back in should you close your console. Please be patient as the process can take up to 10 minutes per device." I know I have been making lots of suggestions about this sort of stuff, but I think people will really appreciate the extra information as they use various features for the first time. It prevents anxiety and wated time. Especially since ISY doesn't have a formal owners manual where this might otherwise be explained. Lou

After having replaced a ton of switches because of failed paddles my system became less stable. I speculated that there were some errors on devices and since I had replaced about half of my stuff, I decided to just go through and factory reset every single device and run a restore. So, yesterday I did that. During the restore, the ISY java console went dead. Needless to say, I had great anxiety during the 2 hours it took to complete the restore wondering if I had just completely scrambled my whole installation. The only comfort I had was that the PLM was blinking activity and the ISY tx/rx lights were blinking. After about 2 hours the console responded again and my system is working well. During the restore, what I had was the java console displaying like normal but not following commands. It would move from screen to screen and show devices I would click on, but if you tried to do a command, notta. It also did not indicate that any activity was going on. I closed the java console and tried to reopen, but the ISY wouldn't respond at all. The "finder" would find nothing. Question, is this normal? I would have expected to see it running down the devices with the write commands as it progressed.

After having replaced a ton of switches because of failed paddles my system became less stable. I speculated that there were some errors on devices and since I had replaced about half of my stuff, I decided to just go through and factory reset every single device and run a restore. So, yesterday I did that. During the restore, the ISY java console went dead. Needless to say, I had great anxiety during the 2 hours it took to complete the restore wondering if I had just completely scrambled my whole installation. The only comfort I had was that the PLM was blinking activity and the ISY tx/rx lights were blinking. After about 2 hours the console responded again and my system is working well. During the restore, what I had was the java console displaying like normal but not following commands. It would move from screen to screen and show devices I would click on, but if you tried to do a command, notta. It also did not indicate that any activity was going on. I closed the java console and tried to reopen, but the ISY wouldn't respond at all. The "finder" would find nothing. Question, is this normal? I would have expected to see it running down the devices with the write commands as it progressed.

I assume you have just one switch and one outlet. If not, put the switches together in a scene and put the plugs together in a scene. Also, this assumes the lighting load is attached to the swtich. I would consider using a kpl where one of the buttons does the monitors and the other does the lights. But, if you want to do it this way then. . . If switch is turned on and switch is not on then turn plug on if switch is turned on and switch is not off then turn plug off if switch is turned off and switch is not off then turn plug off if switch is turned off and switch is off the turn plug on I think that should all work. Haven't tested it but I use a few similar programs in my house as is that do work. Please note, that this does not take into account the double tap for fast on/off. You would need to pause between pushes long enough that the double tap function is no longer active. Also, you will be challenged in dealing with brightness levels if you don't want it to just be on/off.

I think there might be confusion that many people have when they first start using this stuff. Some points that I think will help. 1) When a command is sent to an individual device to turn on/off or whatever, it and only it will change. It does not matter what the device might be linked to, none of those other devices will be affected. 2) When a command is sent to a scene, all of the devices in that scene will respond as per the scene attributes. 3) When you locally control a device (press the button/switch), it will locally do its thing and if it is a controller in a scene, all of the other devices in the scene will do as per the scene attributes. Please note, turning on a device status (push the button) is not the same thing as that same device turning on as a result of a command sent to it via a power line command. Another way to say this is that a device always behaves as a responder only unless it is actually physically acted on. When you actually physically control the device it will be a controller (should you have programmed it to control something.) In this way, a device can respond to multiple scenes/programs. If a device were not setup this way, then a switch could not be part of one scene and control another scene because every time you changed a scene that the switch was part of, it would trigger the scene it was a controller of. You can see why you might not want this. Conceivable, you could have a cascade of scenes where turning one scene on might end up turning on practically everyting.

There is a very good chance that you have the "paddle issue". Until 2007 Insteon switches were using a micro switch (when you push the paddle it clicks down on a microswitch) that were of inferior quality. Take off the switch plate cover and see what version the switches are. If the 2476d's are prior to v3.2 then you will have the problem if you don't already. The version number can only be found by looking at the switch, the version listed in ISY is for the firmware and that is different than the hardware. If the paddles were bought from smarthome, they are under warranty for 7 years becuase of this issue. They will only honor the warranty for the original purchases so you will need to discuss the issue with the person who originally bought them.

Tom, Of course what Michel said is correct. But I know your confusion. Here is a way to think about it that I think helps. A controller (or manager as listed in the membership tree) only does the controlling when it is switched locally (i.e. you actually push the botton on the kpl or hit the swtichlinc paddle). No matter how else you change the status of that device, it is only a responder (or managed by). So, in the fewest words possible, for a device to tell another device to do something, it must have been pushed directly. Keep in mind, that a load connected directly to that switch will do as the switch does regardless of how it got that way. If you want the scene to turn on, put the scene in your program and then the whole shabang does its thing. Don't just list a switch even if it is a controller.

It appears that your switchlinc in the gardenshed is only a responder to the scene, not a controller. It does turn the light on becuase it is (I assume) the load. But it won't turn on the other switches in the scene. Try removing it from the scene and then adding it back to the scene as a controller.

I too put scenes in my programs which are controller/responders and have found it to be superior to listing devices separately. Aside from the obvious added work of listing all the devices I find it executes more quickly and I don't encounter any surprises. In fact, if my program targets more than two devices and an appropriate scene doesn't already exist, I will create a scene specifically for the program (although it will be a responder only).

Yes, I just learned that the hard way. I spent a good half hour last night and ended up having to completely remove my kpl from ISY factory reset it and then add it back rebuilding all the scenes to fix it.

Michel, Unless my unit is doing something different than it is supposed to, my progress bars don't seem as straight forward as you describe. For example, if I add a switch to a scene, it does not start at zero and go to 100% in a single orderly fashion. It starts at 0 and goes to 100 many times depending on the size of the scene. Some of those times it flies across so fast that I can't hardly see it and other times it is quite slow. It might do a 0 to 100% 6 or 7 times when building a scene. And it isn't like it does this once per device in the scene. I really never know for any maneuver how many times it needs to go across. Also, sometimes, I have the "writing" labels on devices and the progress bar isn't there at all. It seems to be writing because it will progress from "1011" to "writing" on device after device, but no progress bar shows up at all. In this case it I know it is done when all of the green labels are gone. My main gripe really is that never can you watch the bar and have a real idea about how close it is to being done. I just think that a percentage bar should be there so that you can estimate when the job will be done, and this progress bar doesn't do that. It seems that if communication failures occur then it shouldn't keep going across, it should stop. After all, it isn't actually making progress. And if it has 10 jobs to do to build a scene, it should start at 0 and go 100 a single time as it does those 10 jobs. Perhaps a little flag comes up if it is having comm difficulty to let you know about that and pausing during that time.

Michel, If you are looking for other simple to implement ideas, here is one. Instead of the 1011 in the green box next to devices that need to be written to, why not put the word "pending". While they are writing, the most obvious word "writing" shows up so why not be just as simple when the write is pending? I have seen a number of posts on here where people were confused as to what the 1011 meant. One other thing. I don't really understand what the bar that gives a percent of job completion means. It keeps either slowly or rapidly jumping accross the screen only to start at 0 again or maybe not. Perhaps those percentages really mean something, but I don't know what. It might be just as well to put one of those spining clocks or something just to indicate that the system is writing rather than what seems to be meaningless percentages. Lou

Curious. I never had to select that option before, it defaulted to it. They must have changed the default sometime from when I first added my KPL's to now. Thanks for pointing out that rather obvious but yet missed solution.

I have a 6 button kpl which was acting up after making a small change. After trying to restore, factory reset then restore, and removing from scenese and replacing in scenes, I gave up. I removed it from all scenes then removed it from ISY completely. I factory reset it and readded it to ISY and redid all of the scenes. It is working again, however, in the tree of devices, all of the sub-buttons (A,B,C,D) show up as individual devices instead of in a sub-tree. Why is this happening? I also tried clearing the Java cache.

I did not believe that the wait statement actually caused a re-evaluation. Rather, I understood that a re-evaluation COULD occur during a wait state, at which point, a program would be either halted or restarted. This is exactly the sort of thing I was talking about when referring to program triggers and programs restarting prior to conclusion. For example, let's say a switchlinc is on and a program is running which includes the status of the switch. If the switchlinc is told to turn on again (either locally or otherwise), the program resets, even though nothing seemed to happen. Essentially, any traffic on the system referring to an insteon device will restart a program containing a "status" line for that device, regardless of whether that traffic caused a change in the status or not. I was playing with writing programs where the "if" and "then" section were written into two separate programs. The "if" program runs the "then" program with the "then" program's first line to disable the "if" program and the last line turning it back on. It seemed to work for me, but another poster was not having as much luck.

Personally, I think one of the greatest issues with understanding how this system works is undertanding what triggers programs. ISY will reset a program in the midst of running if any events occur that are "triggers" Bascially, everything in the "if" section runs the risk of restarting your program midstream.

Nice work. I agree that ISY has a lot of things you don't quite expect and you touched on a number of them. One thing I think they should do is drop the word "on" and replace it with 100%, since that is what they mean. A silly thing that bugs me is the lack of the word "delete". The rest of the world uses "delete" to delete something, not "remove". I always have to stare at if for a while before I remember to look for remove, not delete. The ISY totally needs a logically put together programmers manual. Even for people like me who have spent a fair amount of time writing programs and whatnot, a few weeks after you figure something out, you forget when you don't use it. I have taken to writing a list of my anecdotes for future reference, but still. And trying to piece things together from the threads is, well, at best very time consuming. I like what you have started. Thanks.

OK, I think I got this figured out. Never mind.