Lutron QSE-CL-NWK support

Hey there!

I’m trying to talk to the Lutron QSE-CL-NWK gateway with OpenHAB, using the Lutron binding and running into some errors. I do not have a Lutron system, however have worked with both Homeworks Illumiation and QS systems in a past life so have a baseline understanding of how it all fits together.

Reading through the Lutron Binding Thread it looks like @BobA and others needed tweaks to get the telnet conversation to work with their hardware, I’m pretty sure this is the case here - I’m able to control devices and see status without issue from a PuTTY telnet session to the Lutron device, but when OpenHAB tries it times out with errors.

Example LIP PuTTY session when monitoring for a SeeTouch keypad press:

login: nwk
connection established

My Bridge definition:

Bridge lutron:ipbridge:QSNNWK01 [ipAddress="", user="nwk"]

I think the command prompt differs as well as the login method (no password) resulting in the plugin looping while it times out over and over again, in a debug console I see it try to establish and never move past:

18:07:02.459 [INFO ] [del.core.internal.ModelRepositoryImpl] - Loading model 'lutron.things'
18:07:02.508 [TRACE] [] - Creating new TelnetSession
18:07:02.514 [DEBUG] [.lutron.internal.LutronHandlerFactory] - Registering discovery service.
18:07:02.560 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'lutron:ipbridge:QSNNWK01' changed from UNINITIALIZED to INITIALIZING
18:07:02.605 [DEBUG] [tron.internal.handler.IPBridgeHandler] - Connecting to bridge at
18:07:02.606 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'lutron:ipbridge:QSNNWK01' changed from INITIALIZING to OFFLINE: Connecting
18:07:02.612 [TRACE] [] - TelnetSession open called
18:07:02.628 [TRACE] [] - TelnetSession waitFor called with login: 0
18:07:02.634 [TRACE] [] - TelnetSession writeLine called with nwk
18:07:02.637 [TRACE] [] - TelnetSession waitFor called with password: 0
18:07:02.645 [DEBUG] [tron.internal.handler.IPBridgeHandler] - Received message connection established
18:07:02.648 [DEBUG] [tron.internal.handler.IPBridgeHandler] - Ignoring message connection established

Whats super weird is debug messages DO make it through to OpenHAB sometimes! from the logs when pressing a keypad button:

18:31:24.526 [DEBUG] [tron.internal.handler.IPBridgeHandler] - Received message QSE>~DEVICE,0x002a8ece,19,4
18:31:24.530 [DEBUG] [tron.internal.handler.IPBridgeHandler] - Ignoring message QSE>~DEVICE,0x002a8ece,19,4
18:31:24.538 [DEBUG] [tron.internal.handler.IPBridgeHandler] - Received message QSE>~DEVICE,0x002a8ece,19,4
18:31:24.543 [DEBUG] [tron.internal.handler.IPBridgeHandler] - Ignoring message QSE>~DEVICE,0x002a8ece,19,4

It discovers the bridge, but for some reason never shows as ONLINE:

18:55:25.892 [DEBUG] [.lutron.internal.LutronHandlerFactory] - Registering XML device discovery service.
18:55:25.915 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'lutron:ipbridge:QSNNWK01' changed from UNINITIALIZED to INITIALIZING
18:55:30.924 [WARN ] [.core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'lutron:ipbridge:QSNNWK01' takes more than 5000ms.
18:55:30.954 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'lutron:keypad:QSNNWK01:testKeypad' changed from UNINITIALIZED to UNINITIALIZED (BRIDGE_UNINITIALIZED)
19:18:40.063 [DEBUG] [ery.LutronMcastBridgeDiscoveryService] - Scanning for Lutron bridge devices using multicast
19:18:41.073 [TRACE] [ery.LutronMcastBridgeDiscoveryService] - Bridge property: LUTRON : 2
19:18:41.077 [TRACE] [ery.LutronMcastBridgeDiscoveryService] - Bridge property: MACADDR : 000FE70669DE
19:18:41.080 [TRACE] [ery.LutronMcastBridgeDiscoveryService] - Bridge property: CMDREV : 3
19:18:41.084 [TRACE] [ery.LutronMcastBridgeDiscoveryService] - Bridge property: PRODFAM : GRAFIK
19:18:41.087 [TRACE] [ery.LutronMcastBridgeDiscoveryService] - Bridge property: PRODTYPE : Interface
19:18:41.091 [TRACE] [ery.LutronMcastBridgeDiscoveryService] - Bridge property: DEVTYPE : 0042
19:18:41.094 [TRACE] [ery.LutronMcastBridgeDiscoveryService] - Bridge property: IPADDR :
19:18:41.098 [TRACE] [ery.LutronMcastBridgeDiscoveryService] - Bridge property: SUBNETMK :
19:18:41.101 [TRACE] [ery.LutronMcastBridgeDiscoveryService] - Bridge property: GATEADDR :
19:18:41.106 [TRACE] [ery.LutronMcastBridgeDiscoveryService] - Bridge property: TELPORT : 0017
19:18:41.110 [TRACE] [ery.LutronMcastBridgeDiscoveryService] - Bridge property: CODEVER : 08.60
19:18:43.117 [TRACE] [ery.LutronMcastBridgeDiscoveryService] - Timed out waiting for multicast response. Presumably all bridge devices have already responded.

Not sure what else to try; it feels like this binding is SO close to working…

Description of the NWK interface:

LIP Protocol:

kinda similar use case / PoC that this can be done and some quirks of the LIP protocol:

Had some time to poke around in the source for the Lutron binding and I think the bit of code that needs to be adjusted is in the public class IPBridgeHandler of

private static final String PROMPT_GNET = "GNET>";
private static final String PROMPT_QNET = "QNET>";
private static final String PROMPT_SAFE = "SAFE>";
private static final String LOGIN_MATCH_REGEX = "(login:|[GQ]NET>|SAFE>)";

since the QSE-CL-NWK returns a “QSE>” prompt not any of the above verbiage.

From then on, the protocol is standard LIP… The only other quirk I see is some of the monitoring types (SYSTEM,TIMECLOCK,MODE,SYSVAR,GROUP) do not apply… I am not a coder so unsure if that matters :smiley:

Suggest you open an issue on github with this info and tag @BobA

Done! issue opened here: [Lutron] Adding QSE-CL-NWK support to binding · Issue #14585 · openhab/openhab-addons · GitHub

I came up with a workaround in the Github thread. I do not have the coding skill to submit a PR but there is ample instruction for anyone who does :smiley:

Bridge comes online, responds to keypads, updates channels perfectly but will not show as ONLINE in the GUI.

Posting an update here since unsure what gets looked at more.

If this proves useful to anyone send me a message and I can forward along the .jar file.