I’ll see if I can do that in the next few days. Maintaining two version isn’t as easy as I had hoped it would be, because now along with the namespace changes there is some code in the 3.0 binding that requires a java version higher than 8. The existing beta-2 version has pretty much the same functionality as what was merged in to 3.0, though. I just cleaned up the code a bit more.
Don’t worry about it for me then. I’m holding on 3.x until it gets closer to release. Can’t have my house being flaky. I’ll stay on beta-2 for now.
Hi. I am new to openHAB so please excuse me if my question isn’t phrased well. I have a system with the Pro Bridge and a few Caseta pico remotes, as well as some 3-way switches, which are made of one wired switch and something that looks like the remote. With the current Lutron binding, none of those can be found using search.
Does your LEAP bindings allow for discovery of those through search? I installed openHAB 3.0.0-snapshot and the Lutron binding, and with my bridge seen as online, searching hasn’t returned anything. If I try to create a LEAP bridge manually (assuming it’s the same IP) the config wants a keystore and keystore password. How do I get those?
And in any case, are there good tutorials to add devices for bindings that don’t do search? I think one has to look in logs then?
My first goal is to be able to use openHAB to act as a hub between the Pico remotes and my Philips hue lights, so that I can put the remotes as in wall switches.
Thanks!
Hi. Yes. The ipbridge can’t do automatic discovery for a Caseta system, but the new leapbridge can. However, you would need to follow the docs and configure a keystore with the certificates for your system in order for it to be able to connect and see anything.
I’m actually not sure yet where the binding docs show up in 3.0, but you can see the latest version on github here.
And in any case, are there good tutorials to add devices for bindings that don’t do search? I think one has to look in logs then?
If you want to use ipbridge with a Caseta system and configure it manually, you will need to get an integration report from the Lutron app. That will give you the integration IDs to use when you configure your devices.
My first goal is to be able to use openHAB to act as a hub between the Pico remotes and my Philips hue lights, so that I can put the remotes as in wall switches.
That should definitely work! I do something similar with some keypads on my RadioRA 2 system. However, if you want to be able to take an action in openHAB when someone presses a button on a pico keypad, you’ll need to use the ipbridge rather than the leapbridge, because the LEAP protocol will not report keypad button presses to the binding. That is the one significant limitation of using the LEAP protocol at the moment. So since you have a Pro hub that supports both, you may want to stick with ipbridge for now. You could actually use both at the same time, but that is unnecessarily complex. I’d only recommend that if you need to get both keypad button presses and occupancy sensor status from a Caseta system.
Thanks for the quick response! I’ll see if I can figure out how to get things going from the integration report since I need to stick to the IP protocol.
I don’t see a mention of Pico remotes in your online doc (thanks for the link!) or the LIP integration manual, but I see Lutron referring to them also as keypads (e.g. here), so I assume the Pico keypad support is what i need?
I also noticed that 3.0.0 has a dramatically different UI than 2.5.x, which is fine since I am just getting started. However I am looking for some guidance to figure out what I should put in my model, what are DOs and DONTs, and maybe even things like “I have a ‘Porch light’ in hue that is associated to a ‘Porch (room)’” do I want to import both? And that’s not even looking at the fact that “Kitchen” is probably defined by all my systems: hue, Lutron Caseta, and Google Home/Assistant… Where should I start reading with a 3.0.0 focus in mind?
Yes. For some reason the Caseta docs call it a “Pico Remote”, while in other Lutron systems, which support more keypads, it’s generally called a “Pico Keypad”. But either way it’s the same thing. You’ll want to use the “pico” thing to interface to it.
BTW - The two models that Caseta supports are the -2B (for 2 button) and the -3BRL (for 3 button with raise/lower).
I am looking for some guidance to figure out what I should put in my model, what are DOs and DONTs, and maybe even things like “I have a ‘Porch light’ in hue that is associated to a ‘Porch (room)’” do I want to import both? And that’s not even looking at the fact that “Kitchen” is probably defined by all my systems: hue, Lutron Caseta, and Google Home/Assistant… Where should I start reading with a 3.0.0 focus in mind?
I’m afraid I can’t help you much there! The OH3 UI is still very new, and while I’ve played around with it in the context of binding development and like what I’ve seen so far, I haven’t tried to use semantic modeling in it yet. The docs for 3.0 are still being developed, but there are some draft versions floating around on the forum. I’d suggest searching the forum for “Getting Started with OH3”, and they should come up. In particular, you may want to look at this one:
I was able to do something without much docs. I created equipment, setup all channels, etc. I am not sure how to detect the button being used. I tried to have my trigger be a state change on the button from DOWN to UP (since it only controls the other lights on release) but that doesn’t seem to trigger my rule (the action part works, I can play it). Is that not the correct way to detect that?
PS. I used ID 3 and the connection shows okay/green below is the except from my integration report. It would be great if this could be uploaded to openHAB and things crested from it, some day.
}, {
“Name” : “pico for ceiling lights”,
“ID” : 3,
“Area” : {
“Name” : “Kitchen”
},
“Buttons” : [ {
“Number” : 2
}, {
“Number” : 3
}, {
“Number” : 4
}, {
“Number” : 5
}, {
“Number” : 6
} ]
}, {
I think the problem is that you need to use ON and OFF states for the keypad buttons rather than UP and DOWN. I use rules like the following:
rule LibraryLightsOn
when
Item LibraryLightPico_Button1 received update ON
then
Library1_Brightness.sendCommand(100)
Library2_Brightness.sendCommand(100)
end
I’d like to be able to use that Caseta integration report for auto-discovery, but unfortunately Lutron didn’t put quite enough information in it to always be able to tell what sort of device each ID represents. I’m still looking for a good automated discovery solution for Caseta and RA2 Select systems using the LIP protocol (i.e. ipbridge). There is a way to do it using the LEAP protocol, similar to the way leapbridge does discovery, but that would require setting up certificate-based authentication just for discovery, which may be more effort than just manually creating the things.
Indeed I found events.log and openHAB logs transitions to ON and then OFF as I use the button:
2020-10-24 17:20:44.193 [vent.ItemStateChangedEvent] - Item 'KitchenLights_Pico_Button2' changed from OFF to ON
2020-10-24 17:20:44.199 [vent.ItemStateChangedEvent] - Item 'KitchenLights_Pico_Button2' changed from ON to OFF
and my rule is now working. Thanks! It’s a simple rule in the UI, though. What I’d like to be able to do though, is to be able to cycle through scenes (similarly to the top button of a hue remote; I may actually end up emulating that on the pico top button and use the round button for something else). I don’t think I can do that through the UI simply, can I? (Or would I need multiple rules? That’d be fine if I have a way to maintain state which I don’t know.) And if I can’t, can I use the item names defined through the UI in a .rules file, and does openHAB watch that directory, or do I need to bring it down and restart it after every change to a .rules file?
I know I am asking beyond Lutron, and I apologize. I’ll ask further questions in more appropriate places, I am simply relying on your prompt answering to make quick progress.
You would need to do that with a rule, but you would probably just need one for it. I would probably use a state variable in the rule to track which scene is selected. Every time you detect a button press you can change the state variable, and then set lights to the appropriate levels based on the value of it. In 3.0 you should be able to define rules either in the UI or in rules files, whichever you prefer.
And if I can’t, can I use the item names defined through the UI in a .rules file, and does openHAB watch that directory, or do I need to bring it down and restart it after every change to a .rules file?
That shouldn’t be a problem either. You can reference items defined anywhere from anywhere. And rule files should be re-read whenever you save them. You should almost never need to restart openHAB to change any sort of setting or configuration.
I know I am asking beyond Lutron, and I apologize. I’ll ask further questions in more appropriate places, I am simply relying on your prompt answering to make quick progress.
No problem! You would be better off starting a new topic in the “Scripts & Rules” category if you have more questions about rules, though. That will increase the chances that someone who is better with rules than I am will see it. The rules I use have mostly tended to be pretty simple. Just be sure to mention that you are using OH 3.0.
@BobA, I got the keypad working :D. So, in my kitchen, I have a 3-way Lutron Caseta setup, which is made of a physical wired switch and a Pico remote, controlling my ceiling cans. And then on top of my countertops I have Philips hue lights (color bulbs on one side, and a color light strip under cabinets on the other side). Now I can double-tap the Pico keypad to turn all of them either on to full brightness to cook, or off. That’s awesome.
I want to be able to do the same thing when I use the wired switch. However, I don’t see it in the integration report below. Any suggestions? Is there a way to see the switch and button events/state changes on it?
{
"LIPIdList" : {
"Devices" : [ {
"Name" : "Smart Bridge",
"ID" : 1,
"Buttons" : [ {
"Name" : "Arriving Home",
"Number" : 1
}, {
"Name" : "Leaving Home",
"Number" : 2
}, {
"Name" : "Button 3",
"Number" : 3
}, {
"Name" : "Button 4",
"Number" : 4
}, {
"Name" : "Button 5",
"Number" : 5
}, {
"Name" : "Button 6",
"Number" : 6
}, {
"Name" : "Button 7",
"Number" : 7
}, {
"Name" : "Button 8",
"Number" : 8
}, {
"Name" : "Button 9",
"Number" : 9
}, {
"Name" : "Button 10",
"Number" : 10
}, {
"Name" : "Button 11",
"Number" : 11
}, {
"Name" : "Button 12",
"Number" : 12
}, {
"Name" : "Button 13",
"Number" : 13
}, {
"Name" : "Button 14",
"Number" : 14
}, {
"Name" : "Button 15",
"Number" : 15
}, {
"Name" : "Button 16",
"Number" : 16
}, {
"Name" : "Button 17",
"Number" : 17
}, {
"Name" : "Button 18",
"Number" : 18
}, {
"Name" : "Button 19",
"Number" : 19
}, {
"Name" : "Button 20",
"Number" : 20
}, {
"Name" : "Button 21",
"Number" : 21
}, {
"Name" : "Button 22",
"Number" : 22
}, {
"Name" : "Button 23",
"Number" : 23
}, {
"Name" : "Button 24",
"Number" : 24
}, {
"Name" : "Button 25",
"Number" : 25
}, {
"Name" : "Button 26",
"Number" : 26
}, {
"Name" : "Button 27",
"Number" : 27
}, {
"Name" : "Button 28",
"Number" : 28
}, {
"Name" : "Button 29",
"Number" : 29
}, {
"Name" : "Button 30",
"Number" : 30
}, {
"Name" : "Button 31",
"Number" : 31
}, {
"Name" : "Button 32",
"Number" : 32
}, {
"Name" : "Button 33",
"Number" : 33
}, {
"Name" : "Button 34",
"Number" : 34
}, {
"Name" : "Button 35",
"Number" : 35
}, {
"Name" : "Button 36",
"Number" : 36
}, {
"Name" : "Button 37",
"Number" : 37
}, {
"Name" : "Button 38",
"Number" : 38
}, {
"Name" : "Button 39",
"Number" : 39
}, {
"Name" : "Button 40",
"Number" : 40
}, {
"Name" : "Button 41",
"Number" : 41
}, {
"Name" : "Button 42",
"Number" : 42
}, {
"Name" : "Button 43",
"Number" : 43
}, {
"Name" : "Button 44",
"Number" : 44
}, {
"Name" : "Button 45",
"Number" : 45
}, {
"Name" : "Button 46",
"Number" : 46
}, {
"Name" : "Button 47",
"Number" : 47
}, {
"Name" : "Button 48",
"Number" : 48
}, {
"Name" : "Button 49",
"Number" : 49
}, {
"Name" : "Button 50",
"Number" : 50
}, {
"Name" : "Button 51",
"Number" : 51
}, {
"Name" : "Button 52",
"Number" : 52
}, {
"Name" : "Button 53",
"Number" : 53
}, {
"Name" : "Button 54",
"Number" : 54
}, {
"Name" : "Button 55",
"Number" : 55
}, {
"Name" : "Button 56",
"Number" : 56
}, {
"Name" : "Button 57",
"Number" : 57
}, {
"Name" : "Button 58",
"Number" : 58
}, {
"Name" : "Button 59",
"Number" : 59
}, {
"Name" : "Button 60",
"Number" : 60
}, {
"Name" : "Button 61",
"Number" : 61
}, {
"Name" : "Button 62",
"Number" : 62
}, {
"Name" : "Button 63",
"Number" : 63
}, {
"Name" : "Button 64",
"Number" : 64
}, {
"Name" : "Button 65",
"Number" : 65
}, {
"Name" : "Button 66",
"Number" : 66
}, {
"Name" : "Button 67",
"Number" : 67
}, {
"Name" : "Button 68",
"Number" : 68
}, {
"Name" : "Button 69",
"Number" : 69
}, {
"Name" : "Button 70",
"Number" : 70
}, {
"Name" : "Button 71",
"Number" : 71
}, {
"Name" : "Button 72",
"Number" : 72
}, {
"Name" : "Button 73",
"Number" : 73
}, {
"Name" : "Button 74",
"Number" : 74
}, {
"Name" : "Button 75",
"Number" : 75
}, {
"Name" : "Button 76",
"Number" : 76
}, {
"Name" : "Button 77",
"Number" : 77
}, {
"Name" : "Button 78",
"Number" : 78
}, {
"Name" : "Button 79",
"Number" : 79
}, {
"Name" : "Button 80",
"Number" : 80
}, {
"Name" : "Button 81",
"Number" : 81
}, {
"Name" : "Button 82",
"Number" : 82
}, {
"Name" : "Button 83",
"Number" : 83
}, {
"Name" : "Button 84",
"Number" : 84
}, {
"Name" : "Button 85",
"Number" : 85
}, {
"Name" : "Button 86",
"Number" : 86
}, {
"Name" : "Button 87",
"Number" : 87
}, {
"Name" : "Button 88",
"Number" : 88
}, {
"Name" : "Button 89",
"Number" : 89
}, {
"Name" : "Button 90",
"Number" : 90
}, {
"Name" : "Button 91",
"Number" : 91
}, {
"Name" : "Button 92",
"Number" : 92
}, {
"Name" : "Button 93",
"Number" : 93
}, {
"Name" : "Button 94",
"Number" : 94
}, {
"Name" : "Button 95",
"Number" : 95
}, {
"Name" : "Button 96",
"Number" : 96
}, {
"Name" : "Button 97",
"Number" : 97
}, {
"Name" : "Button 98",
"Number" : 98
}, {
"Name" : "Button 99",
"Number" : 99
}, {
"Name" : "Button 100",
"Number" : 100
} ]
}, {
"Name" : "pico for ceiling lights",
"ID" : 3,
"Area" : {
"Name" : "Kitchen"
},
"Buttons" : [ {
"Number" : 2
}, {
"Number" : 3
}, {
"Number" : 4
}, {
"Number" : 5
}, {
"Number" : 6
} ]
}, {
"Name" : "pico for pathway",
"ID" : 5,
"Area" : {
"Name" : "Dining Room"
},
"Buttons" : [ {
"Number" : 2
}, {
"Number" : 3
}, {
"Number" : 4
}, {
"Number" : 5
}, {
"Number" : 6
} ]
} ],
"Zones" : [ {
"Name" : "ceiling lights",
"ID" : 2,
"Area" : {
"Name" : "Kitchen"
}
}, {
"Name" : "pathway",
"ID" : 4,
"Area" : {
"Name" : "Dining Room"
}
} ]
}
}
The wired switch (is it a switch or a dimmer?) will only show up as a switch zone, which based on your integration report looks like ID 2. So you can use a “switch” thing to control it and track what state it is set to, but the buttons on it won’t behave the same as a keypad. However, you could use a rule or a follow profile to set the state of other lights whenever the item connected to the switch’s “switchstate” channel is updated. The same holds true if it is a dimmer, except that you would use a “dimmer” thing and the “lightlevel” channel.
It’s a Lutron PD-6WCL dimmer, the one from the Lutron PDF I linked. So I added a Maestro dimmer with integration ID 2.
However, you could use a rule or a follow profile to set the state of other lights whenever the item connected to the dimmer’s “lightlevel” channel is updated. [Rephrased since I have a dimmer.]
So that allows me to know, say, when the lights are off (lightlevel of 0) or fully on (100), but that’s it, right? What I have done with the remote was detect a double tap on those buttons to turn the hue lights on/off synchronously. But I couldn’t do that with the dimmer’s lightlevel, because there is no change event once it’s at either 100% or 0%. I double tapped both buttons and logs seem to confirm that, as there was only one change each time.
2020-10-25 19:06:18.069 [vent.ItemStateChangedEvent] - Item 'Kitchenlightsdimmer_LightLevel' changed from 0.00 to 100.00
2020-10-25 19:06:20.890 [vent.ItemStateChangedEvent] - Item 'Kitchenlightsdimmer_LightLevel' changed from 100.00 to 0.00
Any creative suggestions (besides slapping a Pico keypad close to the dimmer, or (gasp) leaving the dimmer hanging in the wall and putting a Pico keypad in its place)?
I wish Lutron sold shallow switch/dimmer controllers behind a Pico keypad. That’d be fantastic: one could replace the face with any Pico keypad they care about, and it’d work both with the app and other integration solutions. They could sell one looking like their current offering, pre-paired. Why isn’t this a thing, or if it is, why can’t I find it? 
Also, you wrote previously:
BTW - The two models that Caseta supports are the -2B (for 2 button) and the -3BRL (for 3 button with raise/lower).
Just these two? If I look at the online site for the Pico models I see that they list a lot of keypads as compatible with Caseta: 2-Button, 2-Button with Raise/Lower, 3-Button, 3-Button with Raise/Lower, 3-Button with Raise/Lower for audio, 4-button, and their nightlight version which looks to be a 3-Button with Raise/Lower. That’s actually all of them listed as compatible with Caseta. Maybe that’s somewhat recent? Or errors from the marketing department?
Right. With the dimmer, all you get from it is the current level, from 0% to 100%. It won’t tell you specifically about presses of it’s buttons. With Lutron’s RadioRA 2 and HomeWorks QS systems you can buy a Hybrid seeTouch keypad, which is essentially a keypad with a dimmer integrated in to it. And I think with a HomeWorks system you can also configure it so that the buttons on any dimmer behave as a keypad, but they don’t support either of those in their lower-cost systems like Caseta and RA2 Select. Lutron is very annoying that way.
If you want scene buttons, I would probably recommend just mounting another Pico next to your current dimmer using the pico wallbox adapter. If you use one of their decora faceplates it’s pretty easy.
As for which Picos are supported, I’m not really sure. Their Caseta site just lists the 2B and various 3BRL models (which are all the same from the binding’s point of view), but the main Lutron site does list more models as being compatible with Caseta. I don’t have a Caseta system, so I’m not sure which is right. You may be able to tell from looking at their app, or maybe someone else here can say for sure.
Yes, it’s unfortunate. I picked Caseta not because of price but because the Pico remotes and their switches are the ones who matched my existing Lutron switches the best. It is however frustrating to see that they do less than my existing Lutron dimmers (e.g. I absolutely loved and used the ability to just long press a dimmer to control the delayed fade to off when leaving a room, and on the other hand dislike how Caseta has a hard wired fade time which is sluggish, and the Caseta fan control has only four speeds vs seven for Lutron, etc.). You’d think that they could add functionality, not remove.
But I also work for a big company who is well known for having inconsistent products and upgrades, so I think that may just be the way things are… It’s just disappointing when it seems that very little effort could have brought so much more versatility to a system.
I am sure there’s a market for a flexible dimmer box that fits recessed in a 1-gang and can be topped off by whatever plate and remote one wants.
I am going to play with other options for the switch side of the house, like exposing the Caseta lights through the hue emulation and using a hue Tap switch to include them as part of some scenes.
@BobA I just got a Caseta PD-3PCL smart plug-in light dimmer.
It shows up as:
{
"Name" : "Light bench",
"ID" : 6,
"Area" : {
"Name" : "Living Room"
}
}
and works beautifully when added as a Maestro Dimmer thing. Posting this for reference.
Well, if you use a RadioRA 2 or RA2 Select system, those support Maestro-style dimmers that are probably more like your older Lutron dimmers in that they will support double-tap to full on, press-and-hold for delayed off, and programmable fade times. However, even those systems will not communicate those actions to the hub. They only process them locally. I think only HomeWorks will communicate actions like those to its central processor(s) and let you base integration actions on them.
By the way, I believe there actually IS a way to adjust the fade times on the Caseta dimmers, but it is somewhat involved. You would need to set up the LEAP bridge and send some custom LEAP commands to do the configuration using the bridge’s debug channel.
But I also work for a big company who is well known for having inconsistent products and upgrades, so I think that may just be the way things are… It’s just disappointing when it seems that very little effort could have brought so much more versatility to a system.
I think all of us who work in high tech have been there 
, but I think Lutron has the same problem that a lot of high-end home automation vendors have. They sell most their high-end kit through custom installers, and all parties involved enjoy pretty good margins. This channel strategy also takes a lot of the support burden for the complex kit off of the equipment vendors. So when they come out with lower-cost systems that they sell directly to consumers, they feel that they need to limit them in some way in order to “protect” their higher-end systems and sales channels, and also to reduce their potential support costs. I think in the long run this is a self-defeating approach, but I do appreciate their predicament.
By the way, I believe there actually IS a way to adjust the fade times on the Caseta dimmers, but it is somewhat involved. You would need to set up the LEAP bridge and send some custom LEAP commands to do the configuration using the bridge’s debug channel.
I’m totally willing to do this :D. What’s interesting too is that apparently the fade time is more tolerable (i.e. faster) when I use the switch than when the command comes from the paired Pico keypad. I’ll have to investigate. I don’t think it’s a delay (like due to the bridge), it really seem that they use different fade durations…
I do understand the high end vs lower end predicament. At $120 for a Radio RA2 switch there should be enough margin for a few intermediaries, for sure! I also agree with you that it doesn’t seem like a smart long term strategy. I am already looking to see if I can find better switches and dimmers 
Though honestly if I can fix the fade times to be shorted and consistent I may call what I have good enough. I write software for a living, I don’t want to spend all my free time writing more software for lighting In any case it seems like the remotes are a good investment given I have the bridges because I could use them to trigger anything else I want.
I know that I ran across instructions on how to do this somewhere while I was researching the LEAP protocol, but now I can’t seem to find it again. You may want to try your own luck with google. There isn’t all that much info out there on LEAP, so the number of sites to choose from will be pretty limited. It may have been in one of the HA forums, or possible in an issue on github somewhere. In the meantime, I’ll keep looking.
I tend to like moderate fade-up times and fairly long fade-down times on my dimmers, but everyone has a different opinion in it. Have fun arguing about it with your family!