Issue of the topic:
I’ve recently setup OH2 v2.4 on a test box I have to connect to a Lutron Radio RA 2 Master Controller. I’ve followed the Installation guide under the documentation and started w/ Item Linking set to Simple and using just the Paper UI to auto-discover Things and auto-create Channels.
I’ve added the Lutron Bindings and then manually added the Lutron IP Access Point (lutron:ipbridge) configured to connect to the Radio RA 2 Master. This all appears to work and I’ve been able to auto-discover dimmers and keypads without issue. I can control the dimmers in the Paper UI.
What I can’t get to work is read the various dimmers status as they all show “UNKNOWN Awaiting initial response”. The Lutron IP Access Point shows the status of online so I’m expecting for most everything else Lutron-related to provide a status as well. Is this a wrong assumption?
I’ve enabled debugging for the Lutron binding but it’s not revealing anything meaningful.
Today, I upgraded to OH2 v2.5 after finding an announcement that the v2.5 binding has several fixes. After the upgrade the system behaves the same and no current status is displayed for the dimmers.
Where do I start to debug this and sort this issue?
*Things listing from console
lutron:ipbridge:909ab090 (Type=Bridge, Status=ONLINE, Label=Lutron IP Access Point, Bridge=null)
lutron:dimmer:909ab090:11 (Type=Thing, Status=UNKNOWN: Awaiting initial response, Label=Rear Flood Ligths, Bridge=lutron:ipbridge:909ab090)
Hi Scott. That’s strange. When each Lutron thing handler (e.g. dimmer) starts up, it queries its corresponding device for its current status. It will stay in that “Awaiting initial response” state until it gets a response back. Most often if a thing is stuck in that state it means that the wrong integration ID has been set for it. If you are using discovery to configure your things, that is less likely. If ALL of your Lutron things are in that state, it could also be a sign of some sort of communication problem, although usually that would result in your bridge status being offline as well.
Is there a reason that your RadioRA 2 main repeater wasn’t auto-discovered as well? Just for debugging purposes, you may want to try deleting all of your Lutron things (from config files and the DB, including the bridge), and re-discovering everything. Let discovery find the main repeater, then accept that, set the password if necessary, and then let discovery find all of the attached devices again.
If you still have problems after that, try setting the logging level for the Lutron binding to “TRACE” and send me the log output. I’ll probably be able to tell what is wrong by looking at that.
One other thing - Can you successfully telnet to and log in to your main repeater from the system that you are running openHAB on?
My home network isn’t a flat subnet as I’ve separated wired and wireless devices/clients as well as servers in to different subnets. The spare system i’m testing OH2 on is sitting in one subnet and the RadioRA 2 main repeater is in a different subnet with a layer-3 switch between the two. This is why discovery of the main repeater didn’t work as subnet broadcasts aren’t routed (usually). Are device status updates done via broadcasts from the main repeater? If so, that would explain my issue straight away.
After I posted, I did exactly what you suggested and deleted all Lutron devices and the IP bridge and created them again but with the same results. I had to manually add the IP bridge but everything else
was auto-discovered.
I can telnet and login into the main repeater as well as login via a browser. I also have the configuration software for Radio RA 2 repeater so I can make changes as required, if that’s needed.
I’ll switch the logging to TRACE and send you the output in a bit.
Here’s the trace output and the answer to my problem.
# tail -f openhab.log | grep TRACE
2019-12-22 21:23:07.788 [TRACE] [ng.lutron.internal.net.TelnetSession] - TelnetSession writeLine called with ?OUTPUT,30,1
2019-12-22 21:24:05.388 [TRACE] [ry.LutronMcastBridgeDiscoveryService] - Timed out waiting for multicast response. Presumably all bridge devices have already responded.
It appears that status updates are done via broadcasts/multicasts. So that means I’ll have to move the test system and the main repeater to the same subnet.
Let me do that and try the full auto-discovery and see what results I get.
Hi Scott. No, you shouldn’t need multicast support for normal communications with the main repeater. That is done via a single persistent TCP (telnet) connection. The “Timed out waiting for multicast response” message you see in the log is from LutronMcastBridgeDiscoveryService, which uses UDP multicasts to find RA2 main repeaters and HomeWorks QS processors on the network. That obviously won’t work across multicast domains, but it should only impact discovery.
The “?OUTPUT,30,1” message you see in the log is the binding requesting the state of the output device with integration ID 30. Does it ever get a response? You can try typing that same command in to a telnet session and see what you get back. Offhand, I think it should be something like “~OUTPUT,30,1,100” if that dimmer is on to 100%.
I moved the main repeater to the same subnet as the test system. I deleted all the Lutron things (including the IP bridge) and then did auto-discovery. It found the main repeater and 20+ things populated in the Inbox. I’ve added a few Things via the Inbox and the status is updating and showing online. If I manually turn on a wall dimmer, the light percentage is shown in the Paper UI Control panel. It appears that everything is working.
I did telnet into the repeater and logged in a few times and got inconsistent results. The first time I logged in and at the GNET> prompt I entered “?OUTPUT,30,1” and hit enter but got no response. On the next two telnet tries, I didn’t even get prompted to login. Not sure what’s going on with that. Any ideas?
It sounds like there is something strange going on with your repeater. You should try rebooting it, if you haven’t already. If that doesn’t help, I would try reloading the configuration on to it with the RA2 programming software. I’ve had that clear up strange behavior for me once or twice.
What version of the Lutron software are you running?
I think I’ve sorted some of my issues of which there appears to be two. With the upgrade to OH 2.5, one of the bindings I’d loaded to try (networkupstool1) wasn’t loaded and failed to install. Also, the RA 2 is configured with switch/dimmers that don’t exist physically. It appears the previous home owners changed their minds on all the switches and dimmers they wanted to install but they weren’t removed from the configuration.
Once I manually removed the binding that was failing to load and rest the RA 2 main repeater, everything started behaving. This also fixed the Z-wave issues where the controller kept timing out and resetting. I presume the attempt to load the failed binding was messing w/ the timing loop and the comms got out of sync so signals were missed.
