From: Eloy P. <pe...@ch...> - 2011-08-18 14:58:14
|
Hi list, Just wanted to share something that I've kinda suspected for a while (and that some of you probably knew) but that I finally confirmed for sure last night: CFLs introduce noise that affect INSTEON communications. What I am seeing is that I can reach a certain relay switch when the light is off -- I can request status and receive the response immediately, and I can turn the light on. No message retransmissions; it just works. However, as soon as I turn the light on, communications break down, badly -- in most cases MH's 5 retransmissions fail. To test the theory of CFLs introducing noise, I replaced the CFLs in that light fixture with incandescent light bulbs, and voilà, problem fixed. In http://misterhouse.wikispaces.com/Insteon, Marc has some comments on CFLs, but I had not paid attention because I thought it was a discussion on the use of CFLs with dimmers, which I don't have (all my CFLs are controlled by relays). I also found this discussion that took place here, but that I didn't see before because I was not subscribed to the list then: http://tech.groups.yahoo.com/group/misterhouse/message/39627 So, nothing new for the old-timers here, but definitely new to me, so I thought I'd share the story for the benefit of those new to INSTEON and to the list ;-) By the way, is anyone aware of a good solution to this problem? Cheers, Eloy Paris.- |
From: Marc M. <ma...@me...> - 2011-08-18 16:59:42
|
On Thu, Aug 18, 2011 at 10:57:51AM -0400, Eloy Paris wrote: > Hi list, > In http://misterhouse.wikispaces.com/Insteon, Marc has some comments on > CFLs, but I had not paid attention because I thought it was a discussion > on the use of CFLs with dimmers, which I don't have (all my CFLs are > controlled by relays). I can indeed reconfirm that CFLs do induce noise on my insteon bus, especially when they're on. > > So, nothing new for the old-timers here, but definitely new to me, so I > thought I'd share the story for the benefit of those new to INSTEON and > to the list ;-) > > By the way, is anyone aware of a good solution to this problem? I'm very surprised that you're having noise with relays. The whole point of relays is to disconnect the load from your bus, and Smarthome does support CFLs with relays. If you can reproduce this, you may have an issue with the relays that you should talk to smarthome tech support about. Please keep up posted. > I also found this discussion that took place here, but that I didn't see > before because I was not subscribed to the list then: > > http://tech.groups.yahoo.com/group/misterhouse/message/39627 On this note, I'd love to know more. I still don't understand how this is possible since insteon is supposed to have CRCs which definitely protect against bit flips. My hunch right now is that some insteon devices (like my older KPLs) do not implement CRC checking. Does anyone if the spec says either way? Thanks, Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Eloy P. <pe...@ch...> - 2011-08-18 17:48:51
|
Hi Marc, On 08/18/2011 12:59 PM, Marc MERLIN wrote: > On Thu, Aug 18, 2011 at 10:57:51AM -0400, Eloy Paris wrote: >> Hi list, >> In http://misterhouse.wikispaces.com/Insteon, Marc has some comments on >> CFLs, but I had not paid attention because I thought it was a discussion >> on the use of CFLs with dimmers, which I don't have (all my CFLs are >> controlled by relays). > > I can indeed reconfirm that CFLs do induce noise on my insteon bus, > especially when they're on. :-( >> So, nothing new for the old-timers here, but definitely new to me, so I >> thought I'd share the story for the benefit of those new to INSTEON and >> to the list ;-) >> >> By the way, is anyone aware of a good solution to this problem? > > I'm very surprised that you're having noise with relays. The whole point > of relays is to disconnect the load from your bus, and Smarthome does > support CFLs with relays. > If you can reproduce this, you may have an issue with the relays that > you should talk to smarthome tech support about. > > Please keep up posted. I think what I am seeing makes sense -- I see no problems at all when the light is off (I think because the CFLs are not energized and therefore, cannot be generating noise). But then, when the light is on, the CFLs are energized, and therefore, generating some noise that affects INSTEON communications. But you are right, if they say that CFLs are supported with relays then it'd be good to talk to them. I fear they'll put the blame on something else, though. Here's another old discussion where someone experienced the same problem I am experiencing: http://www.perceptiveautomation.com/userforum/viewtopic.php?t=1392 >> I also found this discussion that took place here, but that I didn't see >> before because I was not subscribed to the list then: >> >> http://tech.groups.yahoo.com/group/misterhouse/message/39627 > > On this note, I'd love to know more. I still don't understand how this > is possible since insteon is supposed to have CRCs which definitely > protect against bit flips. Man, I am glad you bring this up again -- if there is something that I really really *really* want to know about INSTEON is precisely that, i.e. how is it possible that we are seeing this darn bit corruption if there is a CRC byte that all devices are supposed to check, and then discard the entire message if the CRC is incorrect. That just does not seem to be happening. Otherwise we would not see so many corrupted link tables in our devices. I wish someone had a good explanation for this. I have brought this issue up many times before, a few times here, and even in the Smarthome forum: http://www.smarthome.com/forum/topic.asp?TOPIC_ID=7006 (As you can see, nobody from Smarthome took interest, and there was no resolution, and nobody answered the direct question of whether the CRC byte is being checked.) > My hunch right now is that some insteon devices (like my older KPLs) do > not implement CRC checking. > Does anyone if the spec says either way? I agree, it does look like some devicesare not checking CRCs, and that, if true, contradicts what the INSTEON technical documents say. This is what that "INSTEON: The Details" whitepaper from Smarthome Labs has to say about the CRC byte: "Message Integrity Byte The last field in an INSTEON message is a one-byte CRC, or Cyclic Redundancy Check. The INSTEON transmitting device computes the CRC over all the bytes in a message beginning with the From Address. INSTEON uses a software-implemented 7-bit linear-feedback shift register with taps at the two most-significant bits. The CRC covers 9 bytes for Standard messages and 23 bytes for Extended messages. An INSTEON receiving device computes its own CRC over the same message bytes as it receives them. If the message is corrupt, the receiver’s CRC will not match the transmitted CRC. Firmware in the INSTEON Engine handles the CRC byte automatically, appending it to messages that it sends, and comparing it within messages that it receives. Applications post messages to and receive messages from the INSTEON Engine without the CRC byte being appended. Detection of message integrity allows for highly reliable, verified communications. The INSTEON ACK/NAK (acknowledge, non-acknowledge) closed-loop messaging protocol based on this detection method is described below (see INSTEON Message Retrying)." This all sounds great on paper, but given the bit corruption that seems to plague everyday communications, it does not look like that integrity byte is being checked, at least by some devices. The problem here, from a claims verification and troubleshooting point of view, is that there is currently no way (that I know of) to see and independently verify that CRC byte, so we are at the mercy of whatever Smarthome Labs claims on their marketing and technical documents. If there was an INSTEON sniffer we could easily confirm whether devices (and what devices specifically) are checking the CRC byte, but I am not aware of anyone that has built an INSTEON sniffer. That would be awesome, and would give me a lot more confidence in the technology (as things are right now I've stopped investing in INSTEON, primarily because of these "unresolved" reliability issues). Another claim I've read in the technical documents from Smarhome Labs is that the INSTEON engine handles retransmissions (page 28 of the same whitepaper about, section "INSTEON Message Retrying"). Unless I am missing something, it seems to me like retransmissions are handled by the INSTEON stack, at least in the case of MisterHouse. Anyway, apologies for the long rant. Cheers, Eloy Paris.- |
From: Marc M. <ma...@me...> - 2011-08-20 15:16:41
|
On Thu, Aug 18, 2011 at 01:48:31PM -0400, Eloy Paris wrote: > > My hunch right now is that some insteon devices (like my older KPLs) do > > not implement CRC checking. > > Does anyone if the spec says either way? > > I agree, it does look like some devicesare not checking CRCs, and that, > if true, contradicts what the INSTEON technical documents say. My experience is that there is CRC checking for on/off/whatever commands, but not for link database updates. Then again, I have had unused KPL buttons that I've occasionally found lit when I don't have any way to control them and nothing is linked to them. > Another claim I've read in the technical documents from Smarhome Labs is > that the INSTEON engine handles retransmissions (page 28 of the same > whitepaper about, section "INSTEON Message Retrying"). Unless I am > missing something, it seems to me like retransmissions are handled by > the INSTEON stack, at least in the case of MisterHouse. Restransmissions are done in software with the PLM, but in hardware with switches. That part seems ok even if I wish I could control some buttons to retry more than once or twice. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Joel D. <jr...@pr...> - 2011-08-18 18:02:38
|
Remember too that CRC is an error CHECKING algorithm. All you can do when you get a bad result from a CRC check is send a NAK and wait for a retransmission. If the CFL is generating a lot of noise most, if not all of the subsequent messages will fail as well and the protocol will eventually time out. Unless you're seeing other devices switching apparently at random when a CFL is on, one might deduce that the Insteon receivers are in fact checking CRC and ignoring the corrupted messages. Does anyone know many retransmissions mh insteon stack supports? Upping that number might increase the odds of a message getting through successfully. Joel On Thu, 18 Aug 2011, it would appear that Eloy Paris wrote: > Hi Marc, > > On 08/18/2011 12:59 PM, Marc MERLIN wrote: > >> On Thu, Aug 18, 2011 at 10:57:51AM -0400, Eloy Paris wrote: >>> Hi list, >>> In http://misterhouse.wikispaces.com/Insteon, Marc has some comments on >>> CFLs, but I had not paid attention because I thought it was a discussion >>> on the use of CFLs with dimmers, which I don't have (all my CFLs are >>> controlled by relays). >> >> I can indeed reconfirm that CFLs do induce noise on my insteon bus, >> especially when they're on. > > :-( > >>> So, nothing new for the old-timers here, but definitely new to me, so I >>> thought I'd share the story for the benefit of those new to INSTEON and >>> to the list ;-) >>> >>> By the way, is anyone aware of a good solution to this problem? >> >> I'm very surprised that you're having noise with relays. The whole point >> of relays is to disconnect the load from your bus, and Smarthome does >> support CFLs with relays. >> If you can reproduce this, you may have an issue with the relays that >> you should talk to smarthome tech support about. >> >> Please keep up posted. > > I think what I am seeing makes sense -- I see no problems at all when > the light is off (I think because the CFLs are not energized and > therefore, cannot be generating noise). But then, when the light is on, > the CFLs are energized, and therefore, generating some noise that > affects INSTEON communications. > > But you are right, if they say that CFLs are supported with relays then > it'd be good to talk to them. I fear they'll put the blame on something > else, though. > > Here's another old discussion where someone experienced the same problem > I am experiencing: > > http://www.perceptiveautomation.com/userforum/viewtopic.php?t=1392 > >>> I also found this discussion that took place here, but that I didn't see >>> before because I was not subscribed to the list then: >>> >>> http://tech.groups.yahoo.com/group/misterhouse/message/39627 >> >> On this note, I'd love to know more. I still don't understand how this >> is possible since insteon is supposed to have CRCs which definitely >> protect against bit flips. > > Man, I am glad you bring this up again -- if there is something that I > really really *really* want to know about INSTEON is precisely that, > i.e. how is it possible that we are seeing this darn bit corruption if > there is a CRC byte that all devices are supposed to check, and then > discard the entire message if the CRC is incorrect. That just does not > seem to be happening. Otherwise we would not see so many corrupted link > tables in our devices. > > I wish someone had a good explanation for this. I have brought this > issue up many times before, a few times here, and even in the Smarthome > forum: > > http://www.smarthome.com/forum/topic.asp?TOPIC_ID=7006 > > (As you can see, nobody from Smarthome took interest, and there was no > resolution, and nobody answered the direct question of whether the CRC > byte is being checked.) > >> My hunch right now is that some insteon devices (like my older KPLs) do >> not implement CRC checking. >> Does anyone if the spec says either way? > > I agree, it does look like some devicesare not checking CRCs, and that, > if true, contradicts what the INSTEON technical documents say. > > This is what that "INSTEON: The Details" whitepaper from Smarthome Labs > has to say about the CRC byte: > > "Message Integrity Byte > > The last field in an INSTEON message is a one-byte CRC, or Cyclic > Redundancy Check. The INSTEON transmitting device computes the CRC over > all the bytes in a message beginning with the From Address. INSTEON uses > a software-implemented 7-bit linear-feedback shift register with taps > at the two most-significant bits. The CRC covers 9 bytes for Standard > messages and 23 bytes for Extended messages. An INSTEON receiving device > computes its own CRC over the same message bytes as it receives them. > If the message is corrupt, the receiver?s CRC will not match the > transmitted CRC. > > Firmware in the INSTEON Engine handles the CRC byte automatically, > appending it to messages that it sends, and comparing it within messages > that it receives. Applications post messages to and receive messages > from the INSTEON Engine without the CRC byte being appended. > > Detection of message integrity allows for highly reliable, verified > communications. The INSTEON ACK/NAK (acknowledge, non-acknowledge) > closed-loop messaging protocol based on this detection method is > described below (see INSTEON Message Retrying)." > > This all sounds great on paper, but given the bit corruption that seems > to plague everyday communications, it does not look like that integrity > byte is being checked, at least by some devices. > > The problem here, from a claims verification and troubleshooting point > of view, is that there is currently no way (that I know of) to see and > independently verify that CRC byte, so we are at the mercy of whatever > Smarthome Labs claims on their marketing and technical documents. If > there was an INSTEON sniffer we could easily confirm whether devices > (and what devices specifically) are checking the CRC byte, but I am not > aware of anyone that has built an INSTEON sniffer. That would be > awesome, and would give me a lot more confidence in the technology (as > things are right now I've stopped investing in INSTEON, primarily > because of these "unresolved" reliability issues). > > Another claim I've read in the technical documents from Smarhome Labs is > that the INSTEON engine handles retransmissions (page 28 of the same > whitepaper about, section "INSTEON Message Retrying"). Unless I am > missing something, it seems to me like retransmissions are handled by > the INSTEON stack, at least in the case of MisterHouse. > > Anyway, apologies for the long rant. > > Cheers, > > Eloy Paris.- > |
From: Eloy P. <pe...@ch...> - 2011-08-19 15:50:11
|
Hi Joel, On 08/18/2011 02:02 PM, Joel Davidson wrote: > Remember too that CRC is an error CHECKING algorithm. All you can > do when you get a bad result from a CRC check is send a NAK and wait > for a retransmission. If the CFL is generating a lot of noise most, > if not all of the subsequent messages will fail as well and the > protocol will eventually time out. If that's what is happening the I think the CRC is doing its job, i.e. sending a NAK (or even just silently dropping the message) when the CRC is bad is a good thing. The problem that some of us have seen, however, is that corrupted addresses are getting stored in devices' link tables, so we are questioning whether the CRC is being checked at all. Otherwise we cannot explain why this is happening. > Unless you're seeing other devices > switching apparently at random when a CFL is on, one might deduce that > the Insteon receivers are in fact checking CRC and ignoring the > corrupted messages. Nope, I have not seen other devices switching at random, so I think you have a good point -- when the CFL is on and you try to talk to the switch but the switch does not respond, it is possible that it is because the CRC is bad and the switch throws away the message. But that does not explain why we get corrupted addresses in the link tables, so I am at a loss. > Does anyone know many retransmissions mh insteon > stack supports? Upping that number might increase the odds of a > message getting through successfully. In the INSTEON branch it is five times by default, but can be changed by setting Insteon_retry_count in the .ini file. You can also adjust the delay between retransmissions. Cheers, Eloy Paris.- |
From: Marc M. <ma...@me...> - 2011-08-20 15:20:37
|
On Thu, Aug 18, 2011 at 01:02:27PM -0500, Joel Davidson wrote: > Remember too that CRC is an error CHECKING algorithm. All you can > do when you get a bad result from a CRC check is send a NAK and wait > for a retransmission. If the CFL is generating a lot of noise most, > if not all of the subsequent messages will fail as well and the > protocol will eventually time out. Unless you're seeing other devices > switching apparently at random when a CFL is on, one might deduce that > the Insteon receivers are in fact checking CRC and ignoring the > corrupted messages. Does anyone know many retransmissions mh insteon > stack supports? Upping that number might increase the odds of a > message getting through successfully. I've hacked the code to make retransmissions be an mh.ini param. It can be as many as you want. This does not help for a 2 way switch toggling the the other switch, or in my case another 4 or 5 KPL button lights, but it does help for mh to end device. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Carl M. <cmc...@co...> - 2011-08-19 13:02:21
|
I have several CFLs on Insteon Relay switches and have not experienced degradation in communications. You may find that choosing a different CFL, or perhaps different brand, will solve or improve your interference problem. On 08/18/2011 02:02 PM, Joel Davidson wrote: > Remember too that CRC is an error CHECKING algorithm. All you can > do when you get a bad result from a CRC check is send a NAK and wait > for a retransmission. If the CFL is generating a lot of noise most, > if not all of the subsequent messages will fail as well and the > protocol will eventually time out. Unless you're seeing other devices > switching apparently at random when a CFL is on, one might deduce that > the Insteon receivers are in fact checking CRC and ignoring the > corrupted messages. Does anyone know many retransmissions mh insteon > stack supports? Upping that number might increase the odds of a > message getting through successfully. > > Joel > > > > On Thu, 18 Aug 2011, it would appear that Eloy Paris wrote: > >> Hi Marc, >> >> On 08/18/2011 12:59 PM, Marc MERLIN wrote: >> >>> On Thu, Aug 18, 2011 at 10:57:51AM -0400, Eloy Paris wrote: >>>> Hi list, >>>> In http://misterhouse.wikispaces.com/Insteon, Marc has some comments on >>>> CFLs, but I had not paid attention because I thought it was a discussion >>>> on the use of CFLs with dimmers, which I don't have (all my CFLs are >>>> controlled by relays). >>> I can indeed reconfirm that CFLs do induce noise on my insteon bus, >>> especially when they're on. >> :-( >> >>>> So, nothing new for the old-timers here, but definitely new to me, so I >>>> thought I'd share the story for the benefit of those new to INSTEON and >>>> to the list ;-) >>>> >>>> By the way, is anyone aware of a good solution to this problem? >>> I'm very surprised that you're having noise with relays. The whole point >>> of relays is to disconnect the load from your bus, and Smarthome does >>> support CFLs with relays. >>> If you can reproduce this, you may have an issue with the relays that >>> you should talk to smarthome tech support about. >>> >>> Please keep up posted. >> I think what I am seeing makes sense -- I see no problems at all when >> the light is off (I think because the CFLs are not energized and >> therefore, cannot be generating noise). But then, when the light is on, >> the CFLs are energized, and therefore, generating some noise that >> affects INSTEON communications. >> >> But you are right, if they say that CFLs are supported with relays then >> it'd be good to talk to them. I fear they'll put the blame on something >> else, though. >> >> Here's another old discussion where someone experienced the same problem >> I am experiencing: >> >> http://www.perceptiveautomation.com/userforum/viewtopic.php?t=1392 >> >>>> I also found this discussion that took place here, but that I didn't see >>>> before because I was not subscribed to the list then: >>>> >>>> http://tech.groups.yahoo.com/group/misterhouse/message/39627 >>> On this note, I'd love to know more. I still don't understand how this >>> is possible since insteon is supposed to have CRCs which definitely >>> protect against bit flips. >> Man, I am glad you bring this up again -- if there is something that I >> really really *really* want to know about INSTEON is precisely that, >> i.e. how is it possible that we are seeing this darn bit corruption if >> there is a CRC byte that all devices are supposed to check, and then >> discard the entire message if the CRC is incorrect. That just does not >> seem to be happening. Otherwise we would not see so many corrupted link >> tables in our devices. >> >> I wish someone had a good explanation for this. I have brought this >> issue up many times before, a few times here, and even in the Smarthome >> forum: >> >> http://www.smarthome.com/forum/topic.asp?TOPIC_ID=7006 >> >> (As you can see, nobody from Smarthome took interest, and there was no >> resolution, and nobody answered the direct question of whether the CRC >> byte is being checked.) >> >>> My hunch right now is that some insteon devices (like my older KPLs) do >>> not implement CRC checking. >>> Does anyone if the spec says either way? >> I agree, it does look like some devicesare not checking CRCs, and that, >> if true, contradicts what the INSTEON technical documents say. >> >> This is what that "INSTEON: The Details" whitepaper from Smarthome Labs >> has to say about the CRC byte: >> >> "Message Integrity Byte >> >> The last field in an INSTEON message is a one-byte CRC, or Cyclic >> Redundancy Check. The INSTEON transmitting device computes the CRC over >> all the bytes in a message beginning with the From Address. INSTEON uses >> a software-implemented 7-bit linear-feedback shift register with taps >> at the two most-significant bits. The CRC covers 9 bytes for Standard >> messages and 23 bytes for Extended messages. An INSTEON receiving device >> computes its own CRC over the same message bytes as it receives them. >> If the message is corrupt, the receiver?s CRC will not match the >> transmitted CRC. >> >> Firmware in the INSTEON Engine handles the CRC byte automatically, >> appending it to messages that it sends, and comparing it within messages >> that it receives. Applications post messages to and receive messages >> from the INSTEON Engine without the CRC byte being appended. >> >> Detection of message integrity allows for highly reliable, verified >> communications. The INSTEON ACK/NAK (acknowledge, non-acknowledge) >> closed-loop messaging protocol based on this detection method is >> described below (see INSTEON Message Retrying)." >> >> This all sounds great on paper, but given the bit corruption that seems >> to plague everyday communications, it does not look like that integrity >> byte is being checked, at least by some devices. >> >> The problem here, from a claims verification and troubleshooting point >> of view, is that there is currently no way (that I know of) to see and >> independently verify that CRC byte, so we are at the mercy of whatever >> Smarthome Labs claims on their marketing and technical documents. If >> there was an INSTEON sniffer we could easily confirm whether devices >> (and what devices specifically) are checking the CRC byte, but I am not >> aware of anyone that has built an INSTEON sniffer. That would be >> awesome, and would give me a lot more confidence in the technology (as >> things are right now I've stopped investing in INSTEON, primarily >> because of these "unresolved" reliability issues). >> >> Another claim I've read in the technical documents from Smarhome Labs is >> that the INSTEON engine handles retransmissions (page 28 of the same >> whitepaper about, section "INSTEON Message Retrying"). Unless I am >> missing something, it seems to me like retransmissions are handled by >> the INSTEON stack, at least in the case of MisterHouse. >> >> Anyway, apologies for the long rant. >> >> Cheers, >> >> Eloy Paris.- >> > ------------------------------------------------------------------------------ > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, > user administration capabilities and model configuration. Take > the hassle out of deploying and managing Subversion and the > tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > > |
From: Jim S. <js...@sy...> - 2011-08-19 13:46:37
|
I can confirm that there is a huge difference in brands of CFL and even LED lamps depending on the design of the switching supply in the bulb - cheaper is usually but not always worse. Dimmable ones seem to be a little better in managing the noise injection. I have not look at this in terms of INSTEON noise but in terms of the general power line noise. Also as the CFL nears end of life (at least in some cases) seems to get worse. Jim -----Original Message----- From: Carl McGrath [mailto:cmc...@co...] Sent: August 19, 2011 9:02 AM To: The main list for the MisterHouse home automation program Subject: Re: [mh] CFLs introduce noise that affect INSTEON communications I have several CFLs on Insteon Relay switches and have not experienced degradation in communications. You may find that choosing a different CFL, or perhaps different brand, will solve or improve your interference problem. On 08/18/2011 02:02 PM, Joel Davidson wrote: > Remember too that CRC is an error CHECKING algorithm. All you can > do when you get a bad result from a CRC check is send a NAK and wait > for a retransmission. If the CFL is generating a lot of noise most, > if not all of the subsequent messages will fail as well and the > protocol will eventually time out. Unless you're seeing other devices > switching apparently at random when a CFL is on, one might deduce that > the Insteon receivers are in fact checking CRC and ignoring the > corrupted messages. Does anyone know many retransmissions mh insteon > stack supports? Upping that number might increase the odds of a > message getting through successfully. > > Joel > > > > On Thu, 18 Aug 2011, it would appear that Eloy Paris wrote: > >> Hi Marc, >> >> On 08/18/2011 12:59 PM, Marc MERLIN wrote: >> >>> On Thu, Aug 18, 2011 at 10:57:51AM -0400, Eloy Paris wrote: >>>> Hi list, >>>> In http://misterhouse.wikispaces.com/Insteon, Marc has some comments on >>>> CFLs, but I had not paid attention because I thought it was a discussion >>>> on the use of CFLs with dimmers, which I don't have (all my CFLs are >>>> controlled by relays). >>> I can indeed reconfirm that CFLs do induce noise on my insteon bus, >>> especially when they're on. >> :-( >> >>>> So, nothing new for the old-timers here, but definitely new to me, so I >>>> thought I'd share the story for the benefit of those new to INSTEON and >>>> to the list ;-) >>>> >>>> By the way, is anyone aware of a good solution to this problem? >>> I'm very surprised that you're having noise with relays. The whole point >>> of relays is to disconnect the load from your bus, and Smarthome does >>> support CFLs with relays. >>> If you can reproduce this, you may have an issue with the relays that >>> you should talk to smarthome tech support about. >>> >>> Please keep up posted. >> I think what I am seeing makes sense -- I see no problems at all when >> the light is off (I think because the CFLs are not energized and >> therefore, cannot be generating noise). But then, when the light is on, >> the CFLs are energized, and therefore, generating some noise that >> affects INSTEON communications. >> >> But you are right, if they say that CFLs are supported with relays then >> it'd be good to talk to them. I fear they'll put the blame on something >> else, though. >> >> Here's another old discussion where someone experienced the same problem >> I am experiencing: >> >> http://www.perceptiveautomation.com/userforum/viewtopic.php?t=1392 >> >>>> I also found this discussion that took place here, but that I didn't see >>>> before because I was not subscribed to the list then: >>>> >>>> http://tech.groups.yahoo.com/group/misterhouse/message/39627 >>> On this note, I'd love to know more. I still don't understand how this >>> is possible since insteon is supposed to have CRCs which definitely >>> protect against bit flips. >> Man, I am glad you bring this up again -- if there is something that I >> really really *really* want to know about INSTEON is precisely that, >> i.e. how is it possible that we are seeing this darn bit corruption if >> there is a CRC byte that all devices are supposed to check, and then >> discard the entire message if the CRC is incorrect. That just does not >> seem to be happening. Otherwise we would not see so many corrupted link >> tables in our devices. >> >> I wish someone had a good explanation for this. I have brought this >> issue up many times before, a few times here, and even in the Smarthome >> forum: >> >> http://www.smarthome.com/forum/topic.asp?TOPIC_ID=7006 >> >> (As you can see, nobody from Smarthome took interest, and there was no >> resolution, and nobody answered the direct question of whether the CRC >> byte is being checked.) >> >>> My hunch right now is that some insteon devices (like my older KPLs) do >>> not implement CRC checking. >>> Does anyone if the spec says either way? >> I agree, it does look like some devicesare not checking CRCs, and that, >> if true, contradicts what the INSTEON technical documents say. >> >> This is what that "INSTEON: The Details" whitepaper from Smarthome Labs >> has to say about the CRC byte: >> >> "Message Integrity Byte >> >> The last field in an INSTEON message is a one-byte CRC, or Cyclic >> Redundancy Check. The INSTEON transmitting device computes the CRC over >> all the bytes in a message beginning with the From Address. INSTEON uses >> a software-implemented 7-bit linear-feedback shift register with taps >> at the two most-significant bits. The CRC covers 9 bytes for Standard >> messages and 23 bytes for Extended messages. An INSTEON receiving device >> computes its own CRC over the same message bytes as it receives them. >> If the message is corrupt, the receiver?s CRC will not match the >> transmitted CRC. >> >> Firmware in the INSTEON Engine handles the CRC byte automatically, >> appending it to messages that it sends, and comparing it within messages >> that it receives. Applications post messages to and receive messages >> from the INSTEON Engine without the CRC byte being appended. >> >> Detection of message integrity allows for highly reliable, verified >> communications. The INSTEON ACK/NAK (acknowledge, non-acknowledge) >> closed-loop messaging protocol based on this detection method is >> described below (see INSTEON Message Retrying)." >> >> This all sounds great on paper, but given the bit corruption that seems >> to plague everyday communications, it does not look like that integrity >> byte is being checked, at least by some devices. >> >> The problem here, from a claims verification and troubleshooting point >> of view, is that there is currently no way (that I know of) to see and >> independently verify that CRC byte, so we are at the mercy of whatever >> Smarthome Labs claims on their marketing and technical documents. If >> there was an INSTEON sniffer we could easily confirm whether devices >> (and what devices specifically) are checking the CRC byte, but I am not >> aware of anyone that has built an INSTEON sniffer. That would be >> awesome, and would give me a lot more confidence in the technology (as >> things are right now I've stopped investing in INSTEON, primarily >> because of these "unresolved" reliability issues). >> >> Another claim I've read in the technical documents from Smarhome Labs is >> that the INSTEON engine handles retransmissions (page 28 of the same >> whitepaper about, section "INSTEON Message Retrying"). Unless I am >> missing something, it seems to me like retransmissions are handled by >> the INSTEON stack, at least in the case of MisterHouse. >> >> Anyway, apologies for the long rant. >> >> Cheers, >> >> Eloy Paris.- >> > ---------------------------------------------------------------------------- -- > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, > user administration capabilities and model configuration. Take > the hassle out of deploying and managing Subversion and the > tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > > ---------------------------------------------------------------------------- -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ________________________________________________________ To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 |
From: Eloy P. <pe...@ch...> - 2011-08-19 14:48:09
|
Hi Carl, On 08/19/2011 09:02 AM, Carl McGrath wrote: > I have several CFLs on Insteon Relay switches and have not experienced > degradation in communications. > > You may find that choosing a different CFL, or perhaps different brand, > will solve or improve your interference problem. Yes, it's very possible that different brands or models of CFLs behave different (worse or better). At least that's what I've read in many different places online. In my case, it was just plain *obvious* that the CFLs are at fault, even when the are getting controlled by relays instead of dimmers. Cheers, Eloy Paris.- |
From: Eloy P. <pe...@ch...> - 2011-08-19 14:58:05
|
On 08/19/2011 10:47 AM, Eloy Paris wrote: > Hi Carl, > > On 08/19/2011 09:02 AM, Carl McGrath wrote: > >> I have several CFLs on Insteon Relay switches and have not experienced >> degradation in communications. >> >> You may find that choosing a different CFL, or perhaps different brand, >> will solve or improve your interference problem. > > Yes, it's very possible that different brands or models of CFLs behave > different (worse or better). At least that's what I've read in many > different places online. > > In my case, it was just plain *obvious* that the CFLs are at fault, even > when the are getting controlled by relays instead of dimmers. By the way, I must point out that I have other CFLs being controlled by other INSTEON relay switches and they don't have issues. The issue of noise introduced by CFLs seems to be exacerbated by the following factors: - The number of CFLs in the light fixture. For instance, in the particular case of the light fixture I found to be affected by CFL-generated noise, the light fixture has three CFLs. I notice that when all three CFLs are on, communications are close to 100% unreliable, i.e. messages from the PLM not getting to the switch controlling the light fixture. When I leave two CFLs, communications improve a bit, and when I leave only one CFL then things work like 90% of the time. (With incandescent light bulbs things work 100% of the time.) - Whether the switch is on the AC phase opposite to where the PLM is, i.e. traffic must go through an access point -- this is just a hunch on my side and I could be wrong, but this particular troublesome switch is not on the same phase as the PLM, and most of the other switches that control CFLs and are not having problems are on the same phase as the PLM. (Guess I can move the PLM to the same phase the troublesome switch is in and try to confirm.) Cheers, Eloy Paris.- |
From: Serge M. <sm...@vi...> - 2011-08-19 17:22:10
|
<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#3333FF"> Eloy,<br> <br> I am fairly to Insteon, but <i>some</i> CFL were a big problem to my X10 reliability. I sucessfully fixed it by adding an RF choke of 1000uH in series with the hot wire in the light socket. Et Voila, problem fixed! . It is worth the try, here is the digikey number I used: M8275-ND. $1.72 a piece...pretty cheap to try!!<br> <br> Good luck<br> Serge<br> <br> Le 2011-08-18 10:57, Eloy Paris a écrit : <blockquote cite="mid:4E4...@ch..." type="cite"> <pre wrap=""> By the way, is anyone aware of a good solution to this problem? Cheers, Eloy Paris.- </pre> </blockquote> </body> </html> |
From: Eloy P. <pe...@ch...> - 2011-08-19 17:35:11
|
Hi Serge, On 08/19/2011 01:21 PM, Serge Martel wrote: > Eloy, > > I am fairly to Insteon, but /some/ CFL were a big problem to my X10 > reliability. I sucessfully fixed it by adding an RF choke of 1000uH in > series with the hot wire in the light socket. Et Voila, problem fixed! . > It is worth the try, here is the digikey number I used: M8275-ND. $1.72 > a piece...pretty cheap to try!! Great; thanks for the good info. Definitely very cheap to try! I'll try to include this in my next Digikey purchase, whenever that might be. Cheers, Eloy Paris.- > Le 2011-08-18 10:57, Eloy Paris a écrit : >> >> By the way, is anyone aware of a good solution to this problem? >> >> Cheers, >> >> Eloy Paris.- >> |
From: Joel D. <jr...@pr...> - 2011-08-19 18:28:52
|
That sounds like a decent solution, but be careful you don't overload that choke as it's only got a current rating of 1A. Should be fine as long as you only put CFL's in that fixture. On Fri, 19 Aug 2011, it would appear that Serge Martel wrote: > Eloy, > > I am fairly to Insteon, but some CFL were a big problem to my X10 > reliability. I sucessfully fixed it by adding an RF choke of 1000uH in > series with the hot wire in the light socket. Et Voila, problem fixed! . It > is worth the try, here is the digikey number I used: M8275-ND. $1.72 a > piece...pretty cheap to try!! > > Good luck > Serge > > Le 2011-08-18 10:57, Eloy Paris a ecrit : > > > By the way, is anyone aware of a good solution to this problem? > > Cheers, > > Eloy Paris.- |