LeeG

"2) is the format something like {sys.node.#.status}?" Yes. The # is the device address, aa bb cc 1 for example. The ending number, 1 in this case, is required. For devices with multiple nodes it is the number associated with the node. The second node of an 8 button KeypadLinc would be aa bb cc 2

The QueryAll Program exists to correct any inaccurate device status resulting from missed Insteon messages. In general when the QueryAll changes a device status it means there are comm issues where a state change was missed in earlier 24 hour period. The I/O Linc change in status can be the above or it can be duplicate Insteon messages affecting the Query analysis because the I/O Linc requires two commands to determine the relay and sensor status. For an I/O Linc that always changes status at 3AM it could also be it is running with Trigger Reverse set. This option reverses the Sensor state commands as the Sensor changes state but the option does not affect the Query response. It means the Sensor state will change at 3AM when the Trigger Reverse option is used. Already discussed the EZIO8SA. Need to see a LEVEL 3 trace.

This Program checks that the Then clause of 'After Hours Lights' was the clause run and then runs the same clause again. Also ISY Programs do not run serially. The Run of the Then clause does not wait for the Then clause to complete. There is no assurance that any of the Then statements have executed before the Set Scene 'Hallway' On statement executes. If Control 'Hallway Motion Sensor-Sensor' is switched On And Program 'After Hours Lights' is True Then Run Program 'After Hours Lights' (Then Path) Set Scene 'Hallway' On Else Run Program 'After Hours Lights' (Else Path)

I suspect the I/O Linc is running with Trigger Reverse option set. This option reverses the commands the I/O Linc Sensor sends as it turns On and Off. Unfortunately this option does not change what the Query returns so the 3AM QueryAll changes the I/O Linc Sensor Status even though the door has not moved. The best solution is install a NO magnetic switch in place of the NC switch that comes with the garage door kit. Then the Trigger Reverse option is not needed.

That is likely the Dual Band KeypadLinc that was released after 3.3.10 was released. Updating to a 994i would be the next step.

If you have the expected 5 nodes a 6 button KPL should have it is probably okay. However, there are devices not supported on 3.3.10 and that will only increase with time.

"Does this mean I need to walk around to every motion sensor, leak sensor, and door sensor and put them in programming mode one at a time? " Yes, one at a time. Insure that current one is taken out of linking mode before moving to the next battery device.

Here is an 8 button KeypadLinc example. It has 9 link records that have to be rewritten. The newest I2CS devices will be quicker because one Extended command per link record is needed. Older devices that use Peek/Poke write one byte at a time. Here is a SwitchLinc example that has 5 link records with the PLM address. The number of links in each device varies with the number of Scenes the device participates in.

"Did I get a defective PLM?" No. Changing PLMs means every link record in every device that points to the old PLM has to be rewritten with the new PLM address. A normal Restore Modem (PLM) operation does not affect devices outside of the PLM.

clarkes71 Be sure to change the Program to some other backlight level before using the event trace. As was mentioned before the ISY will not send a value it thinks the device already has.

"Is it correct that "is switched on" would include "switched fast on" detection as well as plain "switched On"?" No. "Is switched On" is using If Control and that is looking at command codes from the device, not status. An additional Control 'xxxx' is switched Fast On would be needed to check for that command code.

Yes, the PLM and an Access Point will provide coupling. That arrangement is not as flexible positioning wise since the PLM location is fixed but does reduce the number of plugin units.

The other On Level values can be changed with the Adjust Scene. However, only one value can be changed for each Adjust Scene statement so it can take several Adjust Scene statements to get all the various values Insteon may use. Post the actual Program where the Else would not execute. Right click on Program name and select Copy to Clipboard. Paste into post.

With the I/O Linc the duplicate message came in after the next command was issued and before that Query response was received. Made the duplicate look like it belonged to the Query last issued when it was a duplicate from the previous Query. I believe the ISY did ignore the duplicate but the duplicate from the ISY view was the response from the second Query. The EZIO8SA firmware has not changed for years so it is not likely a new issue is just surfacing. Not impossible but not very likely. If you know the relay states have been reported incorrectly a second Query call would show if the relays are actually On or not. What if you added a second Query in the test Program. Then if the second Query call produced a different set of relay values it would suggest the relays really are not On.

I suspect the issue will be the same thing we see with the I/O Linc. The Query of both the I/O Linc and the EZIO8SA requires two commands. The Insteon network returns duplicate messages for one of the query responses that due to the time when the duplicate comes back makes it look like a response to the other query. The event trace at LEVEL 3 will confirm that.

Next time this happens an Event Trace at LEVEL 3 with the Query response would be useful. Note the System Log entries are the results of the Query EZIO8SA Status Query Thu 2014/01/30 06:48:34 PM Web Log EZIO8SA Status 0% Thu 2014/01/30 06:48:35 PM System Log EZIO8SA / EZIO8SA - 2 Status 100% Thu 2014/01/30 06:48:35 PM System Log EZIO8SA / EZIO8SA - 6 Status 100% Thu 2014/01/30 06:48:35 PM System Log

Also note that the ISY Scene responder value is being changed which affects when the ISY Scene itself is referenced in a Program or invoked from the Admin Console. If the action of a controller paddle press should be affected more Adjust Scene statements are needed using the Controller device in the In Scene parameter. In Insteon the action of a responder is unique to each Controller.

The Adjust Scene statements do not physically change a device On Level or Ramp Rate. They establish the conditions desired for the next time the value being changed is used. After issuing the Adjust Scene statement(s) turn the Scene On so the new values take affect.

There are several posts with the same issue. Move to 4.1.2 or add the ISY IP address to the Java Exclusion list.

I would expect the UUID of the 99i being upgraded. Smarthome could have sales receipt requirement. Probably best to ask Smarthome what they require.

Exhaust fan motors are not very powerful. I have had to replace fan motors that fail to start using standard switches.

Loose wire on the load control ToggleLinc, failure of the relay, failure of the fan motor to spin. If the ToggleLinc indicates it is On but the load is not controlled the ToggleLinc hardware, wiring or the load itself has a problem.

Just as a KeypadLinc has a single Insteon address but multiple nodes, one for each button the hardware supports, the thermostat hardware has a "button" for when the thermostat is calling for heat and a "button" for when it is calling for AC. That is the design point of the thermostat hardware. I would not suggest deleting the nodes (Heat Ctl and Cool Ctl). I don't know what would happen when the thermostat signals it is calling for Heat or calling for Cool and the expected node to indicate that has been deleted. Actually don't know if they can be deleted. It would be removing some of the function provided by the thermostat. As far as its function, the node can be a Controller in a Scene where a light turns On, vents could be opened, when the furnace is producing heat or AC. A Program can be triggered when Heat/Cool is called for to do whatever is needed/desired.

The Heat Ctl node turns On when the thermostat is calling for Heat. That is, the current temperature is below the Heat Set Point and the thermostat is in a mode where heat can be requested. There is also a Cool Ctl node that turns On when the current temperature is above the Cool Set Point and the thermostat is calling for AC.

The message from the device to the PLM that it changed state is not being received if the device is showing a change intermittently. A device that never shows a device state change could be the result of the device or the PLM losing link records. If many devices never show a state change I would do a File | Restore Modem (PLM) to rebuild the PLM link database. If a single device not reporting state changes the a Restore Device can be done. A comm issue due to lack of coupling (maybe no Access Points since the passive coupler was installed) can also prevent a device state change from reaching the PLM. A sense of how well a device is seeing commands from the PLM can be determined by running the Event Viewer at LEVEL 3 and sending On and Off commands from the Admin Console. Watch the Hops Left count, 2 is best, 1 is okay, 0 is at the limit of operation. A Hops Left count that changes frequently indicates comm issues.