Originally Posted by desmolift
No documentation is annoying! I appreciate any help or experimenting. I am trying to learn as much as possible before the installers return to continue debugging these issues. Over the phone they implied that HD told them to install the Hub/Bridge to see if it fixes the problems on the assumption the Hub/Bridge has a stronger signal. But I am suspicious about that response based on this discussion, and it won't fix the remote. I believe the shades only respond to RF. The remotes and the Hub must speak the same RF so they can both control the shades. I would also agree that the remote and the Hub are independent of each other, basically providing the same functions; controlling the shades. Unfortunately, I'm not sure how the repeaters work. I was thinking they just repeated the RF signal received, but you said LED lights don't light on the repeater when using the remote, and they do with the HUB, so something different is going on there. I'd love to talk to one of the HD engineers on this.....
After going a little deeper on this, I found and read the operator manuals for the remote, scene controller, repeater, hub and app. The shades themselves appear much more intelligent than I had thought. They respond to commands for discovery, position, etc. The best way to think of this is, the remote, hub, repeater and shades are on a wireless network all potentially communicating with each other. The repeater must act just like a wifi repeater, simply extending the network. So, if the shade drops a packet of information for some reason like it missed it's address match or had data errors, it wouldn't matter if it originated from the remote or the hub. Causing the same failure symptoms. This would possibly also explain why the shades go unresponsive requiring a power reset, because of bugs in the shade. When I see this unresponsive failure, the manual button stops working, ie. the shade crashed. I suppose this could also be a hardware failure. There must be a small micro and firmware in the shade. If so, can it be updated.......
Update: For those interested in more detail. I spoke to level 3 support at HD this morning. I have confirmed with HD that others have seen the unreliability of the RF signal. Their explanation is RF interference. Not that satisfying. As for the unresponsive shade issue, they claim they are unaware of this problem. (but are now as of 5/2/16!) HD said that until the shades work reliably with the remote, they are not likely to work reliably with the Hub. The recommendation for the RF reliability issue is to add repeaters. Although, HD says the repeater does not have a stronger signal than the remote, but that the repeater is repeating the signal. So if the shade misses the signal from the remote, it can get it from the repeater. All sounds like a kludgy workaround, what if the repeater misses the signal, or the shade misses the signal twice. The remote, Hub, shade, repeater etc. are all on the same RF network, so the remote does work with the repeater, you do not need the hub. I was told the firmware within the shade was last updated in January of 2016. This firmware can not be updated in the field, its a motor swap to get the newer firmware. HD is looking into the non-responsive issue with the Engineers and will update me at a later date. I plan to get the installers back, and attempt adding just the repeaters to see if things improve.
As a side note, my 2 cents. The RF network is by definition using an unreliable media, that is, RF. For communication to/from the shade to be reliable, you must run a reliable protocol over the unreliable media. If this is not the case, the shades will always have the potential to miss commands and instructions.
Update: I have verified with HD, they do not use a reliable protocol between the shade and the Remote. The shade is programmed to respond to a Remote ID & Group ID, the remote broadcasts the command, the shade(s) receives it and executes the command. There is no acknowledgement. So the only way to make this reliable, is to have the shade reliably receive the command the first time every time. HD has been very pro-active on debugging these issue, attempting to reproduce the issues in their labs. I'll report the results back as they unfold.