Does anyone know if the latest binding works for Homeworks QS? As of six months ago it didn’t, so I’m currently using some rather hacky nodejs code… but a binding would be much better…
Dan
In theory, the 2.4.0 M6 build should work with Homeworks QS. I included a fix for it in PR 3911. I have no way to test it myself, though, so I’d be interested to hear from anyone who can.
Bob
Yeah, unfortunately there does not seem to be a way to auto-discover Caseta devices using the public APIs, so you have to configure them manually. Auto-discovery works with RA2, and possibly with Homeworks QS.
Hey David,
I’m very interested in integrating a Caseta Pro hub with OH2, and am interested in using Pico remotes to control other things managed by OH2, esp. lights connected to a Hue bridge. How well have you gotten this to work? Can you dim other non Caseta lights on your OH2 system with the Picos? If so, is there alot of lag?
Hi, @dstjohn. I have been testing a mix of RadioiRA 2, Caseta (Pico remotes), Zigbee and Z-Wave devices controlled by RadioRA 2 wireless keypads and Pico remotes. For the bridge I am not using a Caseta Pro, rather a RadioRA 2 master repeater for the interface with the Lutron devices, but it is all working very well for me, and IMO, the system is very responsive.
I really like that with the Pico and RR2 keypads, I don’t have to configure keypresses with the Lutron configuration software. I have configured OH2 items for individual keys and corresponding OH2 rules to handle keypresses.
Hi, Scott. This seems very much like what I’m trying to do. Do you dim lights this way? If so, is it easy/ergonomic to do (i.e., no frustrating delays or missed key presses)? Seems like OH2 would have to be able to see the key-down and key-up events separately for this to work really well. Is that how it works?
Key-up and key-down are each unique events. In the configuration of keypads for the Lutron binding, there is a parameter, autorelease, that defaults to true. When a keypad is configured with autorelease=true, the release (key-up) event is assumed, i.e., a switch item linked to a key thing will automatically return to the OFF state. It is certainly possible to configure a keypad with autorelease=false, in which case the release event will have to be fielded by a rule to return the corresponding switch item’s state to OFF.
With the Pico keypads, if a key is held for a longer time, a third event code is returned, which effectively indicates that the key was held longer than some built-in interval. If the key is released some time after the “long keypress” event has been emitted by the Lutron system, no additional event is emitted until the key is pressed again.
There are Pico keypads with UP and DOWN buttons that are typically dedicated to dimmer control, but I haven’t tried any of them. The RadioRA 2 keypads also have dedicated UP/DOWN dimmer controls.
Thanks, Scott! This sounds promising enough for me to buy a bridge and try it out.
Great! If you don’t mind the somewhat higher prices for Lutron devices, I highly recommend them. It sounds to me like you have already done some research on the Caseta possibilities and are aware that you should to get the Caseta Pro Hub rather than the plain vanilla Caseta Hub.
Yup. That’s the one I ordered, along with two pico remotes.
Hi David,
I am glad that Scott was able to answer your questions. I do not have any other smart dimmer lights to control, so I cannot speak to that aspect. Thanks for tagging me, it reminds me that I need to configure more things in my system (I haven’t added much to my system in the past two years).
David
Hello all,
First, thank you for the work on this. I have deployed this very successfully across my house (2x Caseta Pro bridges and an RA2 bridge with north of 100 devices) and it all ties to OH very well. I am seeing one intermittent issue which I’ve not been successful on pinning down. I have a Serena Shade attached to one of the bridges. Commands work flawlessly and updates work with no issues when they come from OH. I have a Pico remote tied to the shade through the hub and for whatever reason when I use the Pico to raise/lower the shade it does not update the value on the OH side. The shade, pico, and bridge are all within 10 feet of each other in the same room so I don’t believe this is any kind of signal/range issue or anything like that.
Thanks!
I need some help / ideas - what to try next
I upgraded my openhab to 2.4 - now my Lutron pico remotes do not work anymore.
the Dimmers work fine
not work measn openhab does not register any button press events on the picos (button2-6)
Any suggestions what I can do?
I tried to remove all things and reconfigure via Paper UI - did not work
So I deleted all things (Bridge, Dimmers, Picos via Paper UI)
I created the IP Bridge the Dimmers and Picos via a Things file
Thing lutron:ipbridge:casetahubpro [ ipAddress="192.168.1.129", user="lutron", password="integration" ]
//dimmers
Thing lutron:dimmer:Formal_Dining_Ceiling (lutron:ipbridge:casetahubpro) [ integrationId=2, fadeInTime=0.5, fadeOutTime=5 ]
Thing lutron:dimmer:Dining_Chandelier (lutron:ipbridge:casetahubpro) [ integrationId=4, fadeInTime=0.5, fadeOutTime=5 ]
//Thing lutron:dimmer:Formal_Dining_Chandelier (lutron:ipbridge:casetahubpro) [ integrationId=5, fadeInTime=0.5, fadeOutTime=5 ]
Thing lutron:dimmer:Hallway_Downstairs (lutron:ipbridge:casetahubpro) [ integrationId=12, fadeInTime=0.5, fadeOutTime=5 ]
Thing lutron:dimmer:Living_Black_Sofa (lutron:ipbridge:casetahubpro) [ integrationId=6, fadeInTime=0.5, fadeOutTime=5 ]
Thing lutron:dimmer:Living_Grey_Sofa (lutron:ipbridge:casetahubpro) [ integrationId=7, fadeInTime=0.5, fadeOutTime=5 ]
Thing lutron:dimmer:Hallway_Upstairs (lutron:ipbridge:casetahubpro) [ integrationId=10, fadeInTime=0.5, fadeOutTime=5 ]
Thing lutron:dimmer:Lego_Room (lutron:ipbridge:casetahubpro) [ integrationId=17, fadeInTime=0.5, fadeOutTime=5 ]
// picos
//Thing lutron:pico:Pico_Black_Sofa (lutron:ipbridge:casetahubpro) [ integrationId=8, model="3BRL", autorelease="true" ]
Thing lutron:pico:Pico_Black_Sofa (lutron:ipbridge:casetahubpro) [ integrationId=8 ]
My items file looks like this
Dimmer FormalDiningCeiling "Formal Dining Ceiling" <slider> { channel="lutron:dimmer:Formal_Dining_Ceiling:lightlevel" }
// Pico for Scenes
//Scene_Sofa
Switch PicoBlackSofa_Top "Pico Black Sofa Top" <switch> { channel="lutron:pico:Pico_Black_Sofa:button2" }
Switch PicoBlackSofa_Middle "Pico Black Sofa Middle" <switch> { channel="lutron:pico:Pico_Black_Sofa:button3" }
Switch PicoBlackSofa_Buttom "Pico Black Sofa Buttom" <switch> { channel="lutron:pico:Pico_Black_Sofa:button4" }
Switch PicoBlackSofa_Up "Pico Black Sofa Up" <switch> { channel="lutron:pico:Pico_Black_Sofa:button5" }
Switch PicoBlackSofa_Down "Pico Black Sofa Down" <switch> { channel="lutron:pico:Pico_Black_Sofa:button6" }
Depending on what I tried I saw some warnings in openhab.log
2018-12-29 19:31:41.270 [WARN ] [n.internal.handler.BaseKeypadHandler] - Unable to determine channel for component 2 in keypad update event message
2018-12-29 19:31:41.571 [WARN ] [n.internal.handler.BaseKeypadHandler] - Unable to determine channel for component 2 in keypad update event message
2018-12-29 19:31:41.870 [WARN ] [n.internal.handler.BaseKeypadHandler] - Unable to determine channel for component 5 in keypad update event message
2018-12-29 19:31:42.102 [WARN ] [n.internal.handler.BaseKeypadHandler] - Unable to determine channel for component 5 in keypad update event message
2018-12-29 19:31:42.545 [WARN ] [n.internal.handler.BaseKeypadHandler] - Unable to determine channel for component 3 in keypad update event message
2018-12-29 19:31:42.619 [WARN ] [n.internal.handler.BaseKeypadHandler] - Unable to determine channel for component 3 in keypad update event message
2018-12-29 19:31:42.696 [WARN ] [n.internal.handler.BaseKeypadHandler] - Unable to determine channel for component 6 in keypad update event message
2018-12-29 19:31:42.919 [WARN ] [n.internal.handler.BaseKeypadHandler] - Unable to determine channel for component 6 in keypad update event message
2018-12-29 19:31:43.377 [WARN ] [n.internal.handler.BaseKeypadHandler] - Unable to determine channel for component 4 in keypad update event message
And some exception during discovery - but my guess is that is unrelated
2018-12-29 19:41:04.562 [ERROR] [scovery.LutronDeviceDiscoveryService] - Error scanning for devices
com.thoughtworks.xstream.io.StreamException: : Connection timed out (Connection timed out)
at com.thoughtworks.xstream.io.xml.StaxDriver.createReader(StaxDriver.java:126) ~[101:org.eclipse.smarthome.config.xml:0.10.0.oh240]
at com.thoughtworks.xstream.XStream.fromXML(XStream.java:1115) ~[101:org.eclipse.smarthome.config.xml:0.10.0.oh240]
at com.thoughtworks.xstream.XStream.fromXML(XStream.java:1062) ~[101:org.eclipse.smarthome.config.xml:0.10.0.oh240]
at org.eclipse.smarthome.config.xml.util.XmlDocumentReader.readFromXML(XmlDocumentReader.java:85) ~[101:org.eclipse.smarthome.config.xml:0.10.0.oh240]
at org.openhab.binding.lutron.internal.discovery.LutronDeviceDiscoveryService.readDeviceDatabase(LutronDeviceDiscoveryService.java:88) ~[241:org.openhab.binding.lutron:2.4.0]
at org.openhab.binding.lutron.internal.discovery.LutronDeviceDiscoveryService.access$0(LutronDeviceDiscoveryService.java:84) ~[241:org.openhab.binding.lutron:2.4.0]
at org.openhab.binding.lutron.internal.discovery.LutronDeviceDiscoveryService$1.run(LutronDeviceDiscoveryService.java:71) [241:org.openhab.binding.lutron:2.4.0]
- some more lines below
Any hint is welcome
Hannes
I believe I figured it out.
the breaking changes for my installation were:
the channels changed. Up to 2.3 for a pico remote the channels were top to bottom( however maybe I configured it wrong to start with)
- button2 - Top Button
- button5 - Raise Button
- button3 - Middle Button
- button6 - Lower Button
- button4 - Bottom Button
with 2.4 the channels for a Pico 3BRL are - button1 - Top Button
- buttonraise - Raise Button
- button2 - Middle Button
- buttonlower - Lower Button
- button3 - Bottom Button
My rules also used the “received command ON” trigger and with 2.4 the items actually receive an update “received update ON”
I hope this helps other folks too. maybe the description in the binding regarding channels needs an update too.
Hannes
Since there are different Pico keypad models, have you tried using the model option in your Pico keypad Thing definition?
Thing lutron:pico:Pico_Black_Sofa (lutron:ipbridge:casetahubpro) [ integrationId=8,model="3BRL" ]
I used auto-discovery with my RadioRA 2 system, but I did specify that the Pico keypad is a model 4B and it works with the “standard”, i.e., expected button mapping.
Just to note that the binding is only partially compatible with Homeworks QS - dimmers work fine, but SeeTouch keypads aren’t recognised. If any of the devs are interested and have time then I can set out how the QS telnet protocol works for the keypads (I’ve written a simple nodejs script to monitor and trigger them).
Dan
Scott,
thanks for the hint, I tried the “3BRL” as that is what is on the back of my Picos. When I tried I did not get any event (I tried channels button 1-9 (“button1”, “button2”, …)as trial and error ;-)).
I did not investigate “why?” so maybe I messed something up elsewhere.
So far it works fine with the Thing definition omitting the model definition (never touch a running system!)
Looking at the code lines 25 and following and 109 following I assume your 4B only supports 4 buttons - I use all 5 on my picos so that would not work for me. The generic and 3BRL seem to be the same anyway.
private static enum Component implements KeypadComponent {
// Buttons for 2B, 2BRL, 3B, and 3BRL models
BUTTON1(2, "button1", "Button 1"),
BUTTON2(3, "button2", "Button 2"),
BUTTON3(4, "button3", "Button 3"),
RAISE(5, "buttonraise", "Raise Button"),
LOWER(6, "buttonlower", "Lower Button"),
// Buttons for PJ2-4B model
BUTTON1_4B(8, "button01", "Button 1"),
BUTTON2_4B(9, "button02", "Button 2"),
BUTTON3_4B(10, "button03", "Button 3"),
BUTTON4_4B(11, "button04", "Button 4");
case "Generic":
case "3BRL":
buttonList = Arrays.asList(Component.BUTTON1, Component.BUTTON2, Component.BUTTON3, Component.RAISE,
Component.LOWER);
break;
If the commented out Thing definition in your original post is the text of your original definition, you have spaces following the commas between options. IIRC, you have to remove the spaces (I wouldn’t think that spaces should be a problem, but I think they are.)
I am seeing one intermittent issue which I’ve not been successful on pinning down. I have a Serena Shade attached to one of the bridges. Commands work flawlessly and updates work with no issues when they come from OH. I have a Pico remote tied to the shade through the hub and for whatever reason when I use the Pico to raise/lower the shade it does not update the value on the OH side.
That is an odd one. Are you still having this problem? Are the shade and Pico connected to a RA2 system or a Caseta system? In order to help figure out what is going on, I’d recommend that you enable debug level logging for the Lutron binding, then look at the messages that are written to the log file when you press a button on the pico that moves the shade. You should see DEVICE messages from the bridge as notifications of the button press on the pico, and then OUTPUT messages that are notifications from the bridge of the request to the shade to change position. The shade handler should receive and interpret the OUTPUT messages and update the state of the shade level channel.
HI Dan. Thanks. It’s good to hear that the binding is at least partially working with HWQS now. I’d be very interested to hear what needs to be changed in order to get the keypad handlers (and everything else) working properly with it.