Our product, the RUC-01, has been mentioned a few times in this thread, so I’d like to provide a little more detail about the philosophy behind the RUC and what we think it is best at. The intention of the RUC was not, at least initially, to be a replacement for something like HomeSeer, or even MiLightStyle. We were not trying to build a new all encompassing controller. Being UPB guys and working with many UPB dealers and installers, there are several main issues we were trying to resolve.
First, installers told us that installing UPB devices was painful from a programming standpoint. In a typical home, they would have to move their laptop and PIM many times to be close to the next switch they were programming. With the RUC, they install the RUC and its PIM in a desirable location, such as close to the breaker box, then they use their laptops on a wireless network and easily move around the house programming the devices. We have some installers who buy RUCs just for that purpose.
Secondly, we were also told by installers that it was painful when a client called them up and asked them to change the programming on their UPB network. They would have to do a truck roll. Instead, now with the RUC, they can log in remotely, using Upstart and make the changes from the desktop in their office. In fact, several installers do the barest minimum they can get away with at the actual site, then go back to their office and do the link programming there, rather than at the client’s location.
Thirdly, even in the smallest and simplest of installations, there is always a desire for scheduling. Having the internet connection means we provide a very accurate scheduler in the RUC and we can track sunset and sunrise daily.
Fourth, we also get requests from folks saying I merely want to control drapes at the same time I control my lights – how do I do that? With two serial ports, we provide conversions between protocols, so as an example it is very easy to detect a UPB link and send out a serial command to control an ESI motor controller. With these two serial ports, it is easy to trigger events for one protocol from another protocol.
We also wanted to offer a low cost device that could be used for email origination to offer timely alerts when exceptional conditions arise and we wanted to answer the need many installers have for providing simple but functional lighting control options from smartphones. The RUC provides email alerts and a variety of smartphone interfaces.
Another way to use the RUC is as an Ethernet PIM. For example, if you are running PC based automation software and don’t have a dedicated controller, install the RUC and its PIM close to the breaker box and then setup the controller to send commands over Ethernet. Now you don’t have to connect a PIM to a serial port of your desktop and try to find an outlet without a UPS on it. Additionally, you don’t have to have the PC running 24x7, as you can do the scheduling within the RUC.
One other thing that many of our dealers appreciate is the ability to turn any device running under any of the protocols we support into a count-down timer or to daisy chain commands from one device to another, hopping protocols if so desired.
We differ in philosophy from the MiLightStyel and PC-based controllers in believing that the very best tool for setup, trouble-shooting and tinkering with your UPB network is UPStart. Many controller vendors have learned that trying to keep up with all the changes in the UPB world is a daunting task. So, why not just find a way to use Upstart? Upstart is always up to date with new products, is very stable and reliable, and provides more monitoring and diagnostic tools than any other controller we’ve seen. While a controller manufacturer can attempt to perform the functions of Upstart, our position is that they will always be out of date and never up to speed with Upstart.
In this thread there are several comments about showing status. Right now, the RUC will not show any status. While we have simple user interfaces for browser and smartphone access, we don’t show status from them (the paid iPhone app done by a third party does show status). Our product roadmap does have an item on it for us to provide status and we have thought a lot about this and have an approach we will try. But status in any reasonably large installation, no matter the protocol, can be problematic. How will constant polling and/or heavy device response traffic affect the control commands that happen spontaneously but are vitally important to the system’s reliability? Despite the inherent problems, we will be tackling status in a future release.
I hope this gives a better understanding of the features and perceived shortcomings of the RUC-01. We’re always open to questions and suggestions – please visit our web site to contact us.