I realize this is a longshot (not the most common system/older) but I’m working on setting up a Lutron RadioRA Classic system using OpenHab3. I have a RasberryPi connected to the Chronos module via Serial Port. I can toggle switches and Phantom Buttons w/o any issue. But DIMMERS just don’t work. I can configure the dimmer, it shows online and I can see the actions I take appear in the terminal log on the Chronos - but the lights don’t change. Anyone have Dimmers working on RadioRa using OpenHab? Perhaps there’s a setting I’m missing?
I don’t know if many people are exercising that part of the binding. It was originally written by @jjlauterbach. I’ve been trying to avoid touching it much, since I have no hardware to test it with. But I think a few changes went in during 3.0 development to replace some deprecated calls.
Did it work with the same configuration under openHAB 2.5?
I exclusively have dimmer devices for RadioRA. I’m planning to start upgrading to OH3 this week so will verify everything still works.
I had dimmers working in 2.5…basically (they seemed to have issues reading current “state” but did impact the lights) - but honestly hadn’t worked w/ OpenHab in some time. I am using OpenHab3 to re-open a push to put together some of the older home automation tools in my house. The RadioRa Classic part is the biggest need - and most lights are on dimmers so this is a huge part.
ANYTHING you learn - I’d appreciate it.
Also considering sinking my teeth in to see if it might be possible to expand the binding to handle a 2nd zone (which I have and, from a Chronos perspective, seems simple enough.)
I’ve got RadioRA running on OH3 without any issues. If you share the issues you’re having, I can try to help you troubleshoot.
Thank you - are you using RadioRA on OH3 via Chronos box? I think I’ve made some headway - but sometimes it appears my hangups are w/ Lutron/Chronos more than OH. I inherited the system w/ little documentation (found manuals online - but I have limited knowledge of how things are configured and I don’t want to screw up standard operation.)
If you do have Chronos - can you help me out by sharing your understanding of the RS-232 Settings you can set on the box. If I edit those settings - by mapping specific switches/dimmers to the RS-232 SWITCHes via the Chronos UI - that ONLY affects commands coming from the Serial Port - correct? I don’t want to go through, make a bunch of RS-232 Switch changes and find my wall switches/dimmers no longer work…
Yes - I think you’re correct that assigning zone numbers to dimmers/switches is only for the purposes of using RS-232 devices to control them. It should not interfere with how the system is otherwise setup.
I inherited my system and only have a chronos module and dimmers. I do not have any other master controls.
The default RS-232 settings should pretty much work I think. You’ve probably already see this documentation but it is pretty complete in how to get things setup.
I’d suggest just getting a single dimmer setup and integrate it with openhab before going through the hassle of setting up all the dimmers/switches.
Thank you for all help - turns out more of my issue was on the RS232/Chronos side than OpenHab - I am now able to control switches/dimmers.
BUT - my setup is a single Chronos “bridged” system. So as far as I can tell I can only control switches/dimmers from System 1.
Looking at: https://www.lutron.com/TechnicalDocumentLibrary/044-038a.pdf
It seems like sending commands to a 2 system controller is just a single extra parameter. (S1 vs S2)
Would seem to be an easy OpenHab upgrade - I don’t suppose anyone that works on this binding is paying attention? Or am I missing a complication?
I looked at the code, and this wouldn’t be an especially easy fix. It’s not complicated, but it involves quite a few changes, because that system number parameter would need to be added in a lot of places. The code that sends commands to the controller, the code that interprets responses coming back from the controller, the dimmer and switch things handlers, the thing handler configurations, etc.
I can take a look at adding it when I get some time, but I have no way to test it. So you would have to be willing to test mostly untried versions of the code.
I’m entirely willing to test. Honestly I’d take on some of the work myself however I’ve never found the time to research how to set up the development environment to edit existing bindings.
I’ve been tied up with other things lately, but I’ll take a look at this as soon as I have time. Unless @jjlauterbach would rather do it. Since it’s his code, I don’t want to step on his toes.
Sorry I lost track of this thread. I won’t have time to take this change on anytime soon but can happily test any changes.
I’ve started working on this, but it may take a while since lately I seldom seem to have the time to concentrate on it for very long. I’ve made all of the necessary changes for sending commands that include the system parameter. Now I’m working on the more complicated changes for receiving and delivering commands that include the system parameter.
It appears that the message I posted over the weekend about this was lost when the forum crashed. I’ve created a test version of the Lutron binding that should support a bridged RadioRA system, although I have no way to test it. The binding jar file and some additional details about it are available here:
I had forgotten! (that’s on me) - struggling w/ a dependency issue (org.apache.commons.net.telnet) right now - but as soon as I resolve it I’ll test.
And I guess all it took was me complaining to get the dependencies fixed. I did it - and my initial testing on a Chronos bridged system is that the new “System Number” works as desired.
I setup zone(s) on System 2 and I can now control them w/ OpenHab.
Previously setup switches all work w/ no update needed.
I’m going to setup all switches/dimmers in the zone this week and test through actual usage - and I’ll post any updates here.
(but so far - it works great!)
Great! If the rest of the testing goes well, I’ll submit a PR for the changes. I want to add null annotations to a few more classes to reduce the number of warnings from the SAT tool (this is an on-going task for the binding), so I may have one more test version for you to try even if no fixes are required.
I’ve built another test version of the Lutron binding containing the changes for bridged RadioRA classic systems. This is the version I’ll submit a PR for, assuming it tests out ok. Functionally it should be the same as the last test version, but I’ve made a bunch of code changes to eliminate SAT tool and compiler warnings. @wjo3 and @jjlauterbach, if you guys could test it out I’d appreciate it!
I have a random question about the ra-dimmer thing. Do the fadeInSec and fadeOutSec parameters to ra-dimmer do anything? The handler code accepts them, but from what I can see it never does anything with them.