I will. Have you seen the prices for those switches? What were they thinking? UPB gives you the choice of several different manufacturers at half the price. Shows you what a little competition can do.pete_c said:I am not knocking Lutron here. The company does wireless automation good.
This is absolutely possible with Total Control and Dash OS. The logic is all handled by the MRX, the Total Control unit. Once motion detects, it follows the logic configured in the Dash OS Lutron module (sofware).wkearney99 said:Now, it's not all roses, I'd dearly love for Lutron to introduce time-ranged dimmer levels for motion sensor commands. As in, don't bring up the master bedroom closet lights to 100% if it's after 10pm. Just that one simple thing would wrap up my only compelling reason to get more automation integration with my RA2 gear. But no way I'd want to do this if it in any way compromised the fantastically quick response time I get now. I know why it can't, as the motion sensor doesn't really speak to the repeater, but to the associated dimmers themselves. Yes, the repeater 'sees' the motion commands, but it's the switches that handle things directly.
Anyway, not to rain on the OP's parade, but I'm guessing there's a lot more work than practical in trying to get his existing UPB devices to do what he's after.
Agreed, on what slows it down. However, it COULD be fast with the right controller (Total Control) as it detects the Lutron sensors CRAZY fast and executes commands pretty much instantly. Definitely acceptable.cobra said:I don't think UPB limits you here...
I use motion sensors and UPB to run a nightlight 'scene' here. The slow side isn't UPB for me, it's the motion sensor, security system, to home controller link that takes a couple seconds.
I'd think you would get very fast response in your case. The RadioRA sensors can be hooked to something like a HAI Lumina / Omni system, that would make the motion/occupancy status very fast, I would think. Sending of UPB commands is fast for single lights or links, it all depends on how you setup the layout. You only have a problem if you take something fast like your occupancy sensors and then try to send 10s of UPB light commands all at once. That's just bad design / programming...
BobS0327 said:I'm currently in the process of decommissioning a really old controller. As part of that process, I had to develop an alternative for controlling my UPB devices. So, I decided to write a software UPB gateway which is essentially a back end server to process UPB commands.
Ranger Digital said:Agreed, on what slows it down. However, it COULD be fast with the right controller (Total Control) as it detects the Lutron sensors CRAZY fast and executes commands pretty much instantly. Definitely acceptable.
Correct, it currently doesnt work. But COULD if we had a module or a way of getting the info via TC WITHOUT using the HAI. I agree, its the HAI side that slows it down, WAY down. HAI is SLOW. it can take four or five seconds sometimes just to turn a light on with even the actual command written in the remote control. Not acceptable of course. UPB on its own is CRAZY fast. Love that part lol.cobra said:Hmm, no, if Total Control doesn't have access to the light states, then that presently doesn't work.
But you can get light states on the HAI side, and you can get RadioRA status as well, can't you?
It seems like you think the HAI control side is the slow side, not the motion sensor inputs?
I was saying that with fast RadioRA sensors, the HAI control would be fast as well.
I've been using HAI for years and never experienced that delay. You might have an unintentional loop, like where X -> Y, and Y -> Z, then Z -> X. For HAI this doesn't freeze it, but it very much slows it like you describe. I've never seen HAI response slower than 100ms with 750 lines of programming.Ranger Digital said:Correct, it currently doesnt work. But COULD if we had a module or a way of getting the info via TC WITHOUT using the HAI. I agree, its the HAI side that slows it down, WAY down. HAI is SLOW. it can take four or five seconds sometimes just to turn a light on with even the actual command written in the remote control. Not acceptable of course. UPB on its own is CRAZY fast. Love that part lol.
Ranger Digital said:Correct, it currently doesnt work. But COULD if we had a module or a way of getting the info via TC WITHOUT using the HAI. I agree, its the HAI side that slows it down, WAY down. HAI is SLOW. it can take four or five seconds sometimes just to turn a light on with even the actual command written in the remote control. Not acceptable of course. UPB on its own is CRAZY fast. Love that part lol.
And when i say 100ms, I'm ONLY counting HAI time. Yes outside devices take a bit to report to the panel, and certainly technology like UPB take time to set a switch. All of these times can add up together, but its not the panel at fault. For example I use wireless motion detectors. The instant they trip they wait a bit to transmit. Then they transmit, and the receiver reads it twice to verify it. next the receiver has to send it serially to the panel. Panel figures it out then serially sends it to a UPB PIM. PIM transmits and switch has to react to it. From one end to the other it could be 2 or 3 seconds, and everyone assumes that the panel is slow, but its not.ano said:I've been using HAI for years and never experienced that delay. You might have an unintentional loop, like where X -> Y, and Y -> Z, then Z -> X. For HAI this doesn't freeze it, but it very much slows it like you describe. I've never seen HAI response slower than 100ms with 750 lines of programming.
UPB seems to be WAY behind todays technology. Has querying changed? What I mean, is there a way to INSTANTLY query the state of any UPB device and take that query to execute macros from another control system. Example, as a URC Total Control dealer, we need to be able to INSTANTLY query the state of a UPB switch, use that query as part of a macro in the URC programming: Check the status of a light, if its on do "this". If its off do "this".
It has been my experience that sending a UPB Get Status request to any device requires a minimum of a four second delay between initially sending the request and finally receiving a response. If you try to send another request to another device within that time frame, the packets will most probably collide causing the packet you sent to fail and the packet you expect to receive to just disappear. I have also discussed this issue with PCS Lighting tech support. They also highly recommended to only send one packet and then wait for a response prior to sending another packet. IOW, minimize the powerline traffic.
So, my software approach to getting an INSTANT status update is to poll all my UPB devices on initial startup of my app. After which, my app would continuously “sniff” the power line for UPB packets. If a “sniffed” packet indicates that a UPB device was dimmed to a certain level, the app would immediately update the database according. With my app, I can now get INSTANT status update of any of my switches by querying the database via a web browser. The app INSTANTLY returns a JSON string with the current status of the switch.
So, IMHO, it's not so much the protocol that is the issue but rather how you adapt the protocol to meet your specific needs.
Not much of this would be attached to HAI. Total Control is way more powerful and has so much more flexibility. Not to mention no clunky, large automation blocks to filter through. WAY more efficient to let TC handle the logic. Currently, TC comminicates directly with UPB, I dont use my HAI to handle the UPB logic, aside from scenes that activate based on alarm status. My biggest problem is TC doesnt know the status of the lights. While this is a worthless endeavor for some, its detrimental for our company and could mean the end of using UPB.