-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[lutron] Add support for bridged RadioRA (classic) systems #10302
Conversation
Signed-off-by: Bob Adair <bob.github@att.net>
Signed-off-by: Bob Adair <bob.github@att.net>
Signed-off-by: Bob Adair <bob.github@att.net>
This pull request has been mentioned on openHAB Community. There might be relevant details there: https://community.openhab.org/t/lutron-radiora-classic/111644/27 |
@@ -59,7 +63,8 @@ public void open(String portName, int baud) throws RadioRAConnectionException { | |||
} | |||
|
|||
try { | |||
serialPort = portIdentifier.open("openhab", 5000); | |||
SerialPort serialPort = portIdentifier.open("openhab", 5000); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really necessary to create a local variable here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. I agree with you, but wherever you see this pattern it was done to eliminate compiler warnings associated with the Eclipse JDT null annotations. It seems to "helpfully" assume that if something is annotated as being Nullable but isn't a local variable, another thread may have come along and changed it to null behind your back. No matter if code design or use of locking prevents this. So the solution is to use a lot of otherwise unnecessary local variables. It would be interesting to see what the overall impact on GC is, although they are mostly just extra pointers.
...inding.lutron/src/main/java/org/openhab/binding/lutron/internal/radiora/RS232Connection.java
Show resolved
Hide resolved
....lutron/src/main/java/org/openhab/binding/lutron/internal/radiora/handler/DimmerHandler.java
Show resolved
Hide resolved
...ng.lutron/src/main/java/org/openhab/binding/lutron/internal/radiora/config/DimmerConfig.java
Show resolved
Hide resolved
@@ -52,6 +58,10 @@ public String getCommand() { | |||
args.add(String.valueOf(fadeSec)); | |||
} | |||
|
|||
if (system == 1 || system == 2) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This block of code could maybe be pushed to RadioRACommand and reused throughout
I've tested this change in a non bridge mode and haven't found any functional issues. |
Thanks for the testing and comments, @jjlauterbach. |
Signed-off-by: Bob Adair <bob.github@att.net>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
…0302) Signed-off-by: Bob Adair <bob.github@att.net>
…0302) Signed-off-by: Bob Adair <bob.github@att.net> Signed-off-by: John Marshall <john.marshall.au@gmail.com>
…0302) Signed-off-by: Bob Adair <bob.github@att.net>
…0302) Signed-off-by: Bob Adair <bob.github@att.net>
…0302) Signed-off-by: Bob Adair <bob.github@att.net>
This update adds support for bridged RadioRA (classic) systems. A system is considered “bridged” when a Chronos System Bridge and Timeclock is used to integrate two RadioRA Systems in a single residence.
I also took the opportunity to add null annotations to the source files for the RadioRA part of the binding.