Lutron HomeWorks QS Support

Tags: #<Tag:0x00007f7456ece510> #<Tag:0x00007f7456ece290> #<Tag:0x00007f7456ece150>

I believe the newer discovery code will return a different error in the case of a bad response than if it just fails to connect or can’t parse the XML, so… maybe? I’ll take a look and see if I can do that.

1 Like

I opened this github issue to track the HomeWorks discovery problem:

1 Like

Hi! I just found this amazing community and would love to help test and dev HWQS support!
I currently have a Homeworks QS deployment in my apartment, and here is the XML file: DbXmlInfo-Unformatted
Currently, autodiscovery doesn’t work, also with the “Content is not allowed in prolog” exception when parsing the XML file.

Hi Xinyang! Welcome to the openHAB community!

Thanks for posting your DbXmlInfo file! At this point, every example helps a lot as I try to add full support for HomeWorks QS in to the Lutron binding.

The good news for you is that all of the devices in your configuration should be supported under 2.5. At least if manually configured. New handlers for the International seeTouch keypads and the QSE-IO interface were just merged in to 2.5 a week ago. These are in the current nightly 2.5.0 development snapshot builds, and will be in the upcoming 2.5.0.M2 milestone build. I would be very interested to hear how they work for you.

Discovery is a known problem with older versions of the HomeWorks QS software, but probably not with newer versions. It looks like you are running version 5.0 of the HomeWorks QS software? That is a useful data point, too, since I’m trying to get a handle on which versions have the discovery problem.

In any case, I’m working on a discovery update now that should allow auto-discovery to work for you. I’ll let you know when it is available for testing.

Your configuration file is interesting in two ways. First, many of your output devices (i.e. dimmers) are set up to control DALI digitally addressable dimming ballasts. The discovery code would not previously have worked with those, but after seeing your config I’ve added DALI output support in to my dev branch. Second, your system has areas named with the simplified Chinese character set. I don’t know if that has been tested before. It should work, but I will try it out with the new discovery code and fix it if it doesn’t.

The Lutron binding, like all of openHAB, is written in Java. If you’re interested, you can find the current 2.5 development branch here.

Just a quick update: I tested the new discovery code with your configuration file this morning, and it worked fine.

Hooray! That is fantastic news! I guess UTF-8 does work (sometimes). :wink:

In case you have not seen it elsewhere, these HWQS-specific improvements made it in to 2.5.0.M2:

  • Support for HomeWorks QS International seeTouch keypads
  • Support for HomeWorks QS QSE-IO Interface
  • Support for GRAFIK Eye in RadioRA 2 and HomeWorks QS systems

Soon after the M2 build, another PR was merged that contains multiple discovery improvements. Among other things, it adds the ability to automatically discover more device types that are specific to HomeWorks QS. It also adds a feature for HomeWorks QS users who have been having problems with auto-discovery as described in issue 5841. It will allow you to get around this problem by downloading the DbXmlInfo.xml file to your openHAB server and pointing discovery at it using the discoveryFile bridge parameter. This is available now in the nightly builds, and will be in the next milestone build.

Ahhh this is great, I can’t wait to try it out, I have been out of the game for 8 months while my new digs is being built / wired / programmed.

Looking forward to beta testing this binding

I am a Lutron Dealer/Installer/Programmer and I can provide you with more xml files than I can count if you are interested?

Let me know.

Cheers!

Hi Tom. Yes, I would be very interested in getting more examples of XML config files from HWQS systems! Right now I’m especially interested in seeing examples from systems with:

  • System state variables
  • Shade groups
  • Palladiom, Architrave, Signature, or Dynamic keypads
  • DMX interfaces
  • Any unusual output device types

But XML files from any large/complex systems would be useful for testing.

I’m also interested in learning exactly which versions of HomeWorks QS cause problems for discovery via HTTP as described in Issue 5841. I know that 3.1 and 5.0 seem to have the problem. I’m guessing that recent versions do not, since I know that newer versions of Radio RA2 do not, and they seem to use a common code base.

You can contact me directly via the private message feature.

I can make a custom “phantom” project file with all of those items you require.

I haven’t been in the habit of extracting the xml files from all projects, but now that I know they can be put to good use I will be doing so when I re-visit them.

Hold tight for an example system with the features you are looking for.

I’m discovering OpenHab through a Lutron System.
I had no problem to have the Light Switch discovered by the binding.

But

  • Motors of rollershutter wer not discovered
  • touchpad panel not discovered also

I have DbXmlInfo if it can help
I can do some basics tests for a version that detect shades

Thanks for the job done on this binding

Hi hal01! If you could send me your DbXmlInfo file, I will take a look at it, see why your devices aren’t being discovered, and try to fix/add support for them. The roller shades should work already, so I’ll have to see what is wrong with that. What version of openHAB are you running?

If by the touchpad panel you mean this Dynamic Keypad, that isn’t supported yet, but I can probably add support for it pretty quickly if you are willing to test it.

Hi all,

I discovered openHAB recently, as I just purchased a condo with a HomeworksQS system and I’m looking to integrate it with the rest of the smart home gadgets I’ve been collecting or making during the last couple of years…

I am really impressed about openHAB’s potential… I installed it on a raspberry pi, installed the Lutron binding… and voila! discovery worked and I could see lots of elements… but… it looks like my Homeworks QS processor’s default username/password has been changed… :frowning:

I’ve contacted the company that installed it and they are trying to find the credentials, since the person who configured it has left the company… In the mean time…

I guess that my questions are:

  1. Is there any way I can reset the password for the Homeworks QS processor?
  2. Is there any workaround in openHAB to be able to control the system without the homeworks credentials?

Thanks so much in advance!
R

Hi Roberto. Unfortunately, I don’t know of any way that you can reset the integration password on the HomeWorks processor without the programming software. If you are using the Lutron Home Control+ app on a phone or tablet, you should be able to use the same user/password that you use for that. I don’t think this is true if you are using their newer app that accesses the system through the cloud service, though.

It’s actually a bit unusual for the default integration password to be changed, although I’ve heard that the newer software allows it. Did you try to telnet to the processor and enter the user/password manually to make sure that there isn’t some other problem?

Also, what version of openHAB are you running? I have added support for a lot of HomeWorks devices in the 2.5 development cycle, so I would recommend running at least the 2.5.0.M4 version of the Lutron binding if not a more recent snapshot version.

With the help of hal01 (in the thread above) I’ve recently added support for Palladiom keypads, the QS Wallbox Closure Interface (WCI), and the LQSE-4M-D motor controller in to a development version of the binding that is available here. If you have any of those devices in your system, I would recommend using that version for now, since those updates have not yet been merged in to 2.5.

If you find any devices in your system that aren’t supported by the binding, bring it up here and I will try to get them added. One quick way to check is to grep your log file for the message “Unrecognized device type” from the discovery service.

You might want to try something like this: https://nmap.org/ncrack/

That’s a great idea! I would try a dictionary attack against user names “lutron” first and “integration” second. It might save you from having to have the installer come out to reconfigure it.

Thanks for the responses…

Yes, I’m trying to telnet the processor directly from my openhab, no luck with user/pass.

I’ve created a VPN so the engineer can connect remotely with their programmer software and reset the password for me… Waiting for him to do it… hopefully soon… (if he doesn’t come back to me, I’ll try the ncrack… the issue, I think, is that the processor locks itself down for 15 minutes after 10 unsuccessful login attempts…)

Bob, I’ll definitely try the new version as soon as I have access to my system :slight_smile:

Will keep you posted
Thanks!

Wow. I didn’t expect that a processor that (almost) always uses the same password would have any security measures!

So… Lutron engineer used my VPN to connect and reset the password for me…

From there, it’s been great… Auto Discovery worked to perfection! (I even discovered a couple of plugs controlled by the system that had no idea of)… All configured and running on openHAB now…

Next step… Integration with Google Assistant :slight_smile:
Thanks once again for your answers!
R