Re: Lutron Homeworks Seetouch Keypad
Towanda Tuning
Wow I finally found someone else with the same problem I have with my Lutron shades. I have RadioRA 2, but the same issue where when you close the shades fully from C4 environment, you then have have to press the open button TWICE from seeTouch keypad.
I do not use it but I do have the Lutron Connect app. When I close the shades fully in C4 it does not show the correct shade level in the Lutron app (so same symptoms as you). When I click the lutron button on my wall the lutron app realizes the state for the shade but then I have to click the button another time for the shade to actually do anything.
Based on the driver information, Control4 was the creator of the Lutron drivers, not Lutron itself. So Control4 used the published API and created their own drivers. So I think C4 is on the hook to fix this, if we can convince them there is a bug.
There is not much out there that I can find regarding this Leap driver documentation and how it works. I have a QS system. I'd be happy to update to a QSX if it gives me the ability to have accurate scene mapping and integration into my C4 and Lutron system.
Would this give the ability to properly mimic Lutron QS keypads with scene control. In almost all of my jobs the main top button in every room is the main lighting scene for the room, followed by individual control below. Getting C4 to recognize those keypad button w scene control has been a pain. Individual button control is no problem.
In terms of mimicking scene buttons, i know it can be programmed if you'll get scene feedback, that's something i'm not sure about, not had a chance to test one out yet as in the UK we've only just got the QSX processor. There is also a keypad driver available. Again i've not tried it yet, so i can't comment.
What i currently do is create a scene inside c4, add my loads, press. the lutron keypad button and on c4 press the get light levels button. This works really well as when you execute a scene from c4 the lutron keypad LED also lights up OR You can create blank lighting scenes and in programming add a press and release commands, this is good as if you ever change anything on the lutron side you won't have to re do c4, ad you're just mimicking a button press.
As of the OpenHAB 2.4 release, the Lutron binding should now work with HomeWorks QS systems, at least to some extent. I am looking for help from people who can test it out and provide feedback so that we can work toward full HWQS support. I do not have access to a HomeWorks QS system myself.
Auto-discovery may work only partially, or may not work at all. This needs to be tested. It would also help to see examples of the XML configuration file (DbXmlInfo.xml) from the HWQS processor. Auto-discovery relies on this file.
Finally, support for Lutron venetian blinds and horizontal sheer blinds is not available yet, but is coming soon. If anyone has Lutron blinds in their RadioRA 2, HomeWorks QS, or Caseta system (if Caseta supports blinds), and is willing to test the new blind thing, please let me know! You would need to be running either 2.4, or a 2.5 snapshot or milestone release.
Just a quick update: I have created a new keypad handler that should work with the seeTouch QS International keypads on HomeWorks QS systems. Once all of the 2.5 build system change issues have been worked out and we have a new milestone release of 2.5, I will make it available for testing under 2.5.
Thanks Dan. That is the URL that discovery is trying to use already. Does it work without supplying any authentication information or having already authenticated with your browser? For example, will a curl command like the following on a Linux host spit out the XML file?
I discovered that there is a problem with the embedded web server in older versions of the HomeWorks QS Processor firmware. In responses, it ends header lines with and ends the header with rather than ending header lines with and ending the header with as required by RFC2616 & RFC7230. This is what has been preventing auto-discovery from working properly with these devices, since the discovery service in the Lutron binding needs to retrieve the configuration XML file from the bridge device using HTTP. Some HTTP clients work with these incorrect header line endings, but many do not.
I opened this github issue to track the HomeWorks discovery problem:
github.com/openhab/openhab2-addons Issue: [lutron] Discovery issues with older HomeWorks QS software versionsopened by bobadairon 2019-07-17I've discovered that there is a problem with the embedded web server in older versions of the HomeWorks QS Processor firmware....
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.
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.
7fc3f7cf58