Is UPB able to be queried? Like Lutron

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". 
 
Lutron allows this and its INSTANT. While UPB is VERY stable and inexpensive, its VERY limited in this regard. Has this changed? There has to be a way as HAI gets the status of the lights in their app. Has another manufacturer offered a module or device that allows this type of communication? THere are a couple IP modules, Web Mountain, PCS, etc, but Im not finding they have the capability of getting the status and using that info to put into a control system. 
 
Hopefully its possible and I just havent learned how its done yet. 

Are you comparing to RadioRA from Lutron?
 
Often in UPB the controller maintains status of devices on the network for fast response.  UPB does support querying of devices as well.  Nothing is really instant though, so you have to determine what your response time needs to be.  A few hundred mS probably won't bother users, but as you approach a second, users start to notice.

I'm not sure its fair to compare a radio technology to a powerline technology for speed. Powerline transmissions are fairly low speed. If you use HLC with an Omni controller, most status should be correct because the controller will poll switches after a link is sent.  Switches can also report status changes, but that is'nt required with HLC.

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.
 
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.
 
My Java UPB gateway (back end server) project is on github.  https://github.com/BobS0327/upbserver
 

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.
 
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.
 
My Java UPB gateway (back end server) project is on github.  https://github.com/BobS0327/upbserver

Click to expand...

Sounds good, but how do you handle links? As you know a single link can change the state of every switch. Most switches can process requests from 16 links. Your sniffer can see the links, but then what?  Do you maintain a table of all 16 states for every link a switch can process?  Then when you change a setting in a switch, how do you make sure the table matches?
 
Personally I think people get too obsessed with having to know the state of every switch. Switches can transmit their status when you switch them. That is all you usually need.

I don't recall the specifics but I believe Lutron holds some patents on lighting status.

ano said:

Personally I think people get too obsessed with having to know the state of every switch. Switches can transmit their status when you switch them. That is all you usually need.

Click to expand...

 
I don't disagree with the notion that being up-to-the-second informed isn't necessary.  As in, there's lots of devices (likely most) that you really don't need to know a damned thing about until you send them some kind of 'large scale' commands.  
 
As in "I'm coming/going-- deal with the lights".  Various tech has meant "deal with the lights" could be a problem.  Lutron (iirc) gets around this by the devices themselves being reasonably smart and clued-into using larger group commands instead of one-at-a-time lighting instructions.  
 
Now, I'm not claiming any one brand does it better, nor calling out any others for being bad at it.  Barring X-10, that was just too fucked up for words, but hey, it was the 80's....
 
Still, there really are a lot of scenarios where having a "live" overview of ALL the automation devices present has potential.  Not just for feel-good excuses like energy management.  That's laudable, but never really gets implemented or used effectively.  No, tying together a lot of usage data does present the possibility of more nuanced rule building and resulting interaction.  
 
But let me toss it back to the OP, what're you envisioning that would require that kind of status?

ano said:

Sounds good, but how do you handle links? Do you maintain a table of all 16 states for every link a switch can process? 

Click to expand...

 
Elan g! does just that. You either read in the export file from UPStart or have the controller scan all the UPB devices.
 
If you create a on-screen "push-button" object that sends a link, that push-button will be highlighted if all of the devices that respond to that link end up in the correct state.
 
If any of the devices change to a different "incorrect" state the push-button will no longer be highlighted.

Sounds good, but how do you handle links? As you know a single link can change the state of every switch. Most switches can process requests from 16 links. Your sniffer can see the links, but then what?  Do you maintain a table of all 16 states for every link a switch can process?  Then when you change a setting in a switch, how do you make sure the table matches?

Click to expand...

 
Again, I try to avoid putting any packets on the powerline. Handling links is done by using the Upstart export file.  This export file is used as input for creating a database table of presets.  The export file will have all 16 presets for each UPB device  The export preset record will have the following format:
 
Preset record (4)
 Channel # (0 = channel 1, 1 = channel 2, etc)
 Component # (First component is zero)
 Module id
 Link id
 Preset dim level
 Preset dim fade rate
 
Thus, we search the preset database table on Link id AND Module id.  We then update the Module id table with the info from the preset table. I.e. dim level and fade rate. This whole process is initially started when we "sniff" an Activate link (scene control) 0x87 command.  We extract the link id from the Destination id field of the "sniffed" packet and perform the above database search.
 
I have to generate another Upstart export file anytime any switch preset is changed.  The app will then have to be restarted in order to rebuild the database according to the new export file.   The database also contains tables to hold other data such as product info (LEviton name of the product), header info such as network id, password etc, devise status.
 
To reiterate, the key is to be sure to use the most current Upstart export file.
 
 
 
 

cobra said:

Are you comparing to RadioRA from Lutron?

Click to expand...

 

Not actually "comparing" just looking for ways to query.
 

wkearney99 said:

But let me toss it back to the OP, what're you envisioning that would require that kind of status?

Click to expand...

True automation. Knowing the status is KEY to fully automating a home. Hitting a button that turns on a scene is not true automation. That's just a shortcut, a convenience. Nice, yes. Capable? Not so much. Having the house KNOW what room you are in, if you are home, who is home, current condition of lights so scenes can be returned to AFTER execution of various macros and basing events on all those perimeters is automation. 
 
Some examples:
 
If after 10pm and room is not occupied and tv is off and no lights are currently on, set X light scene. After 4 minutes of no activity, turn lights off. If tv is on, do nothing with lights. 
 
If after 7pm but before 6am, no lights on, no TV on, no occupancy, turn on X scene. If B lights are on, turn on C light to X until no occupancy after 4 minutes. If TV is on, dont turn on any lights. 
 
If TV is on in master bedroom and you walk to master bath and no master bath lights are on, turn on master bath TV to same channel as master bedroom and turn on puck light Z until no motion is detected. But if a light is on in master bath, dont turn on TV. 
 
If driveway alarm detects traffic and no lights are on in the house but someone is home, turn on outside lights Q. If no one is home turn on lights P. 
 
If dark out side and you walk into kitchen and X lights are on at these certain levels, turn on lights Z then return back to previous exact lighting levels as before after no occupancy, otherwise just turn on lights Z then turn them off. 
 
These are not actual macros I want to create necessarily but just some examples of what can be done. So, one can see that knowing the status of lights and quickly is a necessity in creating some real automation where no interaction by the use is required at all. No button presses, no manual triggering. 
 
I currently have Lutron Ra2 main repeater with lighting fast occupancy sensor throughout the home. This is tied to URC's Total Control that coupled with Dash OS's Lutron module. EXTREMELY powerful. The weak link is UPB. Yes, I could rip out 150 plus UPB switches and replace it with Lutron but that would be silly not to mention about 20 grand lol. So, just doesnt make sense. I really like UPB. Actually, I love it. Until it can be figured out how to make it a more powerful component in a truly automated system, Im afraid UPB technology is a dying on the vine. Even the manufacturers admit sales are stagnant. With so many lighting options these days, less and less people are going to what a dated technology that has no feed back. Information is key. 
 
Yes, I understand powerline technology is a different animal than others. My goal is not so much to make a comparison of UPB to others but how to make it do what I  need it to do. On a side note, having a sensor detect movement, then four seconds later a light triggers is not an acceptable solution. I assume the ultimate solution would a module for Total Control to be written that can check/track the status and activate macros based on those findings. It very well may be that UPB is not capable of this. Thats what I am trying to find out. I assume it can be done as HAI has the ability to know the status. The key will be how fast a module can do that. Like I said, UPB may very well not be capable of this scenario. Thats what I want to find out. 

True automation. Knowing the status is KEY to fully automating a home.
 
I think you are making much to do of nothing.  This is your opinion based on what you want or consider automation.
 
Here I do let the automation devices watch status and did have fun creating all sorts of automation events based on whatever triggers I wanted to utilize.  It gets old really fast. 
 
I utilize PIR's everywhere and while it was fun to create automation relating to an attempt to define occupancy it was just a waste of my time to sit there and watch and add more triggers of automation.  It did get low on the WAF anyways while concurrently it was fun to do.  Over the years I have added more automated switches (UPB) and the more I add the less I watch. 
 
That said I understand the need of wanting to create events based on whatever relating to automation.  I used to have fun doing this stuff and watching it work.  Today though I do consider much of the automation here just the heartbeat of the home.  I do not keep checking on it to make sure it is working.
 
If after 10pm and room is not occupied and tv is off and no lights are currently on, set X light scene. After 4 minutes of no activity, turn lights off. If tv is on, do nothing with lights.
 
Yeah I've done this before.  It works and so what.  It doesn't define automation for me.
 
Really much of this relates to the transport / dependencies mechanisms in place to get from point A to point B.

Ranger Digital said:

I currently have Lutron Ra2 main repeater with lighting fast occupancy sensor throughout the home. This is tied to URC's Total Control that coupled with Dash OS's Lutron module. EXTREMELY powerful. The weak link is UPB. Yes, I could rip out 150 plus UPB switches and replace it with Lutron but that would be silly not to mention about 20 grand lol. So, just doesnt make sense. I really like UPB. Actually, I love it. Until it can be figured out how to make it a more powerful component in a truly automated system, Im afraid UPB technology is a dying on the vine. Even the manufacturers admit sales are stagnant. With so many lighting options these days, less and less people are going to what a dated technology that has no feed back. Information is key. 

Click to expand...

 
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...

At some point we realize the gizmos we picked, well, sucked.  
 
While I love my RA2 lighting for it's fantastic performance, their integration of it with modern systems absolutely sucks.  Their whole Caseta/RA2/HWQS nonsense is leaving them painted into a corner of their own making. The upside is they could make it better, and I'd still have terrific dimmer controls in the walls.
 
The URC/DashOS setup does look interesting.  That'd be worth a thread just discussing that by itself.  Where's a forum that covers it?
 
As for the automation scenarios, I think Pete makes excellent points.  While the "idea of" totally intelligent, nearly psychic, integration is appealing, and it seems like it's sooooo close to being possible... it fails for many of the same reasons that AI fails, in general.  And that's people expect more of it than they're realistically willing to contribute to making it work.
 
One very big problem with automation is it's always going to be "too dumb" to know what you're thinking.  And nobody's going to be willing to let it know what they're thinking... all... the... time....
 
"TV follow me" as you wander from room to room.  Unless someone's already in that room and the TV's already watching... something else.  What's the rule here?  Who pulls rank?  All the time?  Or only some of the time?  Depending on which show?  The kids are watching SpongeBob and you've been watching a closely fought sporting event.  Do you win and the TV automagically switches?  If they're 2-5 year olds you've just introduced more headaches than you probably want.  Or it's wife watching one of her favorite shows and she actively despises being pre-empted for your dumb-ass football game.  Now, these aren't examples specific to you, but I'd venture they're pretty damned common in the real world.
 
Let's step aside for a moment, when I worked at Apple they created the Newton.  Truly amazing stuff.  Journalists latched onto handwriting recog issues and, well, it went downhill from there.  This is where no matter how amazing your underlying structure might be, it's the idiots making "leaps of expectation" that will just utterly fuck up your momentum.
 
Now, back to lighting changes, without knowing your tasks, making automatic lighting changes is annoying as all Hell.  Just because I'm wandering into the kitchen after dark doesn't mean I want the lights to come up, or change.  I could just be ducking into the space to do something quick and lighting change would be jarring.  Hell, I could just be sneaking into the freezer for some Chubby Hubby ice cream and the lights coming up would rat me out...  
 
Again, if it doesn't "know" your intentions it might well be much more annoying than helpful.
 
Don't get me started on presence detection.  That's a knot of Gordian proportions.  Yes, it ought to be simple.... until it's not and it again, annoys the crap out of the occupants because it was so dumb about what it did.  Even though we told it to do that.
 
Think of the Iron Man movie where the robot arm in his lab gets abuse ladled onto it for constantly doing something wrong.  Now, part of that is just Hollywood scriptwriting (and bad acting) but it isn't far from real world levels of potential disenchantment.  Which translates into disastrous effects on unit sales...
 
So, to circle back around, to get closer to what you want it may well be more effective to just replace the switches.  You'll get what you think you want, it'll work, and you'll get one step closer to discovering it's still not easy.  But at least you'll have one arbitrarily limited piece of the puzzle taken out of the mix.

In my younger days I was very active in controlling every light and turning them off when no one is there. I still have motion detectors in every room. But honestly, with all the information I had it never worked good.  With incandescent bulbs maybe I saved power, but the WAF was BAD. So was the SAF (Self approval factor).
 
Then compact fluorescent were the craze. So when the light went on it still had to "warm up."  Now ever bulb in my house is LED. Instead of 60 watts it uses 6. In other words 10 lights use what one used to. Now I set each room with scenes. All the rooms we use stay lit from dusk to bedtime. The home looks beautiful, wife is happy and so am I, and electricity use is insignificant.  I do the same if we are home or away, All my blinds and shades are automated and that gives the lived-in look.  
 
I'm so happy those crazy control the light days with motion are behind me. With LED lights, why bother and annoy people?

Hee hee, aren't we the disenchanted geezers 'round here.

One of my most favorite observations is "it seemed like a good idea at the time".  Oh, my, could I rattle off the number of times THAT has come to mind...
 
Yes, over-lighting and under-lighting made for lots of "if I could only do X..." wishful scenarios.  Now that LED lighting exists, a lot of previous nonsense is just.... gone.  Sure, it's rip-and-replace in a few situations, but my goodness is it worth it.  No more 'likely to set my cabinets on fire' halogen puck lamps (or those gawd-awful torchiere uplights).  
 
No tabletop dimmers, just on-wall modules.  Meanwhile, no reasonably priced (or genuinely functional) wall or wireless buttons to control the modules.  Made for a very low WAF, not helped by fantastically tedious X10 shenanigans.  
 
Pretty much any time something claims to be able to use the powerline for communication, I (metaphorically) want to get out a big stick and go beat the engineers and marketing idiots that keep trying to foist that nonsense on people.  It... just... doesn't.. work.  STAHP!
 
You know what impresses guests the most with all this automation gear?  They absolutely LOVE that my porch light has a controlled fade-in and fade-out time.  Nope, none of the rest of it really grabs them like seeing it nicely bring up the lights when they approach, or fade them once they're in the car, leaving.  Simple stuff.
 
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.