apostolakisl

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.

One more note here. I can turn the KPL on/off from the Java console by turning the scene on/off. The button light turns on/off and the ISY console shows it turn on/off. But, the program doesn't run. The only thing that trip it is to go up and hit the button. I don't understand!!!!!

Lee, thanks for the response and I think I understand what you are saying but let me add the following observation. From the ISY Java console, I can turn the scene "music" on. When I do this, the KPL button listed in the program turns on. Still, though, the program doesn't execute. How could ISY possible not be aware of the change in status when it was intiated from ISY? I also tried adding another 2476d switch to the scene. The KPL turns on and off as expected when you hit the 2476d switch, but still, the program doesn't execute. As I mentioned before, manually pushing the button works fine. I just don't quite understand why ISY doesn't observe the status of the KPL button from any initiator except physically pushing the button.

I guess what it come down to is, should programs trigger from a status change of a KPL button when the change is not physically initiated by pushing the kpl? It would seem that the answer is no by my experience. Either that or I have something screwy going on.

I am trying to get elk to initiate an ISY program. The program is currently triggered by pushing a kpl button (not the load). The kpl button is in a scene as a responder and controller. The program triggers a bunch of network commands to my global cache. Elk is set to turn the scene off. The button backlight does turn off, but the program that is controlled by that button doesn't run. I tried setting the program to run as both control and status of the button. The program runs fine when I push the kpl manually. What am I missing here?

Devices should report and show the current state on ISY's main console regardless of how they got that way. You should not have to close your window and reopen it to have the state be shown accurately either. I can sit at my console and watch as my wife and kids move around the house turning lights on and off. I had a KPL that was not reporting state properly and found that a factory reset of the kpl follwed by a "restore device" fixed the issue. If nothing on your system is reporting state, I would think that perhaps you are having a plm issue. If the ISY is not getting the word when a device has its state changed, then programs triggered by those status' won't work either. Check to see if programs are functioning that are initiated that way. If reopening the Java console gets the state to show correctly, then you must be having a Java communication problem with ISY knowing what is going on, but it just isn't showing up on your screen. Try rebooting your computer or reinstalling Java.

Any idea on how to get volume keys to behave like volume keys? In other words if you want to get a held key to keep sending the command to the itach until you let go?

I have discovered some finer points to this. Some remotes require you to change some of those settings which earlier we glossed over. In programming my dish vip 622 I have discovered that I needed to change the "gaps" setting to 3. It appears to truncate the code to essentially nothing. If you hit the "trim" button and it pretty much cuts everything out, try increasing the gaps. If I figure out what the other settings do I will let you know. If anyone else can explain what all of these settings do, please feel free to write a nice little description here. Thanks!

I think that the way this works is that Elk addresses a device internally using the x10 type terminology which outputs an Intseon address via IP (not powerline), which the ISY accepts and transmits on the powerline. In short, I believe that the x10 type address is not going to affect anything outside of Elk, so I think that should work.