Device Not Sending Signal?

[yardman 49]

Hello linuxguy:

 

Excellent information! Thanks very much. This really confirms what we've all been discovering by way of common experience, that the PLM is basically "deaf" compared with other Insteon devices.

 

I guess that you just pulled these numbers off of the product spec sheets. So simple, I should have looked at this earlier! I just never expected it to actually be published, I guess.

 

I 'm certain that Michel will find this to be very useful.

 

 

Best wishes,

[Algorithm]

I have been studying the minimum signal sensivity in the SmartHome docs. Here is what I found:

 

Device..............SH #..........Min Sensivity (mvPP)

PLM..............2412S...................20

LampLinc.......2456D3/S3..........10

SwitchLinc.....2476D/S/ST...........1

Access Pts.....2443.....................1

SignaLinc.......2442......................1

 

Excellent information, Jim; thanks for posting. You made me curious as to how Icon modules would compare, so I just went and checked some additional modules.

 

I found the the ApplianceLinc and the Icon Appliance Module were both 10 mvPP, the same as the three-pin LampLinc you indicated. But, the Icon Lamp Dimmer and the two-pin LampLinc both show 1 mvPP, which makes me question the accuracy of the information on Smarthome's web site. Why would the two-pin LampLinc be so different from the three-pin LampLinc, I wonder?

 

Next, I checked some in-wall switches, and found the SwitchLinc Relay, the ToggleLinc Dimmer and Relay, and the Icon Dimmer and Relay all to be 1 mvPP, the same as the SwitchLinc Dimmer. That seems to make more sense.

 

Finally, I checked the PLC Serial and USB, but neither had that specification listed. However, the Specification Table for the Serial PLC (2414S) indicates a Product No. of 2414U, a definite error on Smarthome's site.

 

Anyway, good information and conclusions. Perhaps the above information on the Icon modules may benefit others who have lots of those type of modules, as I do.

[Guest]

I have been studying the minimum signal sensivity in the SmartHome docs. Here is what I found:

 

Device..............SH #..........Min Sensivity (mvPP)

PLM..............2412S...................20

LampLinc.......2456D3/S3..........10

SwitchLinc.....2476D/S/ST...........1

Access Pts.....2443.....................1

SignaLinc.......2442......................1

 

Excellent information, Jim; thanks for posting. You made me curious as to how Icon modules would compare, so I just went and checked some additional modules.

 

I found the the ApplianceLinc and the Icon Appliance Module were both 10 mvPP, the same as the three-pin LampLinc you indicated. But, the Icon Lamp Dimmer and the two-pin LampLinc both show 1 mvPP, which makes me question the accuracy of the information on Smarthome's web site. Why would the two-pin LampLinc be so different from the three-pin LampLinc, I wonder?

 

Next, I checked some in-wall switches, and found the SwitchLinc Relay, the ToggleLinc Dimmer and Relay, and the Icon Dimmer and Relay all to be 1 mvPP, the same as the SwitchLinc Dimmer. That seems to make more sense.

 

Finally, I checked the PLC Serial and USB, but neither had that specification listed. However, the Specification Table for the Serial PLC (2414S) indicates a Product No. of 2414U, a definite error on Smarthome's site.

 

Anyway, good information and conclusions. Perhaps the above information on the Icon modules may benefit others who have lots of those type of modules, as I do.

 

Just guessing here but maybe it depends on the micro etc in the unit and how much noise it produces which affects the sensitivity of the device. Cant think of anything else that would make sense.

[BobMiller]

Linuxguy/Digger/Just another Joe,

 

Why don't you consolidate your results and put it in the "Everything Insteon" forum? And ask SteveL of Smarthome for his comment on your various questions, particularly the conflicting data and why the PLM would have such poor sensitivity.

 

Great information - that does clarify a lot of things.

 

Bob

[Michel Kohanim]

linuxguy,

 

Thank you so very much for this information. I do agree with Bob that this should also be posted in the Everything INSTEON forum.

 

This information is quite invaluable simply because no longer do we have to ask everyone to get an AccessPoint! They could get an LL and expect the same level of coverage.

 

Thanks again!

With kind regards,

Michel

[MikeB]

This information is quite invaluable simply because no longer do we have to ask everyone to get an AccessPoint! They could get an LL and expect the same level of coverage.

 

The LL may have the same sensitivity as an AP, but wouldn't the AP have the added advantage of being able to send & receive signals via RF as well?

[Guest]

This information is quite invaluable simply because no longer do we have to ask everyone to get an AccessPoint! They could get an LL and expect the same level of coverage.

 

The LL may have the same sensitivity as an AP, but wouldn't the AP have the added advantage of being able to send & receive signals via RF as well?

 

Yep the Accesspoint would be much better suited to get the signal out over the mesh since the power line signal might antenuated by a signal sucker on the power line and the RF could jump the message elsewhere in the mesh and "backfeed" the message.

 

The RF is probably (not stating a fact) much more reliable then the power line carrier messaging since the accesspoints seem to have a range of 100 feet or more even with intervening walls, wireless networks and phones, cell phones etc in the house. A power line message sometimes cant get a few feet if there is noise or a signal sucking product on the branch circuit.

 

I experimented earlier this year and found two switchlincs in the same box on the same circuit could not be linked (I was troubleshooting why the one switch could not be remotely controlled at all). If I disconnected the load on the one switch they linked fine. It turned out that the CFL bulbs on the one switches load was killing the signal between the switches even though it was only about 6 inches of wire. Changing the brand of the bulb corrected the problem (the original CFL's were 5 years old).

[linuxguy]

Thanks for all the comments.

 

I don't necessarily recommend (in general) using a LL instead of an AP on the PLM. It just happens to work OK in my case. Remember the LL is 10 mv sens, whereas the AP is one mv.

 

I would be happy to pull all this together to post to the other thread. I just won't have time to do so until this evening.

 

Linuxguy

[BobMiller]

Michel,

 

I got 4 FilterLincs in and put them on what I suspect are the biggest offenders in my house: Main computer, NAS disk system (5 drives, WLAN and router), a refrigerator and my stereo system.

 

I also moved my ISY/PLM to what I think is a quiet powerline leg. I haven't gotten new Access Points yet, so I plugged a Signalinc into that outlet as well to "boost" the returning signal to the PLM.

 

Then as an experiment I plugged a Lamplinc (v.28 ) into that same outlet and controlled it via a Keypad. I could also control the LampLinc via the ISY/PLM, so everything in that regard was functional. The ISY/PLM seems to be able to access and query and device in the house.

 

But... I could not see a LampLinc status change on the ISY when it was being controlled by the keypad. I went ahead and factory reset the LampLinc and restored it, and still no luck.

 

I tried similar experiments with other devices in the house and could never get the ISY to detect a state change in my network (other than doing a query).

 

These units (PLM/LampLinc/SignalLinc) are stacked via the "pass-thru" plugs so they could be no closer. (I am keeping in mind Digger's point with his 2 SWL in one box experience but I have no other components nearby on this circuit).

 

At this point it seems my PLM receive path must be the culprit, and I can only conclude that the PLM is not working properly. Do you have any other suggestions as to what I may not be doing properly?

 

When I am monitoring network state I have the display page open for the device (the LampLinc in this case) and watching the On/Off state. My understanding is if that device (the LampLinc) changes state due to some external control (the Keypad for example) the LampLinc is programmed to broadcast this state change to the ISY/PLM and that the ISY will automatically update the display page. Is that all correct?

 

I have also created a "test program" that recognizes this state change and turns on another indicator light as a result of a change on the LampLinc. This program will work if I use the ISY to change state of the LampLinc (because it obviously is aware of the state change) but will not work if another external device changes the LampLinc state (because the PLM doesn't get the state change).

 

I'm stuck.

 

Thanks for your help,

 

Bob

[Michel Kohanim]

Hi Bob,

 

I am so very sorry to hear that you are still experiencing problems.

 

The first thing that we have to clear up is that:

LampLincs do NOT send their status to the PLM. Actually, no INSTEON device send its status to any other INSTEON device unless specifically requested (query).

 

Now, there are two cases:

1. In the case of direct command to a device, that device responds back with an Ack (echo of the command) and thus we can assume that now the device is at the given state

2. In the case of group commands, each device responds with a group clean up and thus, the same as above, we can assume that the device is in the given state

 

Now, taking all the above into consideration:

1. If you turn on/off the LL from ISY, and if the device actually turns on/off, but you do not see a state change, then I would suspect your LL (is it old?): i.e the LL is not sending back and Ack (echo)

2. If your LL is in a scene with a SWL/KPL, and if you try to turn on/off the scene from ISY (click on the Scene node), and if all the devices in the scene are controllable through ISY, but if you don't see their status get updated on ISY, then I would suspect your PLM

3. Now, if you click on an SWL/KPL and their status is not updated on ISY, then I would suspect KPL/SWL first (if they are really old) and then the PLM second

 

You had mentioned that you had many old SWLs. Have you tried this experiment with your new SWLs?

 

With kind regards,

Michel

 

Michel,

 

I got 4 FilterLincs in and put them on what I suspect are the biggest offenders in my house: Main computer, NAS disk system (5 drives, WLAN and router), a refrigerator and my stereo system.

 

I also moved my ISY/PLM to what I think is a quiet powerline leg. I haven't gotten new Access Points yet, so I plugged a Signalinc into that outlet as well to "boost" the returning signal to the PLM.

 

Then as an experiment I plugged a Lamplinc (v.28 ) into that same outlet and controlled it via a Keypad. I could also control the LampLinc via the ISY/PLM, so everything in that regard was functional. The ISY/PLM seems to be able to access and query and device in the house.

 

But... I could not see a LampLinc status change on the ISY when it was being controlled by the keypad. I went ahead and factory reset the LampLinc and restored it, and still no luck.

 

I tried similar experiments with other devices in the house and could never get the ISY to detect a state change in my network (other than doing a query).

 

These units (PLM/LampLinc/SignalLinc) are stacked via the "pass-thru" plugs so they could be no closer. (I am keeping in mind Digger's point with his 2 SWL in one box experience but I have no other components nearby on this circuit).

 

At this point it seems my PLM receive path must be the culprit, and I can only conclude that the PLM is not working properly. Do you have any other suggestions as to what I may not be doing properly?

 

When I am monitoring network state I have the display page open for the device (the LampLinc in this case) and watching the On/Off state. My understanding is if that device (the LampLinc) changes state due to some external control (the Keypad for example) the LampLinc is programmed to broadcast this state change to the ISY/PLM and that the ISY will automatically update the display page. Is that all correct?

 

I have also created a "test program" that recognizes this state change and turns on another indicator light as a result of a change on the LampLinc. This program will work if I use the ISY to change state of the LampLinc (because it obviously is aware of the state change) but will not work if another external device changes the LampLinc state (because the PLM doesn't get the state change).

 

I'm stuck.

 

Thanks for your help,

 

Bob

[BobMiller]

Michel,

 

Thanks again for your followup.

 

I've tried to glean out what I can from the forum, but I can see that my mental model for the network still has some misconceptions and gaps. Is there any one location/document that summarizes network operation between devices and the ISY.

 

I'd volunteer to create that document as a good learning experience (and hopefully valuable resource) but I'm not sure if I know enough yet to be even dangerous... If there was some type of flow chart for various modes of operation, that would be very useful for debugging.

 

Your point:

 

1. In the case of direct command to a device, that device responds back with an Ack (echo of the command) and thus we can assume that now the device is at the given state

2. In the case of group commands, each device responds with a group clean up and thus, the same as above, we can assume that the device is in the given state

 

It sounds like you are saying that the way an asynchronous external operation (external to the ISY: like a SWL/KPL turning on another device, like a LL) gets back to the ISY, is that the "controlled device(s)" each send back an ACK to the SWL/KPD and the PLM intercepts that ACK. Is that correct? In the case of a scene, I assume each device sends back an ACK and the PLM intercepts each ACK. The PLM is thereby able to update its status of the network. What is a group command? Is it equivalent to a scene?

 

I may be still confused because if the PLM triggers off an ACK from the responder (LL in this case) then I don't understand your point in #3 below that the KPL/SWL would be the problem. I would think that the communication would be between the LL and the PLM and one of those two would be the problem.

 

In answer your questions:

 

1. If you turn on/off the LL from ISY, and if the device actually turns on/off, but you do not see a state change, then I would suspect your LL (is it old?): i.e the LL is not sending back and Ack (echo)

 

This works fine - the status of the LL is properly updated n the ISY. For reference, LL = v.28

2. If your LL is in a scene with a SWL/KPL, and if you try to turn on/off the scene from ISY (click on the Scene node), and if all the devices in the scene are controllable through ISY, but if you don't see their status get updated on ISY, then I would suspect your PLM

 

The LL is in a scene (the scene only has the LL) driven by a KPL. I can turn On/Off the scene from the ISY and the status of the LL is properly updated on the ISY.

 

I also added another device to the scene and it worked fine - status is properly updated on the ISY if I control the scene from the ISY.

 

One side note - I found that I couldn't add many devices in my house to the scene - I would get failures....

 

3. Now, if you click on an SWL/KPL and their status is not updated on ISY, then I would suspect KPL/SWL first (if they are really old) and then the PLM second

 

This is the function that fails. If I click the KPL, the LL changes state as expected however the ISY does not register that state change. If I do a query at the ISY, then it immediately registers the proper state of the LL. The KPL is v.26. In my case the LL/PLM are piggy-backed and should have the best communication on the network.

 

Sorry to drag this out,

 

Bob

[Michel Kohanim]

Hello Bob,

 

Apologies for a tardy reply!

 

 

It sounds like you are saying that the way an asynchronous external operation (external to the ISY: like a SWL/KPL turning on another device, like a LL) gets back to the ISY, is that the "controlled device(s)" each send back an ACK to the SWL/KPD and the PLM intercepts that ACK. Is that correct?

No. Here's the procedure:

1. The SWL/KPL send a command to their responders one of which is the PLM

2. All responders respond to the SWL/KPL command

3. The PLM receives the command, makes sure there's slave link for that device and then forwards it to ISY

4. ISY figures out what has happened and changes the state of devices accordingly (predictive)

So, the main test is to see if the PLM can hear the button presses on your KPLs and SWLs. If the PLM does not hear this, then it won't be able to send the status to ISY and thus no status changes in ISY.

In some cases, doing a factory reset on the SWL/KPL fixes the issue. However we have not yet found a workaround for SWLs/KPLs.

Another possibility is that you may have reached the maximum number of supported links in the PLM. How many devices do you have and out of those how many are CLs/KPLs/RLs?

 

... What is a group command? Is it equivalent to a scene?

Group command is a shortcut for sending n commands to n member of a scene. i.e. you send one command to a scene and all the members respond. Yes, group and scene may be used interchangeably (at least for now).

 

One side note - I found that I couldn't add many devices in my house to the scene - I would get failures....

Things are pointing more and more to the PLM and/or noise.

There are three cases when adding devices to scenes fail:

1. Comm error ... try querying all the devices in the scene and see which one fails (device comm error). Try doing an airgap on that device and see if it fixes the problem

2. PLM ... try unplugging the PLM, leaving it out for about 10 seconds, and then plug it back in

 

This is the function that fails. If I click the KPL, the LL changes state as expected however the ISY does not register that state change. If I do a query at the ISY, then it immediately registers the proper state of the LL. The KPL is v.26. In my case the LL/PLM are piggy-backed and should have the best communication on the network.

Does the state of the KPL itself change in ISY? Is this the case for ALL your KPLs? I do think that you have either reached the max links on your PLM or you have old KPLs. We just have to figure out which!

 

With kind regards,

Michel

[BobMiller]

Michel,

 

Thanks for hanging in there with me. I apologize for not being very grounded in the fundamentals of the Insteon network - I've started coming up to speed via the forum. I searched for more information today and found two documents on the insteon.net site. I found them very useful in describing the network operation as well as defining the terminology. In case it's not commonly known to others reading this, their location is:

 

http://www.insteon.net/pdf/insteondetails.pdf

http://www.insteon.net/pdf/insteoncompared.pdf

 

 

Is there a repository of documentation or pointers to docs in the forum somewhere that I missed?

 

In any case, I've done a lot of experimenting. And the good news is made a lot of progress as well.

 

1) I had some serious noise/signal quality issues. I received and installed 4 FilterLincs and 4 Access Points plus left in the existing two SignalLincs. I also reset the PLM as you recommended and also restored all devices and PLM. I seem to have a pretty clean query. Occasional hiccups - so I still need to spend time moving around my Access Points. But in general a lot better than before.

 

2) My link count was close to the limit. My impression is that the link calculator is a rough approximation (with the scene link usage - I assume it uses a average scene size. I think I may have been above the average) so I reorganized my scenes and reduced them from 28 to 22. I also reduced the number of members in the scenes. (question on this at the end). The link calculator shows roughly 355 links now. SO I think I am clear of the limit.

 

3) You asked:

 

Does the state of the KPL itself change in ISY?

 

No it doesn't in the KPL under test. I assume you mean if I monitor the scene associated with that KPL button, because just viewing the KPL button gives no information. (I have ISY FW 2.4.15)

 

Is this the case for ALL your KPLs?

 

After I fixed the various noise/signal issues I found that my other two KPL's (and other SWLs as well) now work properly (i.e. the ISY is able to properly register external state changes).

 

I do think that you have either reached the max links on your PLM or you have old KPLs. We just have to figure out which!

 

So it now seems to have narrowed down to one KPL (I haven't exhaustively checked out all other SWLs but a general sampling looks good - even v.22's). That KPL is v.29, my other two KPLs are v.26 and v.29). So I assume the KPL is bad at this point. I will move around Access Points to make sure there is no transmission issue but you've help me get to the bottom of this. Thank you very much!

 

One other question on scenes:

 

Previously I had many scenes that had 25-35 members. To reduce those I created 5 or so scenes that were subsets of all these scenes and then in the program area I created programs that combined these subsets (for example " If .... then ... do scenes 1 and 2" ) to give me what I needed. I was trying to reduce the total number of scenes and the number of members in a scene - I assume these are both good things to do.

 

My questions are:

 

1) I assume that the control of the scenes as defined by the programmed "If/then/else" statements only exist in the ISY - is that correct? I.e. if the ISY was turned off the If/Then operations could not be performed. This would be in contrast with a typical linkage where a KPL might control a scene directly and not need a ISY to operate.

 

2) And the scenes defined in the THEN statement are stored as groups in each device?

 

3) Other than requiring the ISY, is there any other disadvantage of this approach?

 

 

One final comment: after all this debugging of my house setup - which I would think is a fairly standard environment - and the addition of lots of FilterLincs and Access Points (I still need to add more of both), I feel that the Insteon networks are significantly less robust than all of Smarthome's literature would leave us to believe. My impression is that the RF part saves the system - so why send anything over the powerline (Zigbee here we come).

 

Thanks again, Michel, for your help. Now I can get down to really using the ISY (and probably generating more questions!! Bad for you, eh!?)

 

Bob

[IndyMike]

Bob,

 

I'm coming in a bit late here, so I'll apologize up front if I'm repeating something.

 

I noticed the devices that you placed filters on. Most of these would be considered signal "absorbers" (at least to X10).

 

I also noticed that you're located in CA, an most likely have a good number of CFL's installed? If that's the case, I'd submit that your culprit is the CFL's generating line noise (beat frequencies and turn-on transients) rather than the devices that you've filtered (I've never filtered a 'Fridge).

 

All CFL's are not created equal. I experimented with various brands a few months ago (I live in Indiana - we don't have the CA restrictions) and settled on Sylvania as being X10 friendly. I ran numerous tests on an isolated circuit measuring beat frequencies and turn on transients. Some of the "other" CFL's would generate noise in the X10 frequency range with several volts of amplitude (I don't have equipment for monitoring Insteon frequencies).

 

If the CFL's are generating noise, you can choose to amplify your Insteon signals (more accesspoints), replace the offending CFl's, or filter them with an inline filter.

 

Other than the possibility of CFL noise, our installations are similar. I have a 4500 ft^2 house with 25 Insteon devices, 5 computers, 1 network server (my version of your NAS) and 2 SignialLincs. Communication is 95% with X10, 100% with Insteon.

[BobMiller]

Dear IndyMike,

 

Thanks for your suggestions.

 

Yes, in general I was trying to filter the signal absorbers and to hopefully minimize signal attenuation. The Fridge was a bit of a long shot but I thought it might be a noise generator (inductive kick tends to cause big voltage spikes). I admit I was grasping for straws since my system performance was so poor.

 

Thanks for the tip on the CFL. Now that you mention it I have a couple fluorescent lights in the garage (but not always on) as well as a fluorescent in my office area (often on) and a CFL the utility room (often on). I assume a fluorescent will potentially generate similar noise. I should borrow a spectrum analyzer from work and check it out.

 

I'll see what I can do to put Filterlincs in those paths.

 

Sounds like our environment is very similar. But I still can't believe that the Insteon system is so sensitive - I would have thought that with 40+ repeaters (SWLs) in a 2600 ft^2 house, I would have gotten by with a simpler setup (less filters, Access Pts, etc.) than I seem to need.

 

I need to dig into this some more - as you suggest there is probably one nasty device, like a CFL, in the house, that is causing me all my grief.

 

Thanks,

 

Bob

[IndyMike]

Bob,

 

By no means should you consider me "experienced" with Insteon. I've owned Insteon devices for two years but have operated them in X10 mode. I would consider myself "somewhat" experienced with the trials and tribulations of X10.

 

That being said:

 

I agree with most of your assessment including the commentary on the 40+ repeaters. I'm still trying to figure out the timing aspects the the Insteon "repeating". If someone has a link to a technical description (timing diagrams), I'd greatly appreciate the assist.

 

The one thing in your post that I may have a problem with is a "single" noise source. I don't think a single noise source would explain the behavior that you're observing.

 

I have an advantage in that I approached this from the X10 side. I've operated my Insteon devices in X10 mode for two years now. From what I've seen, if X10 signals work reasonably Insteon will be flawless.

 

I'm not altogether sure that your problem is noise/signal level related or hardware related (firmware revisions of your devices). If you are interested in the "old fashioned" X10 troubleshooting approach, pm me and I can provide some links.

 

IndyMike

[Michel Kohanim]

Hello Bob,

 

I am so glad you got some of the issues taken care of. That was quite ingenious of you to reduce the size of your scenes. But, I really do think that we should get you a new extended memory PLM when/if they are released.

 

Please find my answers below.

 

With kind regards,

Michel

 

Previously I had many scenes that had 25-35 members. To reduce those I created 5 or so scenes that were subsets of all these scenes and then in the program area I created programs that combined these subsets (for example " If .... then ... do scenes 1 and 2" ) to give me what I needed. I was trying to reduce the total number of scenes and the number of members in a scene - I assume these are both good things to do.

Yes, but with the disadvantage of delays and more traffic on the Powerline network.

My questions are:

 

1) I assume that the control of the scenes as defined by the programmed "If/then/else" statements only exist in the ISY - is that correct?

Yes.

 

I.e. if the ISY was turned off the If/Then operations could not be performed. This would be in contrast with a typical linkage where a KPL might control a scene directly and not need a ISY to operate.

Precisely!

 

2) And the scenes defined in the THEN statement are stored as groups in each device?

If and only if your action is against a scene that you have created yourself in the Main tab.

 

3) Other than requiring the ISY, is there any other disadvantage of this approach?

Yes, a lot of traffic! Here's the scenario:

If you had a scene with 30 devices, then you would send ONE command to the group number and you would receive 30 group cleanup returned from each member (total of 31 x 500 m.s.).

 

Now, if you chop of your group into 5 groups of 6 then:

Send the group command to the first group, wait for the group cleanup to compelete for the 6, repeat for the other 4 groups.

 

I personally do not recommend it and that's why I think we'll have no choice but to upgrade to the extended memory PLM when they are available.

 

With kind regards,

Michel