Getting state back from Lutron Equipement

I am currently setting up a Lutron Homeworks QS processor within openHab 3.
I am having trouble getting back the states of some dimmers and more annoying I cannot figure out how to get events when a physical button is clicked. The button is within a Pico Keypad.

Is it possible to get an openHab event when I press the button ? And how can I get the state of the lamp ?
I know I can get those information via the telnet interface of the processor but I would like to keep everything within openhab.

Hi. Yes, the binding should do all of those things with Homeworks. You should get button push events when a keypad button is pressed, and all dimmer states should update automatically. Are you sure you’ve created the right things and items?

You should see updates in the event log. If not, you can turn on debug logging in the binding and you will see the events coming from the Homeworks system.

Homeworks systems can be very complex, and sometimes there may be a device for which support hasn’t yet been added. Was auto-discovery able to find all of your devices automatically? Did it log any messages about devices it didn’t recognize?

You have to make sure that all of the devices you are interested in interacting with are enabled for integration in Homeworks, and also that the monitoring defaults are configured correctly for the account you are using to access the system.

1 Like

Thanks a lot for your answers, I am using the Lutron IP Access Point and with auto discovery I can see all of my things with no error messages. I have created all my things and items via the auto discovery and the proposed items.
Here is a example of on off my dimmer things with its channels

Regarding the events I see none in the event log, how may I turn on the debug logging on the bindings?

I will also check that I have the correct rights on the account I am using.

You can turn on debug or trace level logging for the Lutron binding in several ways. The easiest is probably to go in to the console and use the command “log:set TRACE org.openhab.binding.lutron”. Later you can set it back to the default (INFO level) using the console command “log:set INFO org.openhab.binding.lutron”.

From the way you describe your issue, I suspect that the problem may be that monitoring isn’t set right for the Homeworks user you are connecting as. If that’s the case, you won’t see an update coming in when you manually press a button or change the level on a dimmer.

So after much investigating I managed to get the states back from the homeworks qs but only via the telenet protocol. I am still stuck without event on the openhab event bus no mater the monitoring state I put in via telenet.
I am using the same account in telnet and openhab. So I guess the problem comes from somewhere else.

Hi. The binding uses the same telnet protocol, assuming you are using ipbridge, so any events you see with a telnet connection the binding should also be able receive and process. You are using ipbridge, right?

What did you have to do to see the right messages via telnet? Did you need to enter a specific monitoring command? And what do you see in the binding’s debug or trace logging?

BTW - When you telnet in to the homeworks processor for testing, use a regular terminal program rather than Lutron’s utility. As I recall, that may modify the monitoring config on its own, which may end up confusing you.

I am indeed using the ipbridge. In order to see the correct message on my telenet terminal I need to run the #MONITORING commands whenever I connect to the processor.

How can I tell the binding to run the commands ?

Ok. That’s the problem. What classes of monitoring did you need to turn on? I don’t have a HomeWorks system, but I think the problem may be that you are using a user login instead of an admin login. An admin login will have a different set of monitoring defaults. In the past everyone just used the default “lutron” account for integration, which I believe was an admin. As I recall, newer versions of the software encourage you to set up alternate users at configuration time, but they probably don’t default to admin.

I thinks that I am using an admin account but not the root account. I am not the one who installed/configure the processor this is the only account I have access to.
I can either turn on every monitoring or choose them one by one. Having the option to toggle them on and off would be wonderful but just a way to turn them all on (with the command #MONITORING,255,1) would still help me so much.
Do you think this is something you could add ?

Hi. Yes, I’ll look at adding an option to the bridge to enable the proper monitoring types at connect time. I’d rather not turn on all (255), though, since that can unnecessarily overload the connection. Plus there are some that should be off.

Can you log in to your processor and send “?MONITORING” and “?MONITORING,255” commands and send me the output?

The binding already handles turning on or off a few monitoring types when necessary, like prompt (12) and maybe system variable (10). I think the minimum that need to be on, and should normally be on by default, are types 3,4,5,6,9,11, and maybe 18.

Here are the outputs from the commands, these are the default value I have on my account:

Displays which monitoring messages this user subscribes to.
USAGE: ?MONITORING or ?MONITORING,255 -- Displays the subscription status for all monitoring types
       ?MONITORING,<TYPE> -- Displays subscription status for the specified monitoring type.

Monitoring Types:
 1 = Diagnostic Monitoring
 2 = Event Monitoring
 3 = Button Monitoring
 4 = LED Monitoring
 5 = Zone Monitoring
 6 = Occupancy Monitoring
 7 = Photosensor Monitoring
 8 = Scene Monitoring
 9 = Time Clock Monitoring
10 = System Variable Monitoring
11 = Reply State
12 = Prompt State 
14 = Device State Monitoring
16 = Sequence Monitoring
17 = HVAC Monitoring
18 = Mode Monitoring
19 = Preset Transfer Monitoring
20 = L1 Runtime Property Update Monitoring
21 = L2 Runtime Property Update Monitoring
22 = Diag Error Monitoring
23 = Shade Group Monitoring
24 = Partition wall Monitoring
25 = System Monitoring
26 = Hyperion Sensor Grouping Monitoring
27 = Temperature Sensor Monitoring

Status: 1 = enabled, 2 = disabled

The event you are proposing seems like the most essential indeed

Hi. I’ve built a test version of the binding containing code that explicitly enables the right monitoring types at connection init time. You should be able to download it here:

You’ll probably have to uninstall your current Lutron binding first, and then drop the jar file in your addons directory.

Please test it out and let me know if it works. It is built on the latest development branch (3.2.0-SNAPSHOT), but I’m assuming it will work on 3.1 as well.

I have tried copy pasting the .jar file in my openhab/addons/ folder on a new installation of openhab (both 3.1 and 3.2) and then starting openhab but I cannot find the build on the webui. Is there anything else I need to configure/do in order to see it ?

You may not see the binding listed in the web UI if you load it that way. You should see it in the console, though, using the bundle:list command. You should see something like this:

openhab> bundle:list | grep -i lutron
239 x Active x  80 x 3.1.0                 x openHAB Add-ons :: Bundles :: Lutron Binding

The state should be “Active”.

I’ve submitted a PR for this change.