The only complete definitive information on a PLM would have to come from the Smarthome/Smartlabs Developer subscription. Smarthome considers that information proprietary. I don’t have a subscription so I cannot say for sure all you want to know about would be available. Generally we learn from our own experience or that of others.

Normally Access Points can communicate with each other between floors. Range on battery devices like the motion sensor or thermostat would be less, perhaps requiring more than two Access Points to cover dead areas but I would have thought Access Points between themselves would be okay. However, there are no absolutes in the business. If something is interfering with the RF signals being generated by the Access Points, more could be needed. I would try different plug locations before buying more Access Points. Mine are in opposite ends of the same floor but are communicating through a few walls. The distance between them would be less if installed on different floors. If the LED on the second access point indicated it was installed on the opposite 120v leg to the first installed Access Point I would think that was enough for cross phase coupling. More could be needed if wireless battery powered RF devices such as the Smarthome motion sensor had problems reaching one of the Access Points.

I would look at where the PLM is receiving power to start with. A simple test can be done by plugging the PLM into a good 3 wire extension cord and plugging the other end into a different circuit and different room away from where the PC/UPS is currently plugged in. This technique has worked well for several people in determining that the PC/UPS was attenuating the powerline signal, indicating a FilterLinc is necessary. If the computers are installed near each other, the larger FilterLinc can handle 10 amps so perhaps one or two is all that is needed. Of course if the computers are located in physically different locations more could be needed. Unplugging devices is also a good way to determine if they are causing a problem. Generally the extension cord technique is needed for the primary computer/UPS as they are needed to test with.

Insteon devices turning On/Off by themself is very unusual unless they have been assigned an X10 address. Then noise can easily turn an X10 address On/Off. There have been reported incidents where Insteon devices have been received from the manufacturer with X10 addresses already assigned and even active link records. Several folks on the Smarthome forum strongly recommend doing a factory reset on every new device before it is placed in service.

PC and UPS power supplies rank high in the signal attenuation category. I have PC/UPSs installed in different locations in the house and have put a FilterLincs at each location. Some TVs (not all for sure) have been a source of problems. I have a flat screen LCD in the bedroom and found it was causing a small problem. Found that one by pulling the plug. Reliability was not bad when it was plugged in, just got a little better when unplugged so I put a FilterLinc on it. Have not heard anyone talk about a refrigerator being the source of a problem. Hair dryer could be considering the type of motor but how often or long would that device be running.

There should be no reason to have to do anything with the Access Points that I am aware of. Assuming they were correctly installed on opposite 120v legs to begin with. Seems like something has changed though since you can now access devices you were not able to before. Maybe something is not on now that was on before. Or perhaps the opposite. A 240V appliance like an electric hot water heater or electric dryer, etc. can couple the 120v phases so if the Access Points are not actually on opposite 120v legs, other things can create cross phase coupling on a temporary basis.

Should be no difference between the EZSrve and the EZBridge. The same 01.60 image.bin file runs in both.

The EZSrve/EZBridge requires a link from the Insteon device as a Controller and the EZSrve/EZBridge as a reponder for it to receive a Group message from a device when the device manually changes state (on/off). The links you describe are going in the opposite direction. Assuming the correct links are present, I think the device view/control screen will reflect the correct status on the next auto refresh. I believe that is why the auto-refresh takes place. Of course you can always request a specific refresh which actually queries the devices (not all devices can be queried in that fashion). I don’t keep track of my devices that way so there could be an exception I am missing.

Regarding the links from your earlier post ……

Also…my EZServe is listed as controlling all 5 of my devices (4 lights and ezrain).

All say “Controller of on Unit 01 – Data:00-00-00”

All device entries are listed as following:

Responder to 09.39.03 on Unit 01 – Data:FE-1B-00 (diff. data for each though)
Responder to EZServe on Unit 01 – Data:FE-1B-00

You don’t mention what the EZBridge has but the post says the EZSrve is listed as controlling all 5 devices. All device entries are listed as “Responder to”.

Nothing wrong with those links as far as allowing the EZSrve to control the responder devices. Since EZSrve is controlling those devices the device status change originates at the EZSrve and all is well.

What I thought you were looking for was when you press an On or Off paddle on the switch itself, EZSrve device status is not updated. For the SwitchLinc to send a Group message to EZSrve, the SwitchLinc device must have a “Controller of” link record that points to EZSrve, and EZSrve must have a “Responder to” link record containing the SwitchLinc address. Now when the On or Off paddle is pressed, the SwitchLinc will send a Group message to EZSrve which EZSrve will receive and process because it has a “Responder to” link record. I think this will update the device status.

I don’t know if there is a different processor (or the same processor being clocked at a different speed). I have both an EZSrve and an EZBridge and see no visible difference in response speeds.

I just tested the theory about the Device View/Control screen being updated if the device had a Controller of link and the EZSrve had a Responder to link record. Does not work. It is documented that X10 device status is not updated on that screen. Looks like Insteon devices are not either. You will have to click on the REFRESH button to get the current status.

EDIT: if you want a Macro to trigger from a SwitchLinc paddle press you will need the link records I described above.

The PLM (internal and external) has a Monitor mode that when activated would pass on Insteon message traffic to the application. This feature turned out not to be reliable. It is only an assumption but without a reliable way to independently Monitor powerline traffic the Device View/Control function would not be accurate so it was decided not to implement that function at all.

EZServ/EZBridge Timers and Macros issued by the respective device which turn on/off Insteon devices are reflected in the device status on the Device View/Control screen. Example, a Timer turns on an ICON switch in my case (similar to a SwitchLinc without the variable ramp rate feature). When the Timer fires, the ICON switch is turned on and the device status on the Device View/Control screen indicates the ICON switch is On. A second Timer turns off the ICON switch a few minutes later and the device status on the Device View/Control screen indicates the ICON switch is Off.

I coded a Macro to fire whenever I press the On paddle of the ICON switch. The Macro Action turns on a LampLinc. When I press the ICON On paddle the LampLinc turns On and the Device View/Control screen shows the LampLinc as On. A second Macro fires when I press the ICON Off paddle, with an Action that turns the LampLinc Off. When I press the ICON Off paddle, the LampLinc turns Off and the Device View/Control screen indicates the LampLinc is Off.

For Insteon devices which EZSrve/EZBridge turns On/Off with a Timer, Macro or On/Off Icon press on the Device View/Control screen, the device status reflects that activity. It does not reflect activity it did not initiate unless the REFRESH button is pressed.

For EZSrve/EZBridge to be aware of the ICON paddle press, either On or Off to activate a Macro, the link I described in an earlier post must be present.

Sorry, clearly I have not been using the correct words after reading your last post. Create a controller link between the device you want to monitor and the EZSrve/EZBridge as a responder. With this you can trigger a macro from the device on/off action. Insteon devices do not send messages on the powerline unless they are linked to something. Without a link there is no message to monitor. You can press the SwitchLinc paddle On/Off and it will control whatever local load is connected to the SwitchLinc. However, the SwitchLinc does not send any message on the powerline unless the SwitchLinc is a Controller (contains a Controller of link record). This is not unique to a SwitchLinc. Motion Sensors, ICON switches, ToggleLincs, RemoteLincs, and on and on do not send Group messages (the method Insteon hardware devices communicate with each other) unless and until they have a Controller of link definition and responder devices do not react to the controller messages unless they have a Responder to link record. A Group message sequence is made up of two Insteon messages. The second message is directed to a specific responder device and that responder device address is contained in a Controller of link record. For every device that is to be notified of the SwitchLinc paddle press, a unique Controller of link record is required containing the Insteon address of the responder.

There is an Insteon Details document in the public domain section of the SmartLabs web site. Perhaps becoming familiar with the general Insteon architecture and the requirement to link Insteon devices together will help in understanding the requirements of Insteon hardware. The above has nothing to do with EZSrve or EZBridge. HouseLinc2 (Smarthomes PC based home automation software), PowerHome2 (another very popular PC based home automation software) have the same requirements. Insteon hardware devices send Group message sequences only to devices that have been linked as a responder.

X10 devices are assigned a House/Unit code and connected to the powerline. They blindly send those codes and any device that happens to receive it can react to it. Very easy and very unreliable because one never knows what device(s) if any has received the X10 messages. With Insteon, controllers and responders are linked together, allowing the responder device to ACK messages that are directed to it which also allows the controller to repeat a message for which no ACK is received. More complex to establish, more complex to administer, but has the capability to be extremely reliable. Hope this helps clarify Insteon hardware requirements.

SwitchLinc A and SwitchLinc B are cross linked to form a virtual 3 way circuit. With the two devices cross linked pressing SwitchLinc A On paddle causes A to send a Group message to SwitchLinc B telling B to turn On. Same is true in the opposite direction. Pressing SwitchLinc B On paddle causes B to send a Group message to SwitchLinc A telling A to turn On.

SwitchLinc C does not react to messages from SwitchLinc A or SwitchLinc B because it has not been linked to either device. This is standard Insteon architecture and has been from the beginning of Insteon.

Now replace SwitchLinc C with a PLM associated with an EZBridge or EZSrve. The PLM does not react to messages from SwitchLinc A or SwitchLinc B because it has not been linked to either device. Now turn on Monitor mode in the PLM. In theory the PLM would react to messages from SwitchLinc A and/or SwitchLinc B without being linked to either A or B. This would allow the application connected to the PLM to be aware of activity on SwitchLinc A and/or SwitchLinc B without being linked to either device. The Monitor feature has proven not to react to messages from SwitchLinc A and/or SwitchLinc B all the time making the Monitor feature unreliable.

The solution that all products are using is to require the PLM to be linked to any device that the PLM will react to. This makes the PLM link requirement the same as any other Insteon device. Just as SwitchLinc C would not react to messages by SwitchLinc A or SwitchLinc B without having a link to A and B, the PLM requires a link to each device it is going to react to. The PLM Monitor mode was a nice idea that did not work in the real world so all applications including EZSrve/EZBridge require the link that was required before the Monitor mode idea came along. With these links in place EZSrve/EZBridge Macros can be triggered by actions of SwitchLinc A and SwitchLinc B providing the control you are looking for.

For a Motion Sensor example, you could link the Motion Sensor to SwitchLinc C if you want the Motion Sensor to have direct control of another Insteon device. Or you can link the Motion Sensor to the EZSrve/EZBridge PLM in which case Macros could be triggered to control SwitchLinc C. You can even do both. Have the Motion Sensor linked to SwitchLinc C so the Motion Sensor turns on C directly and have the Motion Sensor linked to the PLM so that EZSrve/EZBridge could trigger a Macro with a time delay action that turns off SwitchLinc C 10 minutes later.