Sounds great!
Will this work when I’m importing the xml file rather than using auto-discovery?
Dan
Yes. If you set the discoveryFile parameter to reference a local XML file, the only difference in the discovery process is that it opens the local file instead of opening a HTTP connection to the bridge. I made sure of that, because I use the same mechanism for testing the discovery code. 
Hi. There were four new updates to the Lutron binding merged in to 2.5 recently:
-
It was reported that in some cases the Caseta PRO hub was returning malformed response strings, with the CLI prompt embedded somewhere in the middle of them. This is unfortunate behavior, especially since Caseta, unlike HomeWorks QS and RadioRA 2, seems to have no way to disable the CLI prompt. I’ve added some code to the bridge handler that detects this situation and repairs the mangled responses by removing the offending prompt string from them. All Caseta users will probably want to use this new code.
-
A Caseta user with a large system reported a problem where the Smarthub PRO seemed to be dropping some commands when a large number of integration commands were sent to it at once. In order to prevent this, a new
delayparameter for the bridge thing was introduced. It can be used to set a delay (in milliseconds) between transmission of integration commands to the bridge device for command send rate throttling. The parameter can be set to an integer value between 0 and 250 ms, and defaults to 0 (no delay). Some preliminary testing has shown that setting it to somewhere around 100 ms eliminates this “drop” problem. I’d be very interested to hear if others have encountered similar problems, and if so what the minimum delay value is that fixes them. Note that at this point I would probably not recommend setting a delay value unless you have encountered problems with commands being dropped, since it does (obviously) reduce the rate at which you can send commands. -
A fix was made to the shade handler so that the shadelevel channel will be properly updated with the current shade position when an Up or Down command is sent to the shade and it subsequently stops in the full up or full down position. In order for this to work, the shade handler now listens for the response code
~OUTPUT,<id>,32,2,<position>, which is sent by the bridge device to provide position updates. I know this works properly on RadioRA 2 systems. I would appreciate it if shade users with HomeWorks QS and Caseta systems could test it out and verify that it works on those as well. -
A significant change was made to the keypad handlers and to the discovery code. Now the discovery service will automatically determine the model of discovered keypads on RadioRA 2 and HomeWorks QS systems and set the model parameter for you. This should eliminate the mistakes and confusion that seemed to come from users having to select their keypad models after discovery. If you use configuration files instead of discovery, you will still have to set the model parameter for each keypad yourself. I would encourage everyone to please try this out, let me know if the keypad model discovery works properly for you, and more importantly let me know if you find any regressions in the keypad handlers. See the previous message regarding this for more info.
All of these changes are now available in snapshot builds newer than October 6th, and should also be in the upcoming M4 milestone build.
I have some additional enhancements to the Lutron binding in various stages of development. I would like to get these in to 2.5. The first to be ready for testing is discovery of Caseta and RA2 Select bridges via mDNS.
This new discovery service will discover and set properties for Caseta Pro and RA2 Select bridge devices similarly to the way the existing multicast discovery service does for RadioRA 2 and HomeWorks QS bridge devices. The properties set are: ipAddress, productFamily, productType, version, macAddress, and serialNumber. It also sets a label, which should include the model and host name.
The Caseta Smart Bridge Pro 2 should be identified by discovery as productFamily “Caseta” and productType “Smart Bridge Pro 2”. At the moment, RA2 Select and possibly other newer Lutron devices will probably be identified as productFamily: “Unknown” and productType “DEVCLASS nnnnnnnn” (where nnnnnnnn is a hex number which will vary from device type to device type).
In order for the final version of mDNS discovery to be able to correctly identify all bridge devices with which the binding is compatible, and to exclude devices with which it is NOT compatible, I need volunteers to test it out and report back with some details. I especially need to know the following:
- If mDNS discovery properly identifies all Caseta Smart Bridge Pro Gen 1 and Gen2 hubs, and if it sets the productFamily and productType properties correctly. It should report properties correctly for Gen 2 hubs, but may or may not for Gen 1.
- If mDNS discovery correctly finds all RA2 Select main repeaters, and what it sets productType to when it does. It should be a string of the form “DEVCLASS nnnnnnnn”.
- If mDNS discovery finds any Smart Bridge (non-Pro version) or Lutron Connect Bridges on your network. If it does, I’ll want to know the reported DEVCLASS numbers (or debug log details if there are none) so that these devices can be excluded from discovery results.
- If you encounter any other discovery issues, in which case I would probably need to see TRACE level log output from the binding (or at least the discovery service) in order to resolve them.
I really need the help of others to test this out, since I don’t have any of these devices myself. My testing so far has been limited to using simulated mDNS service announcements based on data collected from a friend’s network.
The beta jar file is available from github. It contains the 2.5.0.M4 version of the binding with only the new mDNS discovery service added.
Hi Bob,
I just got 2.5.4 running and have tried to do my Caseta running. I’ve been running RadioRa2 for a while. I get some debug messages so seems like it’s logged into the smart bridge:
2020-04-20 06:21:01.386 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message GNET> ~OUTPUT,4,1,35.00
2020-04-20 06:21:01.410 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~OUTPUT,2,1,35.00
2020-04-20 06:21:01.420 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~OUTPUT,3,1,35.00
Here are part of my things:
Bridge lutron:ipbridge:caseta[ ipAddress="172.26.77.142", user="lutron", password="integration" ] {
Thing switch partial [ integrationId=1 ]
Thing shade denshade1 [ integrationId=2 ]
Thing shade denshade2 [ integrationId=3 ]
Thing shade denshade3 [ integrationId=4 ]
}
And items:
Switch DenPartial { channel="lutron:switch:partial:switchstatus"}
Rollershutter DenShade1 { channel="lutron:shade:denshade1:shadelevel"}
Rollershutter DenShade2 { channel="lutron:shade:denshade2:shadelevel"}
Rollershutter DenShade3 { channel="lutron:shade:denshade3:shadelevel"}
But I’m not seeing these shades opening in the events.log file.
The auto discovery isn’t picking up the Caseta stuff either, but the commands you posted for mDNS do show it:
> avahi-browse -d local _lutron._tcp --resolve -tk
+ eth0 IPv6 Lutron Status _lutron._tcp local
+ eth0 IPv6 Lutron Status (2) _lutron._tcp local
+ eth0 IPv4 Lutron Status _lutron._tcp local
+ eth0 IPv4 Lutron Status (2) _lutron._tcp local
= eth0 IPv6 Lutron Status _lutron._tcp local
hostname = [lutron-xxxxxxxx.local]
address = [172.26.77.142]
port = [22]
txt = ["ST_STATUS=good" "NW_STATUS=InternetWorking" "FW_STATUS=1:NoUpdate" "DEVCLASS=08050100" "CODEVER=08.01.12f000" "MACADDR=xx:xx:xx:xx:xx:xx"]
= eth0 IPv6 Lutron Status (2) _lutron._tcp local
hostname = [lutron-xxxxxxxx.local]
address = [172.26.77.200]
port = [22]
txt = ["ST_STATUS=good" "NW_STATUS=InternetWorking" "FW_STATUS=1:NoUpdate" "DEVCLASS=08090301" "CODEVER=04.07.05f000" "MACADDR=xx:xx:xx:xx:xx:xx"]
= eth0 IPv4 Lutron Status _lutron._tcp local
hostname = [lutron-xxxxxxxx.local]
address = [172.26.77.142]
port = [22]
txt = ["ST_STATUS=good" "NW_STATUS=InternetWorking" "FW_STATUS=1:NoUpdate" "DEVCLASS=08050100" "CODEVER=08.01.12f000" "MACADDR=xx:xx:xx:xx:xx:xx"]
= eth0 IPv4 Lutron Status (2) _lutron._tcp local
hostname = [lutron-xxxxxxxx.local]
address = [172.26.77.200]
port = [22]
txt = ["ST_STATUS=good" "NW_STATUS=InternetWorking" "FW_STATUS=1:NoUpdate" "DEVCLASS=08090301" "CODEVER=04.07.05f000" "MACADDR=xx:xx:xx:xx:xx:xx"]
> avahi-browse -d local _hap._tcp --resolve -tk
+ eth0 IPv6 Lutron Connect Bridge _hap._tcp local
+ eth0 IPv6 Smart Bridge Pro 2 _hap._tcp local
+ eth0 IPv4 Lutron Connect Bridge _hap._tcp local
+ eth0 IPv4 Smart Bridge Pro 2 _hap._tcp local
= eth0 IPv4 Lutron Connect Bridge _hap._tcp local
hostname = [lutron-xxxxxxxx.local]
address = [172.26.77.200]
port = [4548]
txt = ["pv=1.1" "ci=2" "s#=1" "sf=0" "c#=20" "md=Lutron Connect Bridge" "id=xx:xx:xx:xx:xx:xx" "ff=1"]
= eth0 IPv6 Lutron Connect Bridge _hap._tcp local
hostname = [lutron-xxxxxxxx.local]
address = [172.26.77.200]
port = [4548]
txt = ["pv=1.1" "ci=2" "s#=1" "sf=0" "c#=20" "md=Lutron Connect Bridge" "id=xx:xx:xx:xx:xx:xx" "ff=1"]
= eth0 IPv4 Smart Bridge Pro 2 _hap._tcp local
hostname = [lutron-xxxxxxxx.local]
address = [172.26.77.142]
port = [4548]
txt = ["pv=1.1" "ci=2" "s#=1" "sf=0" "c#=23" "md=Smart Bridge Pro 2" "id=xx:xx:xx:xx:xx:xx" "ff=1"]
= eth0 IPv6 Smart Bridge Pro 2 _hap._tcp local
hostname = [lutron-xxxxxxxx.local]
address = [172.26.77.142]
port = [4548]
txt = ["pv=1.1" "ci=2" "s#=1" "sf=0" "c#=23" "md=Smart Bridge Pro 2" "id=xx:xx:xx:xx:xx:xx" "ff=1"]
Hi Paul. To really see what is going on with the shades you would need to set the logging level for the Lutron binding to TRACE. The ~OUTPUT messages you are getting from the shades do look like what the binding expects (assuming your shades really are integration IDs 2, 3, and 4 on your Caseta system). So at first glance I don’t see anything obviously wrong.
As for mDNS discovery of the Caseta, the TRACE level logging should help there as well. The log lines from LutronMdnsBridgeDiscoveryService should show what the discovery service is seeing. Just be aware that while it should discover the Caseta bridge, unlike with RadioRA 2 it can’t yet discover any of the Caseta devices connected to it.
If you want, you can send me the log info as a private message.
BTW - Your mDNS info was actually helpful to me because it contains the devclass number for a Connect Bridge, which I didn’t have before. So thanks for that!
I mainly put the mDNS stuff for your info, since I don’t really need the auto detect.
The trace level didn’t get much more (I closed one shade here):
2020-04-20 14:50:44.753 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message GNET> ~OUTPUT,4,1,0.00
2020-04-20 14:50:44.753 [TRACE] [lutron.internal.handler.ShadeHandler] - Shade 4 received zone level: 0.00
Also, here is a trace from the discovery:
2020-04-20 15:22:49.477 [DEBUG] [ry.LutronMcastBridgeDiscoveryService] - Scanning for Lutron bridge devices using multicast
2020-04-20 15:22:50.503 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: LUTRON : 2
2020-04-20 15:22:50.504 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: MACADDR : xxxxxxxxxxxx
2020-04-20 15:22:50.504 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: CMDREV : 3
2020-04-20 15:22:50.504 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: PRODFAM : RadioRA2
2020-04-20 15:22:50.504 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: PRODTYPE : MainRepeater
2020-04-20 15:22:50.504 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: DEVCLASS : 05010a01
2020-04-20 15:22:50.505 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: DEVTYPE : 0001
2020-04-20 15:22:50.505 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: HARDWAREREV : 0A
2020-04-20 15:22:50.505 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: MINCODEVER : 7.7.3
2020-04-20 15:22:50.505 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: OPMODE : 00
2020-04-20 15:22:50.505 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: NBNDEV : GULLIVER
2020-04-20 15:22:50.506 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: NBNMSTR : GULLIVER_001
2020-04-20 15:22:50.506 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: SERNUM : xxxxxxxx
2020-04-20 15:22:50.506 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: BORNONDAY : --/----
2020-04-20 15:22:50.506 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: CODEVER : 11.06.00
2020-04-20 15:22:50.506 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: BOOTCODEVER : 03.00.21
2020-04-20 15:22:50.507 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: FLASHUSE : 158458/1806336 (bytes), 8%
2020-04-20 15:22:50.507 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: RAMUSE : 1005380/3507120 (bytes), 28%
2020-04-20 15:22:50.507 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: IPADDR : 172.026.077.201
2020-04-20 15:22:50.507 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: SUBNETMK : 255.255.000.000
2020-04-20 15:22:50.507 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: GATEADDR : 172.026.077.001
2020-04-20 15:22:50.508 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: DNSADDR : 172.026.077.001
2020-04-20 15:22:50.508 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: ALTDNSADDR : 008.008.008.008
2020-04-20 15:22:50.508 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: IPLADDR : 239.010.237.146
2020-04-20 15:22:50.508 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: DOMADDR : 000.000.000.000
2020-04-20 15:22:50.509 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: DHCP : 0
2020-04-20 15:22:50.509 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: DEVADDR : 0001
2020-04-20 15:22:50.509 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: SYSADDR : 0001
2020-04-20 15:22:50.509 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: NBNUSER :
2020-04-20 15:22:50.509 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: TELPORT : 0017
2020-04-20 15:22:50.510 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: FTPPORT : 0015
2020-04-20 15:22:50.510 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: GUID : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2020-04-20 15:22:50.510 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: COMM MODE : 01
2020-04-20 15:22:50.510 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: PROJECT NAME : House
2020-04-20 15:22:50.510 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: IDPROC : 0
2020-04-20 15:22:50.511 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: RESET : 0
2020-04-20 15:22:50.511 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Bridge property: REMACCPORT : xxxx
2020-04-20 15:22:50.511 [DEBUG] [ry.LutronMcastBridgeDiscoveryService] - Discovered Lutron bridge device lutron:ipbridge:xxxxxxxx
2020-04-20 15:22:52.513 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Timed out waiting for multicast response. Presumably all bridge devices have already responded.
2020-04-20 15:23:45.349 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Scheduling keepalive reconnect job
2020-04-20 15:23:45.349 [TRACE] [ron.internal.handler.IPBridgeHandler] - Sending keepalive query
2020-04-20 15:23:45.350 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Sending command ?SYSTEM,10
2020-04-20 15:23:45.350 [TRACE] [ng.lutron.internal.net.TelnetSession] - TelnetSession writeLine called with ?SYSTEM,10
2020-04-20 15:23:45.352 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message GNET> ~SYSTEM,03/25/2020,22:22:15
2020-04-20 15:24:00.888 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Scheduling keepalive reconnect job
2020-04-20 15:24:00.888 [TRACE] [ron.internal.handler.IPBridgeHandler] - Sending keepalive query
2020-04-20 15:24:00.889 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Sending command ?SYSTEM,10
2020-04-20 15:24:00.889 [TRACE] [ng.lutron.internal.net.TelnetSession] - TelnetSession writeLine called with ?SYSTEM,10
2020-04-20 15:24:00.917 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~SYSTEM,02/19/2020,17:12:47
2020-04-20 15:28:45.350 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Scheduling keepalive reconnect job
2020-04-20 15:28:45.350 [TRACE] [ron.internal.handler.IPBridgeHandler] - Sending keepalive query
2020-04-20 15:28:45.351 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Sending command ?SYSTEM,10
2020-04-20 15:28:45.351 [TRACE] [ng.lutron.internal.net.TelnetSession] - TelnetSession writeLine called with ?SYSTEM,10
2020-04-20 15:28:45.353 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message GNET> ~SYSTEM,03/25/2020,22:22:15
2020-04-20 15:29:00.889 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Scheduling keepalive reconnect job
2020-04-20 15:29:00.889 [TRACE] [ron.internal.handler.IPBridgeHandler] - Sending keepalive query
2020-04-20 15:29:00.889 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Sending command ?SYSTEM,10
2020-04-20 15:29:00.890 [TRACE] [ng.lutron.internal.net.TelnetSession] - TelnetSession writeLine called with ?SYSTEM,10
2020-04-20 15:29:00.930 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~SYSTEM,02/19/2020,17:12:47
Well that trace message “Shade 4 received zone level: 0.00” means the position update message is being received and parsed right, and is making it to the right place in the shade handler. The very next line in the code updates the channel:
logger.trace("Shade {} received zone level: {}", getIntegrationId(), level);
updateState(CHANNEL_SHADELEVEL, new PercentType(level));
Are you sure that your items are configured properly? Do you see the state update in openhab’s event log?
Thanks. Hmm. All of the discovery messages are from LutronMcastBridgeDiscoveryService, which uses a UDP multicast to find RadioRA 2 repeaters and HomeWorks controllers. I don’t see anything from LutronMdnsBridgeDiscoveryService, which could mean that it either isn’t running for some reason, or it isn’t seeing anything from mDNS. Did your avahi-browse output come from the same host that openHAB is running on?
There’s no update in the event.log
The avahi-browse came from a different host. It was simplest to install on a raspberry pi, and I have openHAB running on a Synology. On one hand that shouldn’t matter, but the difference might really be that openHAB is running in a docker container.
I decided to try running avahi-browse in a docker container on the Synology. So it’s a different docker container from the one openHAB is in, but same host, and is a docker container (similar --net=host option too). It also worked there.
I also found this in the events.log, but nothing about the items changing:
2020-04-19 20:35:47.448 [.ItemChannelLinkAddedEvent] - Link 'DenPartial-lutron:switch:partial:switchstatus' has been added.
2020-04-19 20:35:47.448 [.ItemChannelLinkAddedEvent] - Link 'DenShade1-lutron:shade:denshade1:shadelevel' has been added.
2020-04-19 20:35:47.450 [.ItemChannelLinkAddedEvent] - Link 'DenShade2-lutron:shade:denshade2:shadelevel' has been added.
2020-04-19 20:35:47.451 [.ItemChannelLinkAddedEvent] - Link 'DenShade3-lutron:shade:denshade3:shadelevel' has been added.
2020-04-19 20:35:47.453 [.ItemChannelLinkAddedEvent] - Link 'LivingShade1-lutron:shade:livingshade1:shadelevel' has been added.
2020-04-19 20:35:47.454 [.ItemChannelLinkAddedEvent] - Link 'LivingShade2-lutron:shade:livingshade2:shadelevel' has been added.
2020-04-19 20:35:47.455 [.ItemChannelLinkAddedEvent] - Link 'LivingShade3-lutron:shade:livingshade3:shadelevel' has been added.
2020-04-19 20:35:47.456 [.ItemChannelLinkAddedEvent] - Link 'DiningShade1-lutron:shade:diningshade1:shadelevel' has been added.
2020-04-19 20:35:47.457 [.ItemChannelLinkAddedEvent] - Link 'DiningShade2-lutron:shade:diningshade2:shadelevel' has been added.
2020-04-19 20:35:47.458 [.ItemChannelLinkAddedEvent] - Link 'DiningShade3-lutron:shade:diningshade3:shadelevel' has been added.
That’s very strange. I don’t see any reason why it wouldn’t be working. Does sending a command to a shade work correctly?
Nope. I just tried a command for the first time. This is in events log:
2020-04-21 21:02:01.550 [ome.event.ItemCommandEvent] - Item 'MRKeypadL2' received command ON
2020-04-21 21:02:01.552 [ome.event.ItemCommandEvent] - Item 'LivingShade1' received command DOWN
2020-04-21 21:02:01.552 [nt.ItemStatePredictedEvent] - MRKeypadL2 predicted to become ON
2020-04-21 21:02:01.558 [nt.ItemStatePredictedEvent] - LivingShade1 predicted to become NULL
2020-04-21 21:02:01.558 [vent.ItemStateChangedEvent] - MRKeypadL2 changed from OFF to ON
I used a keypad button to control it, so the LED is turned on as the shade goes down. Not sure why it says predicted to become NULL.
The openlab log in that area:
2020-04-21 21:02:01.558 [DEBUG] [n.internal.handler.BaseKeypadHandler] - Handling command ON for channel lutron:keypad:mudroomkeypad:led2
2020-04-21 21:02:01.559 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Sending command #DEVICE,66,82,9,1
2020-04-21 21:02:01.559 [TRACE] [ng.lutron.internal.net.TelnetSession] - TelnetSession writeLine called with #DEVICE,66,82,9,1
2020-04-21 21:02:01.630 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,66,82,9,1
2020-04-21 21:02:01.630 [TRACE] [n.internal.handler.BaseKeypadHandler] - Handling command DEVICE [82, 9, 1] from keypad 66
2020-04-21 21:02:01.936 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~DEVICE,66,2,4
2020-04-21 21:02:01.936 [TRACE] [n.internal.handler.BaseKeypadHandler] - Handling command DEVICE [2, 4] from keypad 66
2020-04-21 21:03:45.621 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Scheduling keepalive reconnect job
2020-04-21 21:03:45.621 [TRACE] [ron.internal.handler.IPBridgeHandler] - Sending keepalive query
2020-04-21 21:03:45.621 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Sending command ?SYSTEM,10
2020-04-21 21:03:45.621 [TRACE] [ng.lutron.internal.net.TelnetSession] - TelnetSession writeLine called with ?SYSTEM,10
2020-04-21 21:03:45.623 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message GNET> ~SYSTEM,03/25/2020,22:22:15
2020-04-21 21:04:01.151 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Scheduling keepalive reconnect job
2020-04-21 21:04:01.151 [TRACE] [ron.internal.handler.IPBridgeHandler] - Sending keepalive query
2020-04-21 21:04:01.151 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Sending command ?SYSTEM,10
2020-04-21 21:04:01.152 [TRACE] [ng.lutron.internal.net.TelnetSession] - TelnetSession writeLine called with ?SYSTEM,10
2020-04-21 21:04:01.178 [DEBUG] [ron.internal.handler.IPBridgeHandler] - Received message ~SYSTEM,02/19/2020,17:12:47
It seems like this is showing ONLY the LED, plus housekeeping stuff. I guess that goes with the items not being updated from the shade. It’s like the items aren’t defined right, but yet those channel link messages seem to indicate they are.
Doing some snooping in the console. The first part here doesn’t seem right, but don’t know why. Comparing with some RadioRa2 lights below doesn’t show anything obvious that would be wrong with the shades.
openhab> smarthome:items list Living*
LivingShade3 (Type=RollershutterItem, State=NULL, Label=null, Category=null)
LivingShade1 (Type=RollershutterItem, State=NULL, Label=null, Category=null)
LivingShade2 (Type=RollershutterItem, State=NULL, Label=null, Category=null)
openhab> smarthome:items list Den
Den (Type=DimmerItem, State=50.70, Label=Light Level, Category=DimmableLight)
openhab> smarthome:links list | grep Living
LivingShade3 -> lutron:shade:livingshade3:shadelevel
LivingShade2 -> lutron:shade:livingshade2:shadelevel
LivingShade1 -> lutron:shade:livingshade1:shadelevel
openhab> smarthome:links list | grep Den
DenShade1 -> lutron:shade:denshade1:shadelevel
DenShade3 -> lutron:shade:denshade3:shadelevel
Den -> lutron:dimmer:den:lightlevel
DenShade2 -> lutron:shade:denshade2:shadelevel
DenPartial -> lutron:switch:partial:switchstatus
DenHall -> lutron:dimmer:denhall:lightlevel
Some more experiments in the console:
openhab> smarthome:things list | grep den
lutron:dimmer:den (Type=Thing, Status=ONLINE, Label=Maestro Dimmer, Bridge=lutron:ipbridge:)
lutron:keypad:denkeypad (Type=Thing, Status=ONLINE, Label=seeTouch Keypad, Bridge=lutron:ipbridge:)
lutron:dimmer:denhall (Type=Thing, Status=ONLINE, Label=Maestro Dimmer, Bridge=lutron:ipbridge)
lutron:shade:caseta:denshade2 (Type=Thing, Status=ONLINE, Label=Sivoia QS Shade, Bridge=lutron:ipbridge:caseta)
lutron:shade:caseta:denshade1 (Type=Thing, Status=ONLINE, Label=Sivoia QS Shade, Bridge=lutron:ipbridge:caseta)
lutron:shade:caseta:denshade3 (Type=Thing, Status=ONLINE, Label=Sivoia QS Shade, Bridge=lutron:ipbridge:caseta)
The caseta things have an extra “caseta” in the name here. So I added that to my item channel definitions, and it all works. Any idea why caseta and radiora2 are different that way?
I’m probably the wrong person to ask, as I am no expert on config file syntax. I tend to use the database instead. As far as I know, a thing that uses a bridge normally includes the bridge name (which I assume is “caseta” in your config), so I would expect that each item in your items file would need to include a channel reference of the form {channel="<bindingname>:<thingtype>:<bridgename>:<thingname>:<channel>"}. Maybe someone who plays around with config files more than I do can explain why a shorter form works for your RA2 items, but not for your caseta items. It’s probably related to the way the things are defined.
In any case, I’m glad you got the shades working! Are they behaving as expected now?
The only thing not working now is the scene. I put this in things (as above):
Thing switch partial [ integrationId=1 ]
Because the integration report has ID of 1. But looking closer it is the bridge device and needs to refer to a button, so a switch type isn’t right. I don’t see Caseta in the integration reference linked from the doc, so not sure exactly how to get to it. Keypad? Something special for it? Or maybe similar to main repeater phantom buttons? This is the part of the integration report:
"ID" : 1,
"Name" : "Smart Bridge 2",
"Buttons" : [
{
"Name" : "Partial Open",
"Number" : 1
},
Trying it like repeater buttons, the thing status shows:
lutron:virtualkeypad:caseta:casetabuttons (Type=Thing, Status=UNKNOWN: Awaiting initial response, Label=Virtual Keypad, Bridge=lutron:ipbridge:caseta)
So that doesn’t work.
I manually logged into my smart bridge and did the following:
GNET> #DEVICE,1,1,3
GNET> ~DEVICE,1,1,3
~OUTPUT,2,1,35.00
~OUTPUT,3,1,35.00
~OUTPUT,4,1,35.00
And this worked as expected. So what thing do I need to put in to get the binding to issue #DEVICE,1,1,3 ?