LeeG

Network Module is not needed to issue REST commands. They are unrelated.

Access Points are not configured or linked to anything. They are functional as soon as they are plugged in. They are not added to the ISY

A device/node can be a Controller in only one Scene. This is the way Insteon is designed. Not the actual limitation it may sound like when first understood. An individual KeypadLinc button may be controlled by several other devices/nodes so it can appear as a Responder in a number of Scenes. However, when the KeypadLinc button is pressed On/Off it can only control a single list of devices. For the Scene with the list of these devices, the KeypadLinc is a Controller. It would not be possible for that KeypadLinc button to added as a Controller to another Scene as which Scene would be controlled when the button is pressed. Being a Controller in only one Scene generally makes sense when it is looked at from that perspective. It is not the case that a device/node that can Control is always defined as a Controller. If the function of a Scene is contain a list of devices/nodes that are managed from a Program for example, likely all the devices/nodes will be defined as Responders even when they also have Controller capability. For example, at 11:00 PM all the basement lights should be turned Off. A Scene is defined with all the basement lights as Responders. The Program turns the Scene Off at 11:00 PM. In this case an individual device/node is not going to turn the Scene On/Off, only the Program, so none of the devices/nodes are defined as Controllers even though it is likely they all have Controller capability.

The Status of light X has to change for the Program to be triggered. The Status could change from On to Off, from Off to On, from Off to 50% On if a dimmer, from 50% On to 80% On, and so on. Light X could change Status as a result of pressing the light X paddle (assuming it has a paddle). It could change Status by being controlled by another device. Whenever the ISY detects a change in Status the Program is triggered. When the Program is triggered the If clause executes, checking the Status against how the If is coded. The Then clause runs only when the Status changes to On. Any other change in Status, such as to Off, to 50% On Level, causes the Else clause to run. An If Control 'light X' is switched On triggers the Program only when light X is turned On by its paddle/button. This is the only time light X sends an On command. If light X is turned On by another device the Program is not triggered because the device was not turned On by its paddle/button press. Once triggered the Then clause runs as that is the only If result possible in this simple example. The Program only triggers with an On command and the If is checking for On. If clauses can be complex, with combinations of If Control Anded/Ored with combinations of If Status. Also tests of Variable values can be done and testing ELK conditions.

The UDI Wiki has some good information on Status versus Control. To summarize, If Control is looking at specific commands the device is sending to the ISY/PLM. The Program is triggered (runs) whenever the command being checked for is received by the ISY/PLM. If Status is looking at the state of the device the ISY tracks for each node. The Program is triggered (runs) whenever the device/node Status/state changes. In both cases when the If checks evaluate to True the Then clause is executed. When the If checks evaluate to False the Else clause executes.

Might try 127.0.0.1. The request from a browser is going from one IP address (PC) to a different IP address (ISY). When the ISY issues the network request it is trying to talk to itself. I am not a network expert by any means but it seems like 127.0.0.1 can be used when trying to communicate with one’s own IP address

wswartz Try a right click on the device node, select Diagnostics | Query Insteon Engine. The trace shows a similar situation this morning. A 2E command in the Standard format is being used which does turn the device On. I continue to think the ISY should have issued an Extended 2E command to set a Local On Level or Local Ramp Rate for 19 ED 3F. What ISY Firmware level is being used? Michel Is there any situation where the ISY would issue a Standard format 2E command? I did not think the ISY surfaced that Insteon command function anywhere. It looks like an Extended format 2E command should have been issued.

"Then I set the ISY to linking mode." Put the wireless Open/Close sensor into linking mode with its Set button. Then use New INSTEON Device, entering Insteon Address, Name of choice, and Device Type set to default Auto Discover. Would still be helpful to know the Smarthome Item number for the kit.

The SwitchLinc should be a Controller in Scene B. The paddle physically controls light B because it is attached to the Red Load wire. However, the SwitchLinc paddle does not control KPL button B because the SwitchLinc is defined as a Responder rather than a Controller. The ISY assumes a device/button added to a Scene as a Controller is also a Responder (assuming the device has Responder capability). The KeypadLinc button and RemoteLinc2 button are correctly defined as Controllers of Scene B. EDIT: as an FYI Scene A should have its KPL button as a Controller

Sorry, what is the Smarthome Item number of the Open/Close sensor kit? I am not sure what actual device type is having a linking problem.

Thanks for posting the results. It was a vague memory which I am happy was wrong.

If the KPL LED follows the SwitchLinc paddle On/Off press the On condition should take care of itself. It is the Timer function turning the SwitchLinc load Off that is the challenge. Check what the Admin Console shows when the SwitchLinc Timer times out and turns its load off. If it does not turn the KPL LED Off it is likely not telling the ISY about it either as the PLM is just another Responder as the KPL button LED is.

iostream212 The only thermostat that sleeps is the battery powered 2441THZ which can be run on 24v AC power. The other thermostats run on 24v AC provided by the HVAC so they do not go to sleep.

Does the KPL button LED correctly follow the SwitchLinc paddle operation? That is, does the KPL button LED turn On when the On paddle is pressed and the KPL LED turn Off when the Off paddle is pressed. I have a vague recollection of the Timer aspect of the SwitchLinc Timer only turning Off the SwitchLinc load and not its Responders. Can't confirm that since the SwitchLinc Timer no longer has a sales page. I could well be remembering this wrong. The SwitchLinc Timer paddle On/Off test is expected to turn its linked Responders On/Off. If that does not work there is either a link record issue or an Insteon Mesh Network problem. If the paddle On/Off does control the KPL button LED but the Timer function does not I believe this is normal (from an admittedly old memory).

Controlling a Scene with a Program (or Admin Console) uses an Insteon command different from that used by Scene Test. Controlling a Scene from a Program (or Admin Console) uses a command that does not generate ACKs so the ISY/PLM does not know if any specific device actually received the Scene On/Off command. The Scene Test uses a PLM Scene command that does require an ACK from each device. The PLM must have a link record for every device in the Scene for the ACK to be generated. Because a normal Scene On/Off is not ACKed the missing link records have no effect (if they are missing). The failures that IndyMike discussed in his post result from Programs being triggered by Scene driven device state changes which then issue another Scene command or Insteon Direct command. Insteon will terminate a running Scene if another Scene or Insteon command is initiated. Does not bother Scene On/Off because ACKs are not part of a normal Scene On/Off. The lack of ACKs in a Scene Test because the Scene Test Scene has been cancelled by Program activity shows up as Scene Test device failures for the devices that had not yet received the Insteon message that generates the ACK.

What is the Type of timer switch? Details on the Scene, what is/are Controllers, what is/are Responders?

Thanks for posting back. If you have that problem again watch for a Progress Bar when the slider is moved. There have been cased where Java has not told the app the slider has been moved. If a Progress Bar is not displayed, move the slider to some other location and then back (after next Progress Bar completes).

What does Help | About show for Firmware and UI levels. There was a problem with an earlier image marking devices as failed when they actually passed the test. That problem does not exist at 3.3.8 (RC5) Just looked back over trace looking for false failed condition. There are link record problems as only two devices actually ACKed the Scene Test. That is why so many are marked failed. With so many devices failing I suspect the PLM has lost its link database. Do a Restore Modem (PLM)

Depends on whether a 2412 (not RF) or 2413 (Dual Band) PLM. What is the actual Smarthome Item number of this kit?

The NDA for confidential information is in effect. UDI cannot release anything more than what Smarthome chooses to make public. There is a ton of confidential information about lots of existing devices that we mortals would love to know that UDI cannot release.

Insteon does not chain Scenes. Turning Scene2 On/Off from KPL2 has no affect on KPL1 button D as that button is not part of Scene2. If you make KPL1 button D a Responder to Scene2 it will turn On and Off with KPL2 button C. I am not sure exactly what KPL button On/Off activity is desired. Since Scene2 is controlling SW1 it seems natural that KPL1 button D would be a Responder to Scene2 as well. Just not sure that is the result you are looking for.

Look at the ISY Log and see what was logged at that time. The 0x2E command issued in the Standard format is turn On device at specified Ramp Rate. The ISY does not expose this command which makes its use odd. Perhaps this was a LED Brightness change that built a Standard command rather than an Extended command.

I suggest moving to 3.3.8 (RC5) and see if the problem still exists.

Post the Program (right click Program name and select Copy to Clipboard) as it is very likely to happen again until Program is corrected. Sounds like the Program has an If Status check for a device that is being changed by the Program. The change in Status will cause the Program to be triggered again and perhaps run the Else clause which changes the Status again. The Program cycles between the Then and Else clauses. Not an uncommon programming error for someone starting out.

Initiate Start Linking, then press the ApplianceLinc Set button for 3-5 seconds. That will add the ApplianceLinc to the ISY by its Insteon Address. If that does not work manually Set button link the ApplianceLinc as a Responder to a SwitchLinc (or similar device) as a Controller. Then do a Show Device Links Table for the SwitchLinc. The last active link record will normally contain the ApplianceLinc address. This must be followed by a Restore Device for the SwitchLinc to get rid of the Set button link. I am not familiar with the 2002SHL3 designation. Are you certain this is an Insteon device? Could it be an X10 device.