Thoughts on my keypad idea? Right now, I made the Grafik Eye a separate device. In reality though, it is just a really big keypad. I could instead add an option type parameter field to your Keypad definition, so there is only a single keypad thing, which can be expanded to handle all types (i.e. pico remotes, etc.)
Iām not too familiar with the Grafik Eye. At least from looking at the integration documentation, it doesnāt seem like thereās a lot of overlap between the Grafik Eye and the keypads, but maybe it would make more sense to me once I see it in the code. It looks like component #83 means something very different in the Grafik Eye.
I know that is confusing! 83 is just another keypad button AFAIK, despite its moniker. It is not required to be programmed to turn everything off, and is treated in the RadioRa2 program as just another keypad button.
Iām going to keep it separate for now anyway. My next month is pretty busy, so I may not be able to turn to this until Feb.
I actually donāt have the shades, my ultimate goal is to integrate Lutron with HunterDouglas shades. So Iām creating āvirtualā shades in RadioRa2, and using OpenHab to map them to HunterDouglas. This allows me to use the Lutron app to control, and also other apps like Roomie (SimpleControl) for whole home control. But, that means I also need to build a HunterDouglas driver too.
Howād your progress go on that effort?
I have a Caseta Smart Bridge Pro which uses the same telnet integration protocol as RadioRa2. I have OpenHAB 2 running on my Windows 7 PC with JDK 8u92 and all seems to be working fine, except I am not able to connect to the Lutron hub. I was able to use Putty to start a telnet connection with the hub on the same PC to control my lights with the standard Lutron integration commands, but OpenHAB keeps showing that the device username/password is incorrect (itās the default ālutronā, āintegrationā login). Is this a known issue? Perhaps it times out too quickly (Putty takes about 10 seconds before it prompts me for my username/password)? Other bindings in OH2 seem to be working ok (Sonos binding finds and controls my Sonos devices as expected). I also tried running OH2 on my Synology DS214+ (running diskstation 6) and had similar results.
I donāt have a Smart Bridge Pro, and Iām not aware that anyone else has tried it. Are you saying you can telnet to the hub and run DEVICE/OUTPUT commands to control your lights? If so, I may just have to get one.
The Smart Bridge Pro only works with Caseta dimmers and switches (i.e. itās not going to be useful if you have only RadioRa 2 devices) but from what Iāve seen most systems that support RR2 via telnet seems to work with Caseta + Smart Bridge Pro (the standard Smart Bridge does not support telnet). Anyway this is my first go with OH so Iām just trying to figure out if iām missing something easy.
Below is some of a PuTTY telnet session with my Caseta Smart Bridge Pro where I polled a dimmer for its status and changed the light levelā¦ For some reason it asked for my login and password twice. Also it takes about 30s for the login prompt to show up after initiating the telnet session, in case thatās at all helpful.
login: lutron
password: integration
login: lutron
password: integration
GNET> ?OUTPUT,4,1
~OUTPUT,4,1,20.39
GNET> output,4,1,70,00:30
GNET> ~OUTPUT,4,1,70.00
GNET> output,4,1,18
~OUTPUT,4,1,18.00
GNET>
Ok, this weekend I did my best job of pretending I know how to code and tried to remember something from my high-school Java class (and watched a couple youtube videos on the openHAB IDE 
).
So, I changed @actong88ās IPBridgeHandler.java code slightly, specifically lines 203-206 where the code does the login to the Lutron bridge. Since I noticed my Caseta bridge was asking for the login and password twice (see my post above) when I started a telnet session, I just duplicated those lines of code so now the code reads:
this.session.waitFor("login:"); this.session.writeLine(config.getUser()); this.session.waitFor("password:"); this.session.writeLine(config.getPassword()); this.session.waitFor("login:"); this.session.writeLine(config.getUser()); this.session.waitFor("password:"); this.session.writeLine(config.getPassword());
After that change I was able to connect to the Caseta Smart Bridge Pro successfully and added and controlled a dimmer (added a Maestro dimmer thing). Iām pretty sure this code would break the pluginās support for the RR2 hub, but I suppose you could have the user prompted for which type of hub theyāre setting up and have it loop the relevant part of the telnet login once or twice depending on which hub type is selected. Hope this helps!
Good to know. I ordered a smart bridge pro to play with. Just waiting to receive some Serena shades so I have something to configure.
Sounds good, the Serena shades are very nice; I have them on a bay window in my house and Iām very happy so far. I imagine youāll be able to get it all working without much trouble! You do have to make sure to enable telnet access in the advanced settings of the Lutron Caseta app after you setup your bridge.
Iāve started to modify your binding to be more Lutron platform agnostic, so that it can be used with any Lutron system that exposes a telnet server that supports the integration protocol. Thus far, Iāve got a āsystem typeā field setup to account for the authentication difference(s) between systems. (As previously brought up by @olesam ) Am currently tinkering with making other things a bit more agnostic. (Ex. āLutron Dimmerā instead of āMaestro Dimmer.ā)
Would love to collaborate a bit, instead of just blindly submitting commits that are really just edits of your existing code base. (Like @olesam, I too am working off of a very old and fleeting familiarity with Java.)
Thoughts?
Sure, any contribution is welcome. As far as the āsystem typeā parameter, my thoughts are that thatās what thing-types are for, i.e. Caseta smart bridge would just be defined as a different bridge thing-type (the implementation can still be shared under the hood).
I also have changes in my local environment to support Caseta, though all it does is modify the existing bridge handler to try logging in twice; I didnāt create a separate thing-type. I am thinking, though, that we should create a separate thing-type for Caseta. Iāve implemented auto-discovery of devices, which is currently awaiting review. However, Caseta smart bridges donāt seem to expose DbXmlInfo.xml, so right now I get an exception in the logs when OH2 tries to discover devices attached to the smart bridge. Having smart bridges be a different thing-type would allow disabling of the auto-discovery for Caseta.
I hope you donāt mind - Iām also modifying the lutron addon to support Grafik Eye 3000/4000 via grx-ci-prg interface. However, itās sufficiently different than radiora/caseta that itās pretty much a standalone implementation (I just created a sub package within the lutron package to hold the entirety of the implementation). If you have any comments or questions, let me know
Thanks,
Tim
Ooh - I do like the idea of defining system type by way of selecting your interface. That takes care of all device support issues between systems. (As well as the fact the G3000/G4000 predate the standardized integration protocol.)
To deal with the device discovery issues on Caseta, some sort of file upload function would probably work well. (Caseta does present XML via the mobile app, but you then one needs a way for OpenHAB to ingest the info.)
Any updates here? I also have the Caseta Hub Pro and am just starting with learning openhabā¦ I have my lights up and working and can control them via phones now no problem. Now I have to start integrating it all into openhab running on a dedicated Mac Mini.
Allan, very nice binding. Unfortunately (for me) I have an older Lutron HomeWorks processor. Connections can only be made via a serial port and it uses a different protocol and command set (http://www.lutron.com/TechnicalDocumentLibrary/HWI%20RS232%20Protocol.pdf).
I have my processor hooked up to my Raspberry Pi (running openHAB) and Iām in the process (just starting really) of creating a binding to control the processor over a RS232/USB link. Iām mostly copying the structure for your binding (as openHAB development is still pretty new to me).
As I work though my binding, I have the choice of either creating a new module as a separate binding, or adding a new bridge/command set to your module so that the one Lutron binding supports both protocols. If I had my choice, Iād do the latter, and create a unified bundle. Do you have any objection or concern to doing that? Obviously Iād be working in a separate branch but I would eventually like to merge it into the main trunk once I get it working.
I donāt have a problem with putting it in the same bundle. I donāt have HomeWorks and am not familiar with its protocol, though, so I probably couldnāt provide much support.
Thatās no problem. Iāll starting making the changes and upload to a new fork. Iāll just ask you to review the changes and make sure I havenāt broken anything on the IPBridge side. It will probably be a while before I actually have anything to show.
Iām having trouble getting the binding working with the non-RadioRA2 system. Iām fairly new to OH and just made the move to OH2 in order to get my caseta lights integrated. Iām running the openhab-offline-2.0.0.b3 distro and was able to modify and recompile actong88ās IPBridgeHandler.java so that my Smart Bridge Pro shows as āonlineā in PaperUI under āThingsā. I was also able to add a maestro dimmer and it also says itās online. However, if I add a slider to my sitemap, moving it doesnāt change the lights. I know Iāve made some connection though because the slider will update to the current light level if I change it just using the switch in the room. Anytime I use the slider, I get this long string of error messages, but Iām not sure how to go about fixing it. Any help would be greatly appreciated.
Looks like you compiled the binding against a newer version of OH/ESH than what you are running. Your recompiled binding is looking for a method (Bridge.getHandler) that exists in newer versions but didnāt exist in openhab-offline-2.0.0.b3. You should update your OH or recompile against the version of the code that matches your runtime (2.0.0.b3).