apostolakisl

As Lee said, don't do anything prior to a "replace with". Don't change programs, don't change scenes, don't change anything. .. except, you need to remove the device from a folder if it is in one and just have it under the main "my lighting" area. After a "replace with" command has completed, it should automatically close the admin console. If it didn't you would need to manually close it and re-open it. If it looks like it has "hung", you should close and re-open your admin console. After a "replace with" has completed, I do check all the programs to make sure they went through correctly. Scenes on the other hand shouldn't need to be checked.

I leave several of mine unplugged. I also repurpose some of them. I have a "holiday" program which sets a variable to 1 during holiday season. The programs that turn those lamplincs on/off won't run unless that variable is 1. It starts at Thanksgiving. The first program below defines Thansksgiving. It requires you install the entire block of programs I wrote for keeping track of days/months/years and so forth. It is in the wiki. Thanksgiving If ( $iDay.of.Week is 3 Or $iDay.of.Week is 4 Or $iDay.of.Week is 5 ) And $iWeek.of.Month is 4 And $iMonth is 11 Then $iHoliday = 1 Else - No Actions - (To add one, press 'Action') This turns the variable on (to 1) If Program 'Thanksgiving' is True Then $iChristmas_Lights = 1 $iChristmas_Lights Init To 1 Else - No Actions - (To add one, press 'Action') This turns the holidays off (variable back to 0) If $iDay.of.Year is 7 Then $iChristmas_Lights = 0 $iChristmas_Lights Init To 0 Else - No Actions - (To add one, press 'Action')

That is not true! Legionella will not grow in a tank that is too hot no matter how long it sits, the same is true for too cold. You should keep the tank at a minimum of 130 to prevent legionella growth but 140 is recommended. I do not know what the "too cool" temp is for legionella but turning the tank off would probably get you there in most climates, especially if you heated it back up before use to a "kill" temp. But you would not want to leave your tank say at 120, this would be prime growth opportunity. Flushing of the tank (either by regular use or purposeful flushing) is neither possible nor recommended for controlling Legionella. The bacteria grow on the walls and on deposits (calcium) in the tank. You could not flush your tank fast enough to "wash it out". If it is growing in there, you would only be able to remove it by getting the tank sufficiently hot for a sufficient amount of time to kill it. Legionella would enter your system from the water supply. It is rare, but it is possible and many people have died. You don't save hardly any money turning your tank down into the danger range, and your risk a very expensive or even deadly infection.

I have a bunch of those programs. For example: If Status 'Alexis Room / Alexis Bed-Closet L' is not Off Then Wait 4 minutes Set 'Alexis Room / Alexis Bed-Closet L' 45 (Beep Duration) Wait 1 minute Set 'Alexis Room / Alexis Bed-Closet L' Off Else - No Actions - (To add one, press 'Action') I upgdraded to .16 yesterday, and all of these programs have been running just as usual.

I agree. I wouldn't be at all surprised if it weren't the issue with ACK's. It looks very much like the programs I had that would run incorrectly (too often). . . at least prior to 3.1.16 installation yesterday.

The cleanest way to fix this is to use a resistor soldered in between the hot and neutral in the wire to the LED lights. Or to use an Insteon product that doesn't have the sense function. The resistance needed is quite high. You could buy a few and test them out. It could be that 20,000 ohms or even higher is all you need. At full voltage (120v) that is about 3/4 watt. What size resistor will depend on the actual LED light set you have. The resistor will "drain down" the current from the sense function so that it doesn't go through the led's (or at least less of it). This current that is provided as a sensor is present regardless of whether you have the resistor or not and is just a few milliamps so standby power consumption is not changed. When the light is on, however, the resistor will still "drain down" current which results in additional power consumption above and beyond what would have been there without it. But, as I mentioned, your resistor will probably be so high that it is less than 1 watt.

It would appear that 3.1.16 has fixed the problem. I have tried to get it to screw up and it has not even after many many attempts. Only time will tell for sure, but certainly I would have seen dozens of screw ups as it was before in the number of tests I did.

Keep in mind that Legionella grows in water tanks that are not hot enough. It might be better to shut it off completely than let it sit at an "incubating" temp. I would take care to research this before implementing.

I'm confused here. I understood him to say that the lamplinc is the load device and that the keypad linc is the scene controller (non load button). My understanding of scenes is that the controller sends out a "scene on" command. Each responder (the lamp linc) has it's own internal instructions on what to do with that "on" command. Which would mean that the lamplinc has not accepted the proper ramp rate. by the way, what is an SWMBO?

I think LeeG was getting at this, but you probably set the wrong ramp rate. Make sure you are bringing up the scene by tapping the scene on the left hand side of the screen in the "tree". It will list all the ramp rates for each device in the scene at the bottom of the screen. Make sure the load device has the ramp rate you want. Typically I check the "apply to all" box as rarely do I want different devices in a scene to respond differently.

First try at trying to screw up the "ACK" situation. I ran the "if off and switched off" program from one of my switches about 25 times without a single error. I re-enabled all of the programs that work that way so we shall see. At this point, it is really the "wife test" as she will certainly inform me when/if it screws up.

Installed like clockwork. I see no problems. I did not experience anything out of the usual on the first query time nor do I have any problems with the program summary page display. Look forward to seeing if it those ACK issues stop giving me headaches.

Yes, I wrote those programs. http://www.universal-devices.com/mwiki/ ... _Variables And yes, I use them for situations just like this where things recur on a schedule. I have it set up so you can have things recur on virtually any date type situation from every so many days, weeks, months, years, and so on. So, if you have a recurring situation, it might be worth the effort. But a one-off situation wouldn't make sense. You can also use ISY's date function to activate/de-activate the program on certain dates just like oberkc did above, but if you don't plan on ever using it again after the end date, you probably would want to just delete it. I do use that date function above to set all the kids school vacation days at the beginning of the year. But I have to say, it is kind of a PITA putting all those lines of code in for each vacation and I may just foget about next year and simply manually enable/disable it.

If this is just a one-off situation, I highly suggest you simply write the program, leave it disabled, enable on the desired date, then delete when you are done with it. Or you can disable it until you decide you want it again.

I assume you made a backup of your ISY prior to starting any of this. You could always restore that backup to ISY and put the old PLM back in. You would still need to restore any of your devices that did get successfully updated to the new PLM.

I have been having problems with this program type for several months now, perhaps 6. So, if a change occurred around 2.8.16, that could have something to do with it.

The lack of ACK's back to the device has got to be something more than simple lack of comm. Reasons to say this: 1) The comm going the other direction never has an issue. 2) ISY initiated events always get through (ie programs run on ISY and execute events at the switch without fail.) 3) Tests of my comm (Scene tests) are now 100% successful. I have to wonder if this ACK is actually being sent in the first place, or if it is being formated improperly so the switch doesn't recognize it. I will also note that the problem is now consistent between 2 PLM's. I will also note that I didn't always have this problem. The biggest change to my system since this problem began is ISY firmware.

I got the filter and installed it on the breaker. I ran scene tests by the boat load. 100% success. The program still misbehaves. In fact the program design: if status off and switched off then turn on 25% misbehaves in general. When one of the lights associated with one of these programs is on and I turn it off, it will still run and go back on to 25%. It does it randomly about 50% of the time. I am thinking that this entire program structure is going to need to be abandoned.

Hopefully the filter I ordered last weekend will arrive today. I ran a number of scene tests with that circuit off and they went perfect, then they failed with it on. It was reproducable about 5 times each way during a 15 minute span, so I feel like filtering the circuit should help. Also, after I moved the PLM off of that branch panel things worked better as well.

OK, but I don't get it. How can the message go one direction so successfully and go the other direction so poorly. But still, even if it thought there were three button presses, none of them should have been a button that ran that program.

I am not at all very good with these Insteon communication logs, but. It would appear to me that this particular switch is needing 2 hops to get the messages back and forth. I don't mean to be a whiner, but I would think that we should accept that Insteon may need "hops" to get the message around, it was after all built around the premise that the perfect comm was no longer a necessity (as opposed to x10). If we are going to forgo the "hops" then we are giving up a big feature of Insteon. Having said that, I appreciate that you guys think you have a solution to this problem and are working on a fix. Thanks.

I did it again. Wed 12/21/2011 8:01:54 PM : [iNST-SRX ] 02 50 05.15.36 19.75.34 41 13 04 LTOFFRR(04) Wed 12/21/2011 8:01:54 PM : [standard-Cleanup][05.15.36-->ISY/PLM Group=4] Ma x Hops=1, Hops Le ft=0 Wed 12/21/2011 8:01:54 PM : [ 5 15 36 1] DOF 4 Wed 12/21/2011 8:01:54 PM : [iNST-SRX ] 02 50 05.15.36 19.75.34 42 13 04 LTOFFRR(04) Wed 12/21/2011 8:01:54 PM : [standard-Cleanup][05.15.36-->ISY/PLM Group=4] Ma x Hops=2, Hops Le ft=0 Wed 12/21/2011 8:01:55 PM : [iNST-ACK ] 02 62 12.29.64 0F 11 3F 06 LTONRR (3F) Wed 12/21/2011 8:01:55 PM : [iNST-SRX ] 02 50 12.29.64 19.75.34 27 11 3F LTONRR (3F) Wed 12/21/2011 8:01:55 PM : [standard-Direct Ack][12.29.64-->ISY/PLM Group=0] Max Hops=3, H ops Left=1 Wed 12/21/2011 8:01:55 PM : [ 12 29 64 1] ST 63 Wed 12/21/2011 8:01:55 PM : [iNST-ACK ] 02 62 05.15.36 0F 11 3F 06 LTONRR (3F) Wed 12/21/2011 8:01:55 PM : [iNST-SRX ] 02 50 05.15.36 19.75.34 27 11 3F LTONRR (3F) Wed 12/21/2011 8:01:55 PM : [standard-Direct Ack][05.15.36-->ISY/PLM Group=0] Max Hops=3, H ops Left=1 Wed 12/21/2011 8:01:55 PM : [ 5 15 36 1] ST 63 Above is impropper Below is propper Wed 12/21/2011 8:02:31 PM : [iNST-SRX ] 02 50 05.15.36 00.00.04 C7 13 00 LTOFFRR(00) Wed 12/21/2011 8:02:31 PM : [standard-Group][05.15.36-->Group=4] Max Hops=3, H ops Left=1 Wed 12/21/2011 8:02:31 PM : [ 5 15 36 4] DOF 0 Wed 12/21/2011 8:02:31 PM : [ 5 15 36 4] ST 0 Wed 12/21/2011 8:02:31 PM : [iNST-SRX ] 02 50 05.15.36 19.75.34 41 13 04 LTOFFRR(04) Wed 12/21/2011 8:02:31 PM : [standard-Cleanup][05.15.36-->ISY/PLM Group=4] M ax Hops=1, Hops Left=0

Device communication events was selected.

You are looking at a log that contains both a correct and incorrect execution. Above is the log of me doing it twice. The first time I pushed button b, the program did not run (which is correct), the second time the programs did run (which is wrong).

I went ahead and disabled all programs on the ISY to elliminate as many variables as possible and to clean up the log from extranous activity. I only lef these two programs active. If Status 'Master Bedroom / Master-Cans over Bed L' is Off And ( Control 'Master Bedroom / Master-Cans over Bed L' is switched Off Or Control 'Master Bedroom / Master-Keypad' is switched Off ) Then $itest += 1 Else - No Actions - (To add one, press 'Action') If Status 'Master Bedroom / Master-Cans over Bed L' is Off And ( Control 'Master Bedroom / Master-Cans over Bed L' is switched Off Or Control 'Master Bedroom / Master-Keypad' is switched Off ) Then Set 'Master Bedroom / Master-Cans over Bed L' 25% Set 'Master Bedroom / Master-Keypad' 25% Else - No Actions - (To add one, press 'Action') I then turned button B off. The first time, it just shut off and nothing else happened. I turned it back on and turned it off again. This time both programs falsely ran. 5.15.36 is the KPL, 12.29.64 is the 2476D switch that carries the load. 0Wed 12/21/2011 5:40:30 PM : [ 5 15 36 4] DON 0 1Wed 12/21/2011 5:40:30 PM : [ 5 15 36 4] ST 255 2Wed 12/21/2011 5:40:31 PM : [ 5 15 36 1] DON 4 3Wed 12/21/2011 5:40:31 PM : [ 5 15 36 1] ST 127 4Wed 12/21/2011 5:40:31 PM : [ 12 29 64 1] ST 132 5Wed 12/21/2011 5:40:33 PM : [ 5 15 36 4] DOF 0 6Wed 12/21/2011 5:40:33 PM : [ 5 15 36 4] ST 0 7Wed 12/21/2011 5:40:33 PM : [ 5 15 36 1] DOF 4 8Wed 12/21/2011 5:40:33 PM : [ 5 15 36 1] ST 0 9Wed 12/21/2011 5:40:33 PM : [ 12 29 64 1] ST 0 10Wed 12/21/2011 5:40:38 PM : [ 5 15 36 4] DON 0 11Wed 12/21/2011 5:40:38 PM : [ 5 15 36 4] ST 255 12Wed 12/21/2011 5:40:40 PM : [ 5 15 36 4] DOF 0 13Wed 12/21/2011 5:40:40 PM : [ 5 15 36 4] ST 0 14Wed 12/21/2011 5:40:40 PM : [ 5 15 36 1] DOF 4 15Wed 12/21/2011 5:40:41 PM : [ 12 29 64 1] ST 63 16Wed 12/21/2011 5:40:42 PM : [ 5 15 36 1] ST 63