LeeG

Besides sending/receiving RF messages between themselves to couple the phases they may be receiving RF from the PLM. This could result in an Insteon message reaching a location over RF that powerline communication would not support. I would move both Access Points to the PLM plug point. Tap the PLM Set button 4 times and note the reaction of each Access Point LED. Then return them to their original location. If both are in RF range of the test signal one will have an LED that reacts differently because it is on the opposite phase (assuming the Access Points are on opposite phases).

There is no response from Insteon address 17.CE.EB . Check the address for things like 8 instead of B. Could be a defective device, could be a total inability of the PLM to communicate with the ICON location. My Access Points blink Green when receiving the RF test signal and on the opposite phase.

Being computer safe does not mean a pure 60 cycle sine wave. What a power supply needs and what Insteon needs to send Insteon messages over the powerline are two very different things. Insteon sends it messages starting "before" reaching the zero crossing so timing and shape of the 60 cycle sine wave are very important. Most generators do not provide a pure 60 cycle sine wave. If they do they have always advertised that specific point. An alternator does not insure a pure 60 cycle sine wave. If the generator provided that the lights would not flicker and Insteon messages would work. All the other hype about being computer friendly is fine as far as powering electronics is concerned but does not speak to the need of Insteon to sends messages over the powerline. I suggest running Tools | Diagnostics | Event Viewer at LEVEL 3 to see just what the PLM is presenting to the ISY. It may be necessary to Disable certain ISY Programs if they are being triggered by false information presented by the PLM due to the malformed or mal-timed AC sine wave.

The "Local" On Level can be adjusted with an ISY Program based on time. If From 7 PM to 5 AM (next day) Then Adjust Scene where both the 'In Scene' and 'Set' parameters are the LampLinc node name, On Level 22% Else Adjust Scene where both the 'In Scene' and 'Set' parameters are the LampLinc node name, On Level 100% LampLinc node must be a Controller of a Scene even if the Scene itself it not used for anything more than enabling the use of the Adjust Scene statement. With the Local On Level being set any manual operation of the Lamp between 7PM and 5AM will turn the lamp On to 22%

For the ISY to indicate I/O Linc Sensor Off when the door is closed the magnetic switch has to be changed from a Normally Closed (NC) that now comes with the garage kit to a Normally Open (NO). The KeypadLinc button LED can be managed with an ISY Program to have the KPL button LED Off when the Sensor is On (door closed) but the Sensor state requires a different magnetic switch. See this link for a Program that will manage the KeypadLinc button LED with the current NC magnetic switch. viewtopic.php?f=26&t=12068&hilit=keypadlinc+button The I/O Linc Relay should be in Momentary B mode for the I/O Linc Relay to respond to both an On and Off command from the KeypadLinc.

Connected to the ISY? No. Smarthome has a return policy that will take it back.

The Flood Stop itself is not Insteon. The Flood Stop has NC contacts that can control an I/O Linc Sensor for example. The I/O Linc can be added to the ISY with the Sensor state triggering a Program or Scene just as a garage door would.

Define an ISY Scene ‘keypadlinc button C’ (arbitrary Scene name) with KeypadLinc button C as Responder. If Control ‘iolinc – Sensor’ is switched On Or Control ‘iolinc – Sensor' is not switched Off Then Set Scene ‘keypadlinc button C’ Off Else Set Scene ‘keypadlinc button C’ On The above ISY Program turns KeypadLinc button C LED Off when the I/O Linc Sensor turns On and turns KeypadLinc button C LED On when the I/O Linc Sensor turns Off

It works on my 2441TH with v.0A firmware.

Hardware revision 1.0

The thermostat firmware is displayed in the image above, v.0B The thermostat will not send a temp change message to the ISY until it is linked as it needs the PLM Insteon address to know where to send the temp change message.

This is the last temp message as the ambient cooled down to 81 degrees. Fri 08/02/2013 02:00:42 PM : [iNST-SRX ] 02 50 1F.0F.B4 22.80.0B 01 6E A2 (A2) Fri 08/02/2013 02:00:42 PM : [std-Direct ] 1F.0F.B4-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Fri 08/02/2013 02:00:42 PM : [ 1F F B4 1] ST 162

Thanks for the trace. It shows that particular thermostat is sleeping (or out of RF range). The 2441ZTH should send temp changes to the ISY. I increased the ambient temp at the 2441ZTH and received this message in response Fri 08/02/2013 01:56:00 PM : [iNST-SRX ] 02 50 1F.0F.B4 22.80.0B 01 6E A4 (A4) Fri 08/02/2013 01:56:00 PM : [std-Direct ] 1F.0F.B4-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Fri 08/02/2013 01:56:00 PM : [ 1F F B4 1] ST 164 The Status 164 is actually temp 82. There may be a delay in sending the change message when in battery mode and sleeping but the change message should occur.

I understand the unwillingness to issue a Restore Device. These may not be any more palatable. A Show Device Links Table or a Diagnostics | Query Insteon Engine do not change anything in the thermostat but do issue commands which would be a positive indicator the thermostat is not sleeping. If neither is acceptable we will just have to wait to see how long it takes the batteries to run down. This is what a Query Insteon Engine trace looks like when the thermostat is sleeping. Note 3 attempts to send commands none of which got an 02 50 response because the thermostat did not receive the query engine commands. Fri 08/02/2013 11:51:48 AM : [All ] Writing 1 bytes to devices Fri 08/02/2013 11:51:48 AM : [iNST-TX-I1 ] 02 62 1F 0F B4 0F 0D 00 Fri 08/02/2013 11:51:48 AM : [iNST-ACK ] 02 62 1F.0F.B4 0F 0D 00 06 (00) Fri 08/02/2013 11:51:57 AM : [iNST-TX-I1 ] 02 62 1F 0F B4 0F 0D 00 Fri 08/02/2013 11:51:57 AM : [iNST-ACK ] 02 62 1F.0F.B4 0F 0D 00 06 (00) Fri 08/02/2013 11:52:06 AM : [iNST-TX-I1 ] 02 62 1F 0F B4 0F 0D 00 Fri 08/02/2013 11:52:06 AM : [iNST-ACK ] 02 62 1F.0F.B4 0F 0D 00 06 (00) Fri 08/02/2013 11:52:10 AM : [ 1F F B4 1] ERR 1

The basic fact is if the 2441ZTH was going to sleep under battery power it would not be possible to add it to the ISY without the use of the Set button. I'm concerned the 2441ZTH is not sleeping now (for whatever reason) which would explain how it could be added to the ISY. Keep an eye on the battery icon. The batteries may well run down sooner than expected. The question about taking the 2441ZTH out of manual linking mode, when the Set button was used the 2441ZTH would add to the ISY very quickly because Extended commands are used to write the link records. When the 2441ZTH was being added to the ISY using the Set button, there would have been 3+ minutes remaining in linking mode after adding to the ISY. Was that linking mode allow to timeout or was the manual linking mode terminated by tapping the Set button. The ISY issued the same commands, wrote the same link records since it was added as a 2441ZTH. The variable is the interaction with the 2441ZTH itself. Using the Set button to manually enter linking mode should have worked. With the temp not being reported when done that way the question is what physical interaction happened with the thermostat and why did that leave the thermostat in a state where it would not report temp.

I believe you without seeing the video. Something is keeping the 2441ZTH awake during the add process. The question now is does the 2441ZTH ever go to sleep under battery power. If you do a Restore Device to the 2441ZTH does it work without touching the thermostat? When the 2441ZTH was added using the Set button was the 2441ZTH allowed to timeout after 4 minutes or was the 2441ZTH taken out of linking mode by pressing the Set button after adding to the ISY to bring it out of linking mode?

Thanks for the information. The ISY queries the Insteon Engine and device type during add so having it added as a 2441ZTH is expected regardless of what was entered in the Device Type field. A video would not answer the question of how the 2441ZTH is responding to commands when it should be asleep. How long had it been since any physical interaction with the 2441ZTH when the device was added to the ISY?

For a battery powered device putting the device into linking mode with Set button is required. Otherwise, the device is asleep and cannot hear commands. How you got a 2441ZTH operating under battery power to add to the ISY and be able to have the necessary link records written is a mystery. When the primary node is selected what is listed for the device type on the right side line two?

The FanLinc is supported at 4.0.5. The Wiki is listing devices that have some special processing. There are many Insteon devices that are not listed in the Wiki because they do not require special processing.

The If section is evaluated only when the Program has been triggered. The Program will trigger once only at 3 AM (perhaps not a good time since the ISY QueryAll Program also runs at 3 AM). The If will be True as it is 3AM and the Then clause will run. Because the Program is not triggered again until the next 3AM there is no evaluation of the If section to False. Again, the If section is evaluated only when the Program is triggered. A specific time triggers the Program only once at the specified time and the If will be True. A From/To Time in the If section triggers the Program twice. Once at the From time when the If is True (assuming no other conditions in the If) and once at the To time when the If is False as the time is no longer within the From/To time range.

The Backlight level adjusts ALL the KPL buttons backlight level. It is not used to turn an individual KPL button LED On/Off. Secondary KPL buttons cannot be controlled with Direct commands. Direct commands have no means of indicating which KPL button to control. Define an ISY Scene with the KPL C buttons as Responders. The Program turns the Scene On/Off to turn KPL C buttons On/Off A simpler approach is to use an ISY Scene without a Program. Define the ISY Scene with the SwitchLinc and the KPL C buttons as Controllers. The SwitchLinc and the KPL C buttons will turn the load On/Off and the KPL C buttons will stay in sync with the SwitchLinc. EDIT: if it can be done with Set button links (which must not be done while using an ISY) it can be done with ISY Scene(s).

The next command issued by a Mini-Remote button cannot be changed with a Program call. First the device has no command to accomplish that. Second battery devices go to sleep (turn Off RF circuitry) so the ISY cannot communicate with it (which is why it has no command to change Status).

I don't see a problem with the actions to ISY 1. There are all kinds of problems when moving to ISY2. First the Restore Modem (PLM) will change all the device link records to point to the PLM connected to ISY2. That damages the ISY1 environment. Deleting the ISY1 devices from the ISY2 configuration will have PLM errors because the link records do not exist in PLM2. No idea what will actually happen. Don’t know of anyone who has tried to split one configuration into two ISYs. At some point a Restore Modem (PLM) will be needed on ISY2 to build PLM2 and change the device link databases for ISY2 devices to point to PLM2. Might be able to accomplish the same thing with a Restore Device to the ISY2 devices. Again, no history/experience for what you want to do. Folks who have tried to isolate a PLM from the powerline have not always been successful with a single FilterLinc. Two may be needed. Putting the PLM into a solid metal box should block RF but power has to enter the box which may allow some RF to leak. Bottom line is I have many doubts about the procedure. I guess the worst is both ISY configurations are not functional in the end requiring the ISY backup to be restored to ISY1 and the PLM and devices restored.

I suspect a loop issue would not be within a single program. A program changing the conditions that program is checking is pretty obvious. More along the lines program A triggers/runs program B that triggers/runs program C that changes something that causes program A to trigger/run again in a loop through B and C that ends when some other condition changes, temp, time, some combination of conditions, etc. Have you flow charted the Program structure, what program calls what program under what condition. With that number of programs it does not seem possible to have all the interrelationships memorized.

"So if from a program I set a scene "on' I will get the "PLM/scene" values and not the red controller values? is this correct?" Exactly right. You've got it. "What do I get when I set the scene off? does nothing? or sets all the "responders" off." All the Responders turn Off. With an On command the On Level for each Responder is unique. Some Responders can be turned On Full, some set at a lower On Level, some even turned Off with a 0% On Level (as we did with the other KPL buttons). There is no variation with an Off command. All Responders turn Off. The Adjust Scene program statement can be used to alter individual Responder On Level and Ramp Rate values. It can also be used to alter the Local On Level and Ramp Rate. The Adjust Scene specifies the Controller, the Responder, and the new On Level or Ramp Rate.