Hi. I’ve been working on an update to the Lutron binding that should, among other things, support the standard (non-Pro) version of the Caseta Smart Bridge. The current binding only supports the Smart Bridge Pro. Is there anyone out there who has the standard Smart Bridge and is willing to try it out with an alpha version of the binding?
I have the standard smart bridge and would be willing to test out the alpha binding. I have been anxious to see if anyone could pick up support for the standard bridge so this is awesome. Thank you for taking this on.
That’s great! The support is in the form of a new bridge (leapbridge) for the existing Lutron binding. The existing ipbridge uses Lutron Integration Protocol (LIP), which is supported by HomeWorks QS, RadioRA 2, RA2 Select, and Caseta Smart Bridge Pro, but not by Caseta Smart Bridge. There is a newer protocol called LEAP that is supported by both Caseta bridge models and also by RA2 Select. The new leapbridge should theoretically work with all of those, but so far has only been tested with Caseta Smart Bridge Pro and RA2 Select.
It’s still an alpha version at this point. Once I think it is beta quality I’ll post a link to it here, but for now I’ll send you the link in a PM.
i would be interesting in trying it out too, thanks for working on this!
Sure! I’ll send you the link. @GBear09 reported that it worked on his system, so hopefully it will work for you as well.
The beta version of LEAP support is finally available! You can download the beta1 version of the updated binding here:
It will primarily be of interest if you have a Caseta Smart Bridge, Smart Bridge Pro, or RA2 Select system. However, because of all of the changes, I would appreciate it if people with RadioRA 2 and HomeWorks QS systems could try it out as well. Those systems can also take advantage of the new fan and ogroup things for ceiling fan controllers and occupancy groups.
I also have a standard Smart Bridge. I was able to get the keystore set up and successfully use the beta binding to connect to the Smart Bridge and discover the devices connected to it. However, the bridge enters “OFFLINE: Initializing” and never progresses, so the discovered devices aren’t usable.
I am admittedly new to OpenHAB, but browsing the handler class, I see that the only call there to update status to ThingStatus.ONLINE is in LeapBridgeHandler.checkInitialized(), but the only upstream callers I can find are parseMultipleDeviceDefinition() and parseMultipleButtonGroupDefinition() read response handlers.
Am I just missing something?
Hi. Yes, the LEAP bridge handler needs to receive and process the device and button group definitions from the Smart Bridge before it will set its status to online, but that should happen in less than a second. It’s a bit hard to say what might be going wrong without getting a look at the logs. It sounds like communications is working, since you were able to discover devices, and that happens over the same connection as everything else.
Try looking in your log file for messages related to the lutron binding (org.openhab.binding.lutron). If you don’t see any obvious errors, try setting the logging level for org.openhab.binding.lutron to TRACE. That will dump details about every message exchanged with the hub, and you’ll be able to see what is going on as it starts up. You can post that section of the log here, or send it to me in a private message, and I’ll probably be able to tell what is going wrong.
Here is a filtered log slice from adding the bridge Thing via a thing config file.
2020-09-21 21:37:35.173 [DEBUG] [n.internal.handler.LeapBridgeHandler] - Disconnecting
2020-09-21 21:37:35.177 [DEBUG] [n.internal.handler.LeapBridgeHandler] - Command sender thread exiting
2020-09-21 21:37:35.185 [DEBUG] [n.internal.handler.LeapBridgeHandler] - I/O error while reading from stream: Socket closed
2020-09-21 21:37:35.190 [DEBUG] [n.internal.handler.LeapBridgeHandler] - Message reader thread exiting
2020-09-21 21:37:45.603 [TRACE] [n.internal.handler.LeapBridgeHandler] - Initializing keystore
2020-09-21 21:37:45.607 [TRACE] [n.internal.handler.LeapBridgeHandler] - Initializing SSL Context
2020-09-21 21:37:45.631 [DEBUG] [n.internal.handler.LeapBridgeHandler] - Opening SSL connection to 192.168.1.239:8081
2020-09-21 21:37:45.731 [TRACE] [n.internal.handler.LeapBridgeHandler] - Registered child handler for ID 2
2020-09-21 21:37:45.801 [TRACE] [n.internal.handler.LeapBridgeHandler] - Registered child handler for ID 1
2020-09-21 21:37:45.881 [DEBUG] [n.internal.handler.LeapBridgeHandler] - Message reader thread started
2020-09-21 21:37:45.898 [DEBUG] [n.internal.handler.LeapBridgeHandler] - Command sender thread started
2020-09-21 21:37:45.899 [DEBUG] [n.internal.handler.LeapBridgeHandler] - Starting keepAlive job with interval 5
2020-09-21 21:37:45.900 [TRACE] [n.internal.handler.LeapBridgeHandler] - Sending command {"CommuniqueType": "ReadRequest","Header": {"Url": "/device"}}
2020-09-21 21:37:45.904 [TRACE] [n.internal.handler.LeapBridgeHandler] - Sending command {"CommuniqueType": "ReadRequest","Header": {"Url": "/buttongroup"}}
2020-09-21 21:37:45.904 [TRACE] [n.internal.handler.LeapBridgeHandler] - Received message: {"CommuniqueType":"SubscribeResponse","Header":{"StatusCode":"204 NoContent","Url":"/device/status/deviceheard"}}
2020-09-21 21:37:45.906 [TRACE] [n.internal.handler.LeapBridgeHandler] - Sending command {"CommuniqueType": "ReadRequest","Header": {"Url": "/area"}}
2020-09-21 21:37:45.907 [DEBUG] [n.internal.handler.LeapBridgeHandler] - Received CommuniqueType: SubscribeResponse
2020-09-21 21:37:45.908 [TRACE] [n.internal.handler.LeapBridgeHandler] - Sending command {"CommuniqueType": "ReadRequest","Header": {"Url": "/occupancygroup"}}
2020-09-21 21:37:45.909 [TRACE] [n.internal.handler.LeapBridgeHandler] - No MessageBodyType in header
2020-09-21 21:37:45.910 [TRACE] [n.internal.handler.LeapBridgeHandler] - Sending command {"CommuniqueType": "SubscribeRequest","Header": {"Url": "/occupancygroup/status"}}
2020-09-21 21:37:45.911 [TRACE] [n.internal.handler.LeapBridgeHandler] - Received message: {"CommuniqueType":"SubscribeResponse","Header":{"StatusCode":"204 NoContent","Url":"/zone/status/deprecated/level"}}
2020-09-21 21:37:45.914 [DEBUG] [n.internal.handler.LeapBridgeHandler] - Received CommuniqueType: SubscribeResponse
2020-09-21 21:37:45.915 [TRACE] [n.internal.handler.LeapBridgeHandler] - No MessageBodyType in header
2020-09-21 21:37:45.942 [TRACE] [n.internal.handler.LeapBridgeHandler] - Received message: {"CommuniqueType":"ReadResponse","Header":{"MessageBodyType":"MultipleDeviceDefinition","StatusCode":"200 OK","Url":"/device"},"Body":{"Devices":[{"href":"/device/1","Name":"Smart Bridge 2","FullyQualifiedName":["Smart Bridge 2"],"Parent":{"href":"/project"},"SerialNumber":52396370,"ModelNumber":"L-BDG2-WH","DeviceType":"SmartBridge","RepeaterProperties":{"IsRepeater":true},"LinkNodes":[{"href":"/device/1/linknode/1"}],"DeviceRules":[{"href":"/devicerule/40"}],"FirmwareImage":{"Firmware":{"DisplayName":"08.03.05f000"},"Installed":{"Year":2018,"Month":12,"Day":5,"Hour":18,"Minute":10,"Second":57,"Utc":"-5:00:00"}}},{"href":"/device/2","Name":"Main Lights","FullyQualifiedName":["Office","Main Lights"],"Parent":{"href":"/project"},"SerialNumber":52029832,"ModelNumber":"PD-6WCL-XX","DeviceType":"WallDimmer","LocalZones":[{"href":"/zone/1"}],"AssociatedArea":{"href":"/area/2"},"LinkNodes":[{"href":"/device/2/linknode/2"}],"DeviceRules":[{"href":"/devicerule/27"}]}]}}
2020-09-21 21:37:45.944 [DEBUG] [n.internal.handler.LeapBridgeHandler] - Received CommuniqueType: ReadResponse
2020-09-21 21:37:45.947 [TRACE] [n.internal.handler.LeapBridgeHandler] - MessageBodyType: MultipleDeviceDefinition
2020-09-21 21:37:45.962 [TRACE] [n.internal.handler.LeapBridgeHandler] - Found device: Smart Bridge 2 id: 1 zone: 0
2020-09-21 21:37:45.969 [TRACE] [n.internal.handler.LeapBridgeHandler] - Found device: Main Lights id: 2 zone: 1
2020-09-21 21:37:46.007 [TRACE] [n.internal.handler.LeapBridgeHandler] - Received message: {"CommuniqueType":"ReadResponse","Header":{"StatusCode":"204 NoContent","Url":"/buttongroup"}}
2020-09-21 21:37:46.009 [DEBUG] [n.internal.handler.LeapBridgeHandler] - Received CommuniqueType: ReadResponse
2020-09-21 21:37:46.011 [TRACE] [n.internal.handler.LeapBridgeHandler] - No MessageBodyType in header
2020-09-21 21:37:46.074 [TRACE] [n.internal.handler.LeapBridgeHandler] - Received message: {"CommuniqueType":"ReadResponse","Header":{"MessageBodyType":"MultipleAreaDefinition","StatusCode":"200 OK","Url":"/area"},"Body":{"Areas":[{"href":"/area/1","Name":"root","LoadShedding":{"href":"/area/1/loadshedding"}},{"href":"/area/2","Name":"Office","Parent":{"href":"/area/1"},"Category":{"Type":"Office"},"AssociatedDevices":[{"href":"/device/2"}],"AssociatedOccupancyGroups":[{"href":"/occupancygroup/1"}],"LoadShedding":{"href":"/area/2/loadshedding"},"OccupancySettings":{"href":"/area/2/occupancysettings"},"OccupancySensorSettings":{"href":"/area/2/occupancysensorsettings"},"DaylightingGainSettings":{"href":"/area/2/daylightinggainsettings"}}]}}
2020-09-21 21:37:46.077 [DEBUG] [n.internal.handler.LeapBridgeHandler] - Received CommuniqueType: ReadResponse
2020-09-21 21:37:46.078 [TRACE] [n.internal.handler.LeapBridgeHandler] - MessageBodyType: MultipleAreaDefinition
2020-09-21 21:37:46.080 [TRACE] [n.internal.handler.LeapBridgeHandler] - Parsing area list
2020-09-21 21:37:46.094 [TRACE] [n.internal.handler.LeapBridgeHandler] - Received message: {"CommuniqueType":"ReadResponse","Header":{"MessageBodyType":"MultipleOccupancyGroupDefinition","StatusCode":"200 OK","Url":"/occupancygroup"},"Body":{"OccupancyGroups":[{"href":"/occupancygroup/1","AssociatedAreas":[{"Area":{"href":"/area/2"}}],"ProgrammingType":"Freeform","ProgrammingModel":{"href":"/programmingmodel/126"}}]}}
2020-09-21 21:37:46.095 [DEBUG] [n.internal.handler.LeapBridgeHandler] - Received CommuniqueType: ReadResponse
2020-09-21 21:37:46.097 [TRACE] [n.internal.handler.LeapBridgeHandler] - MessageBodyType: MultipleOccupancyGroupDefinition
2020-09-21 21:37:46.099 [TRACE] [n.internal.handler.LeapBridgeHandler] - Parsing occupancy group list
2020-09-21 21:37:46.109 [TRACE] [n.internal.handler.LeapBridgeHandler] - Received message: {"CommuniqueType":"SubscribeResponse","Header":{"MessageBodyType":"MultipleOccupancyGroupStatus","StatusCode":"200 OK","Url":"/occupancygroup/status"},"Body":{"OccupancyGroupStatuses":[{"href":"/occupancygroup/1/status","OccupancyGroup":{"href":"/occupancygroup/1"},"OccupancyStatus":"Unknown"}]}}
2020-09-21 21:37:46.112 [DEBUG] [n.internal.handler.LeapBridgeHandler] - Received CommuniqueType: SubscribeResponse
2020-09-21 21:37:46.113 [TRACE] [n.internal.handler.LeapBridgeHandler] - MessageBodyType: MultipleOccupancyGroupStatus
2020-09-21 21:37:46.115 [TRACE] [n.internal.handler.LeapBridgeHandler] - Parsing occupancy group status list
2020-09-21 21:37:46.119 [DEBUG] [n.internal.handler.LeapBridgeHandler] - OccupancyGroup: 1 Status: Unknown
2020-09-21 21:37:46.121 [TRACE] [n.internal.handler.LeapBridgeHandler] - Group 1 state update: Unknown
2020-09-21 21:37:46.122 [DEBUG] [n.internal.handler.LeapBridgeHandler] - No group thing configured for group ID 1
2020-09-21 21:42:45.902 [TRACE] [n.internal.handler.LeapBridgeHandler] - Sending keepalive query
2020-09-21 21:42:45.905 [TRACE] [n.internal.handler.LeapBridgeHandler] - Sending command {"CommuniqueType": "ReadRequest","Header": {"Url": "/server/1/status/ping"}}
2020-09-21 21:42:45.911 [TRACE] [n.internal.handler.LeapBridgeHandler] - Received message: {"CommuniqueType":"ReadResponse","Header":{"MessageBodyType":"OnePingResponse","StatusCode":"200 OK","Url":"/server/1/status/ping"},"Body":{"PingResponse":{"LEAPVersion":1.113}}}
2020-09-21 21:42:45.913 [DEBUG] [n.internal.handler.LeapBridgeHandler] - Received CommuniqueType: ReadResponse
2020-09-21 21:42:45.915 [TRACE] [n.internal.handler.LeapBridgeHandler] - Canceling scheduled reconnect job.
2020-09-21 21:42:45.916 [TRACE] [n.internal.handler.LeapBridgeHandler] - MessageBodyType: OnePingResponse
2020-09-21 21:42:45.918 [DEBUG] [n.internal.handler.LeapBridgeHandler] - Ping response received
At first glance, it looks like I’m getting MultipleAreaDefinition and MultipleOccupancyGroupDefinition responses only instead of the expected MultipleButtonGroupDefinition and MultipleDeviceDefinition.
Actually, on closer inspection, it looks like I do get the device list response MultipleDeviceDefinition, but the request for button groups is returning a No Content response instead of the expected response type MultipleButtonGroupDefinition.
So the buttonDataLoaded flag is never set to true, and thus checkInitialized never passes the check to set status to ThingStatus.ONLINE.
The Caseta Dimmer that is paired to the bridge is setup as a switch to a light in a room in the app (not just an unconfigured device). I also tried adding a scene to see if I could get button groups to populate, but no luck.
I am not familiar with the API spec for the Smart Bridge, but would it make sense to recognize the No Content response for Url="/buttongroup" as a valid, empty response?
Yes, that makes sense. That probably is what’s happening. It should handle that case, obviously, but it probably hadn’t been tested on a system that didn’t return any buttons before. That’s why it’s still in beta. 
Adding scenes won’t help, because they show up as virtual buttons rather than buttons. Don’t ask why the hub draws a distinction. I’ll try to push an update tonight that should fix it.
No worries. Glad I could help tease out the edge case. 
I’ve just released the beta2 version of the Lutron binding with LEAP bridge support. It’s available here:
There are only two changes since the beta1 build:
- Fixed the bug found by @jbender where the bridge would not initialize if no keypads existed in the system and thus no button groups were defined.
- Added a new “trusting” boolean parameter to the bridge that disables validation of the server SSL certificate. This can cause problems when connecting if, for example, you are using a hostname for the bridge device that does not match its internal hostname. This only seemed to be an issue when using a hostname in the leapbridge configuration rather than an IP address.
I will continue to build these beta versions for OH 2.5, but LEAP support will probably not make it in to an official 2.5.x release because major new features are only being added to the 3.0 branch at this point. I’m hoping to have a beta build available for OH 3.0 soon, and LEAP support will eventually be merged in for the OH 3.0 release later this year.
I’ve pulled the code down and will update next time I restart OH. I don’t think either fix applies to my system however so I doubt I will see a change.
I’ve updated the leap-beta2 release on github and added a build for openHAB 3.0. If any of you are testing 3.0, please try it out!
I’ve finally created a PR (#8650) for adding LEAP protocol support to the Lutron binding! Development of addons is happening against the main branch now, so the the PR is targeting 3.0 rather than a 2.5.x release.
I’m having a weird issue, not sure if this is a bug or not. I came back from vacation and noticed the caseta thing is showing as offline. That being said, it’s working just fine (getting state changes, sending commands, etc all work). In going to try to find the messages in the logs but they may have aged out by now. My OH has been up about 2 weeks since my last restart.
That is odd! What is the full status for the bridge thing? It should say why it is offline. And are you sure there isn’t another bridge thing configured somewhere that is being used?
Logs would definitely help if you still have 'em.
This is what I can find in the logs:
2020-10-08 15:18:56.561 [hingStatusInfoChangedEvent] - ‘lutron:leapbridge:bridge1’ changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): reconnecting
2020-10-08 15:18:56.770 [hingStatusInfoChangedEvent] - ‘lutron:leapbridge:bridge1’ changed from OFFLINE (COMMUNICATION_ERROR): reconnecting to OFFLINE: Initializing
2020-10-08 15:18:56.782 [hingStatusInfoChangedEvent] - ‘lutron:leapbridge:bridge1’ changed from OFFLINE: Initializing to OFFLINE (COMMUNICATION_ERROR): Socket closed
I didn’t have debug or trace logging turned on so I didn’t catch anything magical otherwise. That being said, everything was working when I got home so I assume it did reconnect and just didn’t report the thing being online.
Do you have any debug logs? It’s hard to tell what may have happened from that, except that it looks like communication with the hub was interrupted twice. I would expect to see some other errors before those log entries, and one or more connection retries after.