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
~DEVICE,0x002a8ece,5,4
QSE>~DEVICE,0x002a8ece,4,3
QSE>~DEVICE,0x002a8ece,4,4
QSE>~DEVICE,0x002a8ece,18,3
QSE>~DEVICE,0x002a8ece,18,4
QSE>~DEVICE,0x002a8ece,18,4
QSE>
My Bridge definition:
Bridge lutron:ipbridge:QSNNWK01 [ipAddress="192.168.10.31", 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] [ing.lutron.internal.net.TelnetSession] - 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 192.168.10.31
18:07:02.606 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'lutron:ipbridge:QSNNWK01' changed from INITIALIZING to OFFLINE: Connecting
18:07:02.612 [TRACE] [ing.lutron.internal.net.TelnetSession] - TelnetSession open called
18:07:02.628 [TRACE] [ing.lutron.internal.net.TelnetSession] - TelnetSession waitFor called with login: 0
18:07:02.634 [TRACE] [ing.lutron.internal.net.TelnetSession] - TelnetSession writeLine called with nwk
18:07:02.637 [TRACE] [ing.lutron.internal.net.TelnetSession] - 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 : 192.168.010.031
19:18:41.098 [TRACE] [ery.LutronMcastBridgeDiscoveryService] - Bridge property: SUBNETMK : 255.255.255.000
19:18:41.101 [TRACE] [ery.LutronMcastBridgeDiscoveryService] - Bridge property: GATEADDR : 192.168.010.001
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…
Reference:
Description of the NWK interface:
LIP Protocol:
kinda similar use case / PoC that this can be done and some quirks of the LIP protocol:
https://response-box.com/gear/2021/08/the-most-bizarre-dmx-to-lutron-bridge-firmware-weve-ever-shipped/