I was called to fix some things in a house with 2 QS processors where the last guy had given up extracting the programming so I knew it would be a challenge. I connected via ethernet to the network and did an ip scan and could not even find the processors returning a ping. I usually do this and then open up a web browser to see the version of the firmware so i know what I'm dealing with. Fortunately, since both of the processors were 2 link processors and there was an open ethernet port, connected my cable to that since I've found it works better with communication and avoids some restrictions the router may have put on the network and through that attempted to extract the programming. I was using version 15.10 but again, fortunately, the software told me that the existing processors were 12.4 and it could not do it so I installed 12.4 and WAS able to extract the programming! I was happy because it seems like a dark art to do an extraction sometimes.
Once I looked at the extracted database, it could not find the processors and it was set up for static IP address of 10.0.1.x whereas the actual networking was set up for 192.168.4.x with a subnet of 255.255.252.0 so of course the little it was giving a subnet error.
After verifying that there were no other integrations in the house, I tried changing the networking to DHCP and only one of the processors accepted this and showed "ready". So this is where the dark art comes in. I manually changed the IP address, gateway, and other settings on that and it still would not change, but I noticed that if I did an ip address scan, the two processors WERE showing up on the network. So I just power cycled the processors and at that point, the DHCP on the one processor and the manual IP address on the other processor (the one that was not working) was showing ready. So I changed them all to DHCP. The connect bridge was always on DHCP so I kept that alone.
After that, I was able to make my changes and even got brave enough to update the firmware to 15.10 and re-activate the connect bridge. So I have a few questions because I seem to be the one who goes in after other people and every time I'm able to extract the programming, it seems like it was a small miracle and I was NOT in control of how things were going:
- Why on earth did Lutron ask us to use static IP addresses as "best practices" in their networking guide? I know that if you have a Crestron system or something similar, then yes you need a static ip address but I would say that 90% of the issues I have is a new homeowner buys a system they know nothing about, they change their network to something else, and then the processors don't show up. If you leave it on DHCP, it will be self adapting to whatever network they throw at it. So why on god's grit eating earth would you encourage people to use a static IP address? Every system I've left on DHCP in the last 5 years (after coming to my senses) still works perfectly. I go to the house after 3 years, I connect to the network and "yup, there it is!"...It just works. Why make things complicated?
- How was this system even working where the connect bridge was on DHCP and connected to the network correctly and the processors had a completely different subnet? Are the processors that smart to still find a way to communicate? Did the router still give the two lutron processors a correct IP address even though they thought they were something else? Did the connect bridge use multicast to find them and still send commands via 10.0.1.x and the router still passed it through?
- How would you approach this type of situation?