Lutron and Multicast - Constant Source of Irritation - Time to Request a Solution!
Starting in the 80's I was involved in various projects that employed Arpanet protocols which have become Internet protocols or IP. Today I spent 4 hours with a network analyzer trying to discover what is going on with Lutron. At the heart of the matter is their desire to NOT rely on static IP configuration for anything. If the network specifications were published (and I do recall an excellent document on why, for lighting control they decided to use their own bandwidth rather than wifi or god forbid X10) that defined how the IP portion of RadioRA2 should work, I would expect to see something where there is a requirement for a constant state of discovery independent of IP addresses so the Essentials software could easily program the Repeaters IP address. Noble. The reality is you cannot always design the repeater and Essentials (and the Connect product) to be on the same Network. Getting them on the same IP range AND the same ethernet segment should NOT be a requirement. Currently, with the basic absolute demand for Multicast the only reliable method of configuration is putting the 3 control components on the same network AND the same segment (or in network speak - Link Layer). I watched the traffic on both sides of the Verizon G3100 today (which will be their defacto FIOS box) and none of the multicastV3 packets EVER made it to the other segments. I did configure their implementation of IGMP, as well as implementing port forwarding in the published (by Lutron) ports that they wanted forwarded to either side......nothing! So, once again, as I have been since the 80's stuck between vendors, Verizon is solid at what they do, Lutron is as well. The two together generate long, frustrating days. If anyone from Lutron is reading this, here is what you could do:Walk over to the engineering departmentGet someone that is in the networking department - might be just one guy?Ask him/her to write a complete, with engineering detail, description as to what Lutron is trying to accomplish with Multicast and all of the various methods one might employ (are their hidden configs? Could we dumb it down to use IP addresses only?) Frustrated in Boston!If anyone is interested, I can forward some packet captures.
Static IP addresses DO NOT diminish the reliance on Multicast
When you program (enter) a static address, the device with which you are trying to change is not changed until you SAVE the entry. This stated, the save function starts a multicast broadcast. The logic you infer would work. I KNOW where I want to go, and I can PING (ICMP) that address, so send the TCP session there. This is not what they do - the IP addresses are established ONLY if the session can be first established with multicast (and I am guessing since I am still unsure as to their internal logic). Right now, you can PING all of the devices and NOT be able to see them with the PC software (Essentials) AND if the Connect and Main_Repeater can also be pinged - if they cannot pass multicast between them, they will not work together. Absolutely maddening.
Quote:
Originally Posted by
randyc
Both RadioRA 2 and HomeWorks QS allow use of static IP address. In HQS, under activate processor, click "System Communication"In RadioRA 2, click on "find main repeater" then click "show advanced"I'm not sure why Lutron likes multicast. They do market to a variety of dealers, many of whom don't have network engineers or offer network services.
Not sure why formating in this board is a problem - my apologies for being a NUBE
BTW, I wrote the above with formating in place which the editor on this board provided. Once it was posted the formating went away and the post is a glob of text. Apologies.
