Is UPB able to be queried? Like Lutron

Frederick C. Wilt said:
A good CQC driver for UPB should be fairly straight forward. I would have a lot more faith that you could write a clean one then many of these "3rd party" coders. 
 
Is this existing driver available to QCQ customers like myself? I would like to take a look at it.
 
Thanks.
 
It's available in the Driver Development section of the forum. Just search for UPB there and you should find it. The driver is always linked in the first post of a thread that contains one. Just import the driver package.
 
Dean Roddey said:
It's available in the Driver Development section of the forum. Just search for UPB there and you should find it. The driver is always linked in the first post of a thread that contains one. Just import the driver package.
 
Thank you.
 
Frederick C. Wilt said:
Thank you.
If your looking for a "good" UPB driver, the QCQ driver is not it. It hasn't been updated in many many years. Send three commands in a row and maybe two go through. Send a link and there is no tracking of status. When I stopped using CQC a year and a half ago, the driver author had long since disappeared, and the driver import tool wasn't working or supported. Unless this driver has been updated in the last year and a half, it ain't great. This was one of the big reasons I dropped CQC as I really needed UPB to work well.
 
ano said:
If your looking for a "good" UPB driver, the QCQ driver is not it. It hasn't been updated in many many years. Send three commands in a row and maybe two go through. Send a link and there is no tracking of status. When I stopped using CQC a year and a half ago, the driver author had long since disappeared, and the driver import tool wasn't working or supported. Unless this driver has been updated in the last year and a half, it ain't great. This was one of the big reasons I dropped CQC as I really needed UPB to work well.
 
I was wanting to look at the driver to see how well it was done. I know that often these types of "donated" drivers are not very good.
 
I'm certainly happy to do a better one, but I'm very time limited, since I'm working very hard on 5.0. But if you guys can school me on the details, to save me a bunch of time trying to figure it out myself (and, before anyone says it's not hard, EVERYTHING is hard when it has to work really well in arbitrary circumstances in a complex environment), then I could probably create a much improved one. 
 
BTW, we have folks using that driver currently without any significant issues of that sort. So problems you were having must have been at least partly addressed since then. There are still some quirks, such as it doesn't filter for 'network id' or 'network number', so it might see a neighbor's msgs sometimes if you have one close by using UPB. That can cause some wierdness.
 
Frederick C. Wilt said:
I was wanting to look at the driver to see how well it was done. I know that often these types of "donated" drivers are not very good.
This is a third-party driver, and as far as I can tell, the author is gone, or at least I couldn't find him. If you click on the link in the CQC instructions for the driver, the link to the company has been broken for what 4 or 5 years. http://www.kanak.com/Store/proddetail.asp?prod=KSI%2DUPBCQC  The program that converts the UPStart file is long gone off the site.  This program needs to be updated everytime a new UPB switch comes out. Yes it can be entered manually but lots of work.
 
QCQ and Homeseer share the same problem. Drivers are not updated, many of their authors are long gone. Personally I feel if the drivers aren't bulletproof and support all the newer updates, the base program can be the greatest in the world, but who cares?

 
 
Well, the people that use the hundreds of other devices that don't have that issue, generally. There are too many devices out there for any one system to support every one of them to the hilt. That would be more work than even a very large company could stomach. It can only happen if the manufacturers of the devices themselves do the drivers. Though of course that also suffers from the same problems as operating systems drivers demonstrate.
 
Just within a single category, like A/V receivers, it's almost impossible. Companies put out variations at a stupid pace, and don't really do anything to help us create adaptable drivers that can support a wide swath of their products as is. Yamaha has recently started to get this right, allowing us to just query it for what it supports and have a single driver that can adapt to a lot of different models.
 
Actually the bulk of the drivers, at least for the important stuff, are written and maintained by us. Or, in some cases, they are a simple derivation of one that we wrote, to deal with some other variation of the same device. Most of the third party ones are for more peripheral type devices. We do the Elk, Omni, RA2/HW, Hue, Nest, Z-Wave, Insteon, Brultech, TTS, audio players and media repositories, Sonos, Nuvo, Amazon Echo, Harmony,  Aprilaire, Plex, DSC, Weather, Tekmar, Global Cache and other IR related ones, iTunes, Russound, and other drivers of that sort that are core to lots of people's systems.
 
Ultimately, if customers want more peripheral drivers to be done and maintained by us, they will have to contribute bucks to it. Unlike Homeseer we don't charge for drivers, so we cannot afford to spend enormous amounts of time on drivers that will only be used by a small fraction of customers, which is ultimately most of them. Even if we did charge for them, if only a small number of customers ever use a given one, we'd still lose money.
 
Curious Dean what is the most popular lighting technology utilized with your software today?
 
The means/mechanisms of controlling my lighting today is simple.
 
My UPB lighting works and I do not brood over it or stare at the status of my lighting to know that it is working. 
 
Writing the application isn't hard.  It's the testing (and debugging) that is EXTREMELY hard.  I would guesstimate that about 90% of my time is spent on testing and debugging. This is very boring, grueling drudgery work. Single stepping thru code, setting breakpoints, checking outputs etc.  Trying to cover every conceivable potential issue  Find and fix a defect and I have to start over from the beginning on my testing since I may fix a problem in one area but create another problem in another area.  So, it's drudgery over and over and over and over until I feel comfortable with the product.   My guess is that these 3rd party "donated" drivers just don't go thru a lot of testing since it's very boring work.  They probably, just test it once and if successful, it's then ready for production.
 
But anyway, I went on the CQC forum to look at some of the UPB issues.   I found one post concerning a malformed packet as follows:
 
 

CQCKit, MEng.System.CQC.Runtime.CQCLogger.733, Status/App Status
    Received malformed PU: PU8A0C101B3E20FFFFFFE4<RET>
}

 
The problem here is that three extraneous 0xFF's  (FF) have been injected into the packet.  The issue appears to be somewhere in the building or processing of the packet.  The 0x20 (20) indicates that it is a Activate Link Command.  All Activate Link Commands (0x20) are seven bytes in length, there are no exceptions.  The above packet is 10 bytes in length.
 
The correctly formed packet should look like this:
PU870C101B3E20E4
 
I also did a checksum calculation on the malformed packet 8A0C101B3E20FFFFFFE4 and the checksum value of 0xE4 (E4) is correct for that malformed packet.  So, these extraneous 0xFF's are probably being added to the packet prior to the checksum calculation
 
 
 
 
 
 
BobS0327 said:
Writing the application isn't hard.  It's the testing (and debugging) that is EXTREMELY hard.  I would guesstimate that about 90% of my time is spent on testing and debugging. This is very boring, grueling drudgery work. Single stepping thru code, setting breakpoints, checking outputs etc.  Trying to cover every conceivable potential issue  Find and fix a defect and I have to start over from the beginning on my testing since I may fix a problem in one area but create another problem in another area.  So, it's drudgery over and over and over and over until I feel comfortable with the product.   My guess is that these 3rd party "donated" drivers just don't go thru a lot of testing since it's very boring work.  They probably, just test it once and if successful, it's then ready for production.
You are certainly correct.  The UPB driver, for example, was written very close to when UPB came out, many years ago.  The author never fully tested it, and there weren't many others using UPB at the time to test it either.  For example one bug in the UPB driver that has always been there is if you send 3 or more UPB commands in a row, the last 1 or more commands get lost. The driver probably never properly queued commands, or maybe some PIMs are faster than others.  Better testing would have caught this one, but creating a driver is fun, testing it is not very fun.
 
Maybe a bigger problem is that the author of these drivers just move on.  They have lives, and their lives go on. The driver stays fixed to that moment in time when it was created, but the problem is protocols and technologies evolve so someone has to update a driver if it is to remain current, and there is no one to do that. By the time i started using the UPB driver, maybe 7 or 8 years ago, the drive author had already moved on and was only making minimal updates to the driver.
 
It's an *extremely* common problem that people bang on us to add support for a device, or some type of functionality. We then do it, but no one is ready to actually test it and provide feedback. Sometimes it's quite a while before anyone tests it, and the iron is no longer hot at that point, so it requires time consuming spinning back up on the issues and so forth. Or, the one or two people who initially pushed for it use it, but they don't really fully exercise it, or have environments diverse enough to really prove it out. 
 
This commonly happens and it's pretty painful. We had a similar issue with ping support. Lots of folks use a pinging driver to watch for devices being active on the network, and do things differently depending on that. Someone really wanted that, so I did it, and it was many years later that someone started using it in a more complex environment and turns out it had all kinds of issues, that I or the person using it never saw.
 
Of course when something has been working in the field for a really long time, you have to sort of assume initially that the problem is pilot error, and you have to go through a lot of work to confirm that that is not the case.
 
And of course there is the issue that, just because Bob Corp came out with a new firmware, doesn't mean you should install it if you are using Bob's stuff with an automation system. We can't drop what we are doing and go back and spin up on some device long since solid at the drop of a hat because they came out with new firmware that broke something. Such things should be done carefully and it should be possible to reverse course is if goes awry. But of course these days it's not always even possible to prevent new firmware from being taken up in this 'we know better than you' cloud based world.
 
pete_c said:
Curious Dean what is the most popular lighting technology utilized with your software today?
 
The means/mechanisms of controlling my lighting today is simple.
 
My UPB lighting works and I do not brood over it or stare at the status of my lighting to know that it is working. 
 
Sadly it's probably Z-Wave, despite it being the hardest to support in a robust way.
 
Lots of "drivers" are only written to 'scratch the itch' that bothered the author.  Not to encompass the full range of what the underlying tech is supposed to be able to support.  So if all you want out of it parallels that of the author, you're golden.  But if you want more then you're stuck.  Firmware and other protocol changes certain serve to complicate the matter.  Again, if the author hasn't changed anything in their setup then it's unlikely they'll revisit the code.  
 
Lots of times the authors are open to passing the torch to someone else.  Sometimes all you have to do is ask.  There are some great hosting and collaborative development websites out there; like github.  
 
That and if you're not competent or skilled enough to make additional changes there's always the option of contracting the work out.  None of this comes for free, somebody's got to burn the hours making it work.  
 
I understand why a developer of a larger product might not want to take over a previously written driver.  Who knows what messes might lie within?  Or what functionality might get broken due to house-of-cards-like code?  That and it's tough to find funds/hours to stand up a workable enough prototype environment in order to even begin writing a driver than can be depended upon to include with their offerings.
 
This is why companies like Extra Vegetables get snapped up by larger companies like Control 4.  They figured out enough of the gnarly bits to bring legitimate added-value with their offerings.  Trouble is, the other systems that used their product get frozen out as the parent company integrates them.  Great for the small company, great for the big company and their customers, not good for the rest.
 
I still feel confident if this was THAT easy, Web Mountain would have figured out how to use their IP module to get what was needed to have 3rd party control. That said, maybe it IS that easy and Web Mountain just needs a starting point. I will turn them on to this thread and see what becomes of it. Maybe they can partner with someone here or at least get a good feel of there that starting point is. Web Mountain has been a GREAT company to work with and has some really good people that communicate. 
 
While common sense would suggest that this is not been done yet because the ROI didnt make sense. I dont believe that is the case as Web Mountain has been most eager to see resolution to this issue. It results in one thing: More sales. 
 
Back
Top