Closed txwindsurfer closed 4 years ago
By 'Lutron main repeater' you mean something like a RadioRA 2 repeater, or HomeWorks QS, etc? One of the 'professionally installed' Lutron lighting automation products?
tl;dr: it won't work, with current code
Sorry for any inadvertent misleading, but it's not going to work with the current code -- this Lutron bridge handler only works with the 'retail' bridges: SmartBridge, SmartBridge Pro, RA2/Select repeater. So changing the communications/authorization settings in LutronPiServer.js to talk to one of the 'non-retail' repeaters just won't make it work, sorry to say.
Your instinct is correct in that the Telnet-based LIP protocol for that kind of repeater is very, very similar to (a superset of) that used by the retail SmartBridge Pro and RA2/Select. But the current code expects a Lutron unit to also have an entirely separate communications protocol called LEAP. That is the protocol that informs this server about the roster of Lutron devices attached to the bridge, and some other odds and ends that the Telnet/LIP doesn't support. So far as I know the non-retail repeaters don't include that LEAP protocol.
As I understand it, on some of the non-retail Lutron systems the Telnet/LIP interface includes INTEGRATIONID and DETAILS verbs that allow an outside device to get a limited amount of info about the device roster, but the RadioRA 2 repeater doesn't seem to have that either (according to the Lutron LIP docs, anyway), nor do the retail bridges. Obviously Lutron knows how to extract that info, since their corresponding apps know it, but I don't know if they're using those LIP verbs or some other private protocol (e.g. whatever Lutron techs use for initial setup). In any case, I myself don't have any such equipment, so am not currently in a position to experiment with support for that hardware.
An alternative approach might be to allow a RadioRA 2 or other such repeater to obtain its device roster from some other source, such as a fixed-format file on the device running this node server (much like the "Lutron Integration Report" you can dump from the Lutron Connect app under Settings/Advanced/Integration/Send"). Or even write a way to set that info from the SmartThings end - a rather elaborate bit of work, that would be. Given a way to get the device roster (and inform SmartThings hub of that roster), modifying the lutron-bridge.js code to support that other kind of repeater with just the Telnet/LIP interface would be pretty straightforward.
Sorry I don't have a more encouraging answer. I should add that someone else did take a stab at RadioRA support for SmartThings as an entirely separate project, a couple of years back, but as far as I can see it ground to a halt: https://community.smartthings.com/t/lutron-radiora-version-1-and-smartthings-saga-prologue/49034/17. Also, I think the Hubitat "local processing" hub (among others) does support RadioRA etc. pretty much as speculated above.
Yes, I meant the QS telnet interface. I suspected that this would be the situation but wanted to check. QS uses a hub called Lutron Connect which I believe is the same as the Radio RA hub. It is not intended as an interface except via the Lutron app. I have a simple Lutron to ST interface that discovers when a particular hardcoded Lutron button/light is turned on and then via IFTTT notifies ST so ST can act accordingly. Looks like getting ST to notify Lutron via an IFTTT/http bridge or an mqtt bridge would work for explicitly declared and coded devices. Your suggestion about reading and implementing the Lutron Integration file could also be a possibility for a universal interface. Thanks again for your excellent work and response!
If you (or someone else with the hardware to test!) wanted to take a crack at it, I'd suggest this approach: a Lutron Telnet/LIP 'bridge' plug-in. That is, create a new bridge type specifically for (let's say) LutronLIP or whatever you want to call it that's distinct from the existing Lutron bridge schema. Clone the existing files in bridges/ directory accordingly: lutron-bridge.js -> lutronlip-bridge.js , lutron-auth.js -> lutronlip-auth.js , lutron-discover.js -> lutronlip-discover.js . Then you can modify the three new lutronlip*.js files as needed to implement the LIP-only/static-device-roster interface without having to tinker with the existing LEAP/LIP bridge code. Seems to me that the primary change to the -bridge module would be to strip out the LEAP (SSL comm) code and substitute a means for loading a static device roster and swishing it around to replicate the LEAP device format to pass to SmartThings. The -auth module would probably be mostly stubbed out, and the -discover module would either be adapted to the repeater's discovery mechanism (maybe just a different Bonjour/mDNS name), or maybe just stubbed out in favor of static IP address specification (at least at first).
One other note: you can get some kind of system configuration database dump from your repeater in the form of an XML file, like so: http://ip-address-of-repeater/DbXmlInfo.xml and that might have enough info to dynamically address different Lutron devices off of that repeater. In addition, you can use the Telnet command INTEGRATIONID to get a limited amount of info on the devices: ?INTEGRATIONID,3 to get a list of all integration IDs, ?INTEGRATIONID,3,id to get some limited amount of info about any particular id.
Your suggestions are extremely helpful. Thanks! An excellent Lutron Telnet 'bridge' plug-in for Radio RA2 is the pylutron library found here: https://github.com/thecynic/pylutron. While it is set up for Radio RA2, changing the prompt from GNET to QNET in the init.py is all that is needed to make it work for Homeworks QS. It is however written in python so I am not sure how or if this could be called from the .js files in the bridge directory. While this doesn't address how the information from the XML file or INTEGRATIONID command might be used to set up the devices, I would propose that the ST device set-up be manual and left to the integrator since both Radio RA2 and QS have a very large number of device types and probably an integrator would likely only want to use a few of the devices in a particular ST integration. Do you think the pylutron library could be used in the lutronlip bridge implementation you mentioned?
On Fri, Sep 21, 2018 at 10:15 AM billhinkle notifications@github.com wrote:
One other note: you can get some kind of system configuration database dump from your repeater in the form of an XML file, like so: http://ip-address-of-repeater/DbXmlInfo.xml and that might have enough info to dynamically address different Lutron devices off of that repeater. In addition, you can use the Telnet command INTEGRATIONID to get a limited amount of info on the devices: ?INTEGRATIONID,3 to get a list of all integration IDs, ?INTEGRATIONID,3,id to get some limited amount of info about any particular id.
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/billhinkle/lutronpi-server/issues/2#issuecomment-423568740, or mute the thread https://github.com/notifications/unsubscribe-auth/AZQ7DRjvm3kLkZ_VcqKVugDJbnnxYURUks5udQJ9gaJpZM4WuW_A .
Not directly, but the library probably has some useful clues for the adaptation of the existing bridge-connection code. I'll have a look.
Followup: just so I have an inkling what I'm looking at... any chance you could grab the XML file from your setup and post it to me? It seems like just using web browser to http://ip-address-of-repeater/DbXmlInfo.xml should bring it up, then File/SaveAs. (If other sources are correct, anyhow.)
On a separate but related note... If you feel like doing a bit of onsite sleuthing... I wonder if the current lutronpi server discovers your Lutron Connect bridge? If so, you should see it reported near the very beginning of the log after the server starts up with default Lutron discovery; something like:
node lutronpi
(some startup info)
Discovering lutron bridges...
...Lutron Bridge mDNS found / now 1 service(s): Mon Sep 24 2018 10:37:54 GMT-0400 (EDT)
...Lutron Bridge mDNS Host: lutron-xxxxxxxx.local IP: 192.168.0.zzz
...Lutron Bridge mDNS Name: Lutron Status
...Lutron Bridge mDNS FQDN: Lutron Status._lutron._tcp.local
...Lutron Bridge mDNS MAC: mm:mm:mm:mm:mm:mm
If it DOES discover the Lutron Connect (compare the IP), then get the 8-digit hexadecimal number xxxxxxxx from the lutron-xxxxxxxx host name, convert it to all upper case XXXXXXXX (it will PROBABLY match the S/N on the Lutron Connect unit, if it's anything like the Caseta bridge). Then re-start the lutronpi server with this specific debug option:
node lutronpi XXXXXXXX=debug
which should show the server's communication with the Connect in more detail. It will still probably not get too far, but that first communications exchange might be very revealing and potentially useful. If that doesn't seem to yield anything, try =trace instead of =debug .
(This is predicated on a guess that the Lutron login scheme for the Connect is the same as that for the Caseta bridges, which may not actually be true at all. And also that, once logged in, the Connect has a LEAP interface, even if different in details from that of the other bridges.)
Attached is the xml file that is retrieved.
I'm sending the onsite sleuthing in the next email...
On Tue, Sep 25, 2018 at 8:59 AM billhinkle notifications@github.com wrote:
Followup: just so I have an inkling what I'm looking at... any chance you could grab the XML file from your setup and post it to me? It seems like just using web browser to http://ip-address-of-repeater/DbXmlInfo.xml should bring it up, then File/SaveAs. (If other sources are correct, anyhow.)
On a separate but related note... If you feel like doing a bit of onsite sleuthing... I wonder if the current lutronpi server discovers your Lutron Connect bridge? If so, you should see it reported near the very beginning of the log after the server starts up with default Lutron discovery; something like:
node lutronpi (some startup info) Discovering lutron bridges... ...Lutron Bridge mDNS found / now 1 service(s): Mon Sep 24 2018 10:37:54 GMT-0400 (EDT) ...Lutron Bridge mDNS Host: lutron-xxxxxxxx.local IP: 192.168.0.zzz ...Lutron Bridge mDNS Name: Lutron Status ...Lutron Bridge mDNS FQDN: Lutron Status._lutron._tcp.local ...Lutron Bridge mDNS MAC: mm:mm:mm:mm:mm:mm
If it DOES discover the Lutron Connect (compare the IP), then get the 8-digit hexadecimal number xxxxxxxx from the lutron-xxxxxxxx host name, convert it to all upper case XXXXXXXX (it will PROBABLY match the S/N on the Lutron Connect unit, if it's anything like the Caseta bridge). Then re-start the lutronpi server with this specific debug option: node lutronpi XXXXXXXX=debug which should show the server's communication with the Connect in more detail. It will still probably not get too far, but that first communications exchange might be very revealing and potentially useful. If that doesn't seem to yield anything, try =trace instead of =debug .
(This is predicated on a guess that the Lutron login scheme for the Connect is the same as that for the Caseta bridges, which may not actually be true at all. And also that, once logged in, the Connect has a LEAP interface, even if different in details from that of the other bridges.)
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/billhinkle/lutronpi-server/issues/2#issuecomment-424354499, or mute the thread https://github.com/notifications/unsubscribe-auth/AZQ7DezFy5zUT6WkO-tFYEUG6vNSiy-Sks5uejbLgaJpZM4WuW_A .
Loading lutronpi finds the Lutron Connect hub which cannot be authenticated because Lutron doesn't support this any authentication except to their Connect App for either QS or Radio RA 2. This is the output: ############## pi@raspberrypi:~/lutronpi $ node lutronpi /home/pi/lutronpi/lutronpi Version 2.0.0 2018.07.13 2030Z bridgeDiscoverList=[ 'lutron', [length]: 1 ] Requiring /home/pi/lutronpi/lutronpi/bridges/lutron-discover Discovering lutron bridges... ...Lutron Bridge mDNS found / now 1 service(s): Tue Sep 25 2018 13:30:02 GMT-0500 (CDT) ...Lutron Bridge mDNS Host: lutron-xxxxxxx.local IP: 192.168.x.xx
Lutron Bridge 01F07F67: [Enter] to skip, or enter user: ggggggggggggggggg
Lutron Bridge 01F07F67: [Enter] to skip, or enter password: ***
Generating Lutron authentication for ggggggggggggggggggg Key generation may take a while... Lutron Bridge 01F07F67 SSL comm error undefined Error: 1995825696:error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate:../deps/openssl/openssl/ssl/s3_pkt.c:1498:SSL alert number 42 1995825696:error:140940E5:SSL routines:ssl3_read_bytes:ssl handshake failure:../deps/openssl/openssl/ssl/s3_pkt.c:1216:
Lutron Bridge 01F07F67: [Enter] to skip, or enter user: ######################
and so on.......
However,
Lutron Bridge XC0A801CA: [Enter] to skip, or enter user: id used xxxxxxxxxxx #this is the id I used to access the Connect Hub Lutron Bridge XC0A801CA: [Enter] to skip, or enter password: ***
Generating Lutron authentication for xxxxxxx Key generation may take a while... Lutron Bridge XC0A801CA #0 initializing Lutron Bridge XC0A801CA SSL comm error ETIMEDOUT Error: connect ETIMEDOUT 192.168.1.xxx:8081 Lutron Bridge XC0A801CA reconnecting... ######################
Continues in a timeout/retry loop. The SSL port, 8081 is being used instead of the telnet port 23.
I'll post the result of using debug in the next post.....
On Tue, Sep 25, 2018 at 8:59 AM billhinkle notifications@github.com wrote:
Followup: just so I have an inkling what I'm looking at... any chance you could grab the XML file from your setup and post it to me? It seems like just using web browser to http://ip-address-of-repeater/DbXmlInfo.xml should bring it up, then File/SaveAs. (If other sources are correct, anyhow.)
On a separate but related note... If you feel like doing a bit of onsite sleuthing... I wonder if the current lutronpi server discovers your Lutron Connect bridge? If so, you should see it reported near the very beginning of the log after the server starts up with default Lutron discovery; something like:
node lutronpi (some startup info) Discovering lutron bridges... ...Lutron Bridge mDNS found / now 1 service(s): Mon Sep 24 2018 10:37:54 GMT-0400 (EDT) ...Lutron Bridge mDNS Host: lutron-xxxxxxxx.local IP: 192.168.0.zzz ...Lutron Bridge mDNS Name: Lutron Status ...Lutron Bridge mDNS FQDN: Lutron Status._lutron._tcp.local ...Lutron Bridge mDNS MAC: mm:mm:mm:mm:mm:mm
If it DOES discover the Lutron Connect (compare the IP), then get the 8-digit hexadecimal number xxxxxxxx from the lutron-xxxxxxxx host name, convert it to all upper case XXXXXXXX (it will PROBABLY match the S/N on the Lutron Connect unit, if it's anything like the Caseta bridge). Then re-start the lutronpi server with this specific debug option: node lutronpi XXXXXXXX=debug which should show the server's communication with the Connect in more detail. It will still probably not get too far, but that first communications exchange might be very revealing and potentially useful. If that doesn't seem to yield anything, try =trace instead of =debug .
(This is predicated on a guess that the Lutron login scheme for the Connect is the same as that for the Caseta bridges, which may not actually be true at all. And also that, once logged in, the Connect has a LEAP interface, even if different in details from that of the other bridges.)
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/billhinkle/lutronpi-server/issues/2#issuecomment-424354499, or mute the thread https://github.com/notifications/unsubscribe-auth/AZQ7DezFy5zUT6WkO-tFYEUG6vNSiy-Sks5uejbLgaJpZM4WuW_A .
I hope I am not sending way too much info. I am very appreciative for taking the time just to examine. Thanks!
If using the debug option with the connect Hub this output is: ################# pi@raspberrypi:~/lutronpi $ node lutronpi xxxxxxxx=debug /home/pi/lutronpi/lutronpi Version 2.0.0 2018.07.13 2030Z bridgeDiscoverList=[ 'lutron', [length]: 1 ] Requiring /home/pi/lutronpi/lutronpi/bridges/lutron-discover Discovering lutron bridges... ...Lutron Bridge mDNS found / now 1 service(s): Tue Sep 25 2018 13:55:47 GMT-0500 (CDT) ...Lutron Bridge mDNS Host: lutron-xxxxxxxx.local IP: 192.168.x.xxx
Generating Lutron authentication for ggggggggggggggg Key generation may take a while... Lutron Bridge xxxxxxxx SSL comm error undefined Error: 1996272160:error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate:../deps/openssl/openssl/ssl/s3_pkt.c:1498:SSL alert number 42 1996272160:error:140940E5:SSL routines:ssl3_read_bytes:ssl handshake failure:../deps/openssl/openssl/ssl/s3_pkt.c:1216:
Lutron Bridge xxxxxxxx: [Enter] to skip, or enter user: #######################
Thanks again for taking the time to investigate.... I'm happy to help in any way.
On Tue, Sep 25, 2018 at 8:59 AM billhinkle notifications@github.com wrote:
Followup: just so I have an inkling what I'm looking at... any chance you could grab the XML file from your setup and post it to me? It seems like just using web browser to http://ip-address-of-repeater/DbXmlInfo.xml should bring it up, then File/SaveAs. (If other sources are correct, anyhow.)
On a separate but related note... If you feel like doing a bit of onsite sleuthing... I wonder if the current lutronpi server discovers your Lutron Connect bridge? If so, you should see it reported near the very beginning of the log after the server starts up with default Lutron discovery; something like:
node lutronpi (some startup info) Discovering lutron bridges... ...Lutron Bridge mDNS found / now 1 service(s): Mon Sep 24 2018 10:37:54 GMT-0400 (EDT) ...Lutron Bridge mDNS Host: lutron-xxxxxxxx.local IP: 192.168.0.zzz ...Lutron Bridge mDNS Name: Lutron Status ...Lutron Bridge mDNS FQDN: Lutron Status._lutron._tcp.local ...Lutron Bridge mDNS MAC: mm:mm:mm:mm:mm:mm
If it DOES discover the Lutron Connect (compare the IP), then get the 8-digit hexadecimal number xxxxxxxx from the lutron-xxxxxxxx host name, convert it to all upper case XXXXXXXX (it will PROBABLY match the S/N on the Lutron Connect unit, if it's anything like the Caseta bridge). Then re-start the lutronpi server with this specific debug option: node lutronpi XXXXXXXX=debug which should show the server's communication with the Connect in more detail. It will still probably not get too far, but that first communications exchange might be very revealing and potentially useful. If that doesn't seem to yield anything, try =trace instead of =debug .
(This is predicated on a guess that the Lutron login scheme for the Connect is the same as that for the Caseta bridges, which may not actually be true at all. And also that, once logged in, the Connect has a LEAP interface, even if different in details from that of the other bridges.)
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/billhinkle/lutronpi-server/issues/2#issuecomment-424354499, or mute the thread https://github.com/notifications/unsubscribe-auth/AZQ7DezFy5zUT6WkO-tFYEUG6vNSiy-Sks5uejbLgaJpZM4WuW_A .
great info, thanks, will ruminate on that and probably be back with more Qs
I should add that the lutronlip-xxxx interface doesn't actually exist -- that was just my speculative name for what it COULD be. But nevertheless that diagnostic info was useful.
EDIT: unless I'm missing something, it looks like that XML file didn't actually get attached to the corresponding comment you left about it, above
Thank you for any time! Just wanted to pass along a .js driver for Homeworks QS that you are probably already aware of, but just in case.
https://github.com/ceisenach/homeworks_qs_rti_driver
On Wed, Sep 26, 2018 at 8:22 AM billhinkle notifications@github.com wrote:
great info, thanks, will ruminate on that and probably be back with more Qs
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/billhinkle/lutronpi-server/issues/2#issuecomment-424712822, or mute the thread https://github.com/notifications/unsubscribe-auth/AZQ7DdSWCiHar5VAoWmlzsFg78h6Z2DAks5ue3-LgaJpZM4WuW_A .
Well sir, if you want to try a first pass at a Lutron Telnet interface (e.g. for Homeworkx QS or RadioRA 2, I hope), you are welcome to be the guinea pig. I've added a new additional bridge type: lutrontelnet which is intended to do just that. There are a number of changes at the Smartthings end as well as the node server end, so both software suites need to be updated simultaneously to try this out.
I have put the trial code in a new github brance called 'beta6' for both lutronpi-smartthings and lutronpi-server repositories. I've left the master branch as-is to avoid rocking the boat until you or someone can try this out a bit.
So just update your Smartthings suite of SmartApp and device handlers from that beta6 branch (you can click thru Settings in the IDE to add the repository billhinkle/lutronpi-smartthings/beta6 in addition to the previous 'master' branch, which latter still has the old code. Then Update from Repo and be sure to select the beta6 branch, not master.
Likewise, wherever you've been running the LutronPi node server (RPi?), update all those files INCLUDING the new bridges/lutrontelnet-bridge.js, bridges/lutrontelnet-auth.js files, from the beta6 branch billhinkle/lutronpi-server/beta6 (again, not the master). Use git or copy the files or whatever you usually do.
In your LutronPiServer.js file, comment out the other startup example(s) and try setting one up like so: lutronpi.startup( [{type:"Lutrontelnet", id:"XXXXXXXX", ip:"192.168.0.230"}] );
where XXXXXXXX is some unique ID for your Lutron controller (S/N maybe?) and of course the IP is its IP address. You should be quizzed at startup for the controller's Telnet login (name) and password. For a RadioRA it's lutron/integration by default, but for Homeworks QS I don't know and I guess you do. n.b. those will be stored on your node server device disk in the clear, at least for the moment
Since I wasn't able to garner any information about those controllers' XML device lists, I added a scheme to the Smartthings SmartApp to manually add devices for a bridge that doesn't enumerate them (like these Telnet controllers). So you should just set up a few such devices and see what happens; you'll of course need the LIP 'integration ID' numbers for each such device.
For the moment I added a rudimentary "Lutron Keypad" device handler that hopefully will provide some function for the various non-Pico keypads. Note that it uses the native Lutron button codes, so the best course of action is probably to make note of what button number it thinks is pushed when you do push a particular physical button. Note that you have to set a maximum button number, which is NOT the same as the number of buttons, but rather the largest native Lutron button code it might encounter.
I didn't really feel like implementing a full specific device handler for each of the zillion types of Lutron keypads; not at this point anyhow...
Anyway, give it a shot, if you like, and let me know what you find out. All my debugging has been with a regular Caseta SmartBridge Pro using only the Telnet interface, so it may well trip up when it talks to a real Homeworks QS or RadioRA 2 controller.
Excited to give this a go. Thanks so much!!
Reagan
From: billhinkle notifications@github.com Sent: Monday, October 8, 2018 2:29:10 PM To: billhinkle/lutronpi-server Cc: txwindsurfer; State change Subject: Re: [billhinkle/lutronpi-server] How to use Telnet not Hub (#2)
Well sir, if you want to try a first pass at a Lutron Telnet interface (e.g. for Homeworkx QS or RadioRA 2, I hope), you are welcome to be the guinea pig. I've added a new additional bridge type: lutrontelnet which is intended to do just that. There are a number of changes at the Smartthings end as well as the node server end, so both software suites need to be updated simultaneously to try this out.
I have put the trial code in a new github brance called 'beta6' for both lutronpi-smartthings and lutronpi-server repositories. I've left the master branch as-is to avoid rocking the boat until you or someone can try this out a bit.
So just update your Smartthings suite of SmartApp and device handlers from that beta6 branch (you can click thru Settings in the IDE to add the repository billhinkle/lutronpi-smartthings/beta6 in addition to the previous 'master' branch, which latter still has the old code. Then Update from Repo and be sure to select the beta6 branch, not master.
Likewise, wherever you've been running the LutronPi node server (RPi?), update all those files INCLUDING the new bridges/lutrontelnet-bridge.js, bridges/lutrontelnet-auth.js files, from the beta6 branch billhinkle/lutronpi-server/beta6 (again, not the master). Use git or copy the files or whatever you usually do.
In your LutronPiServer.js file, comment out the other startup example(s) and try setting one up like so: lutronpi.startup( [{type:"Lutrontelnet", id:"XXXXXXXX", ip:"192.168.0.230"}] );
where XXXXXXXX is some unique ID for your Lutron controller (S/N maybe?) and of course the IP is its IP address. You should be quizzed at startup for the controller's Telnet login (name) and password. For a RadioRA it's lutron/integration by default, but for Homeworks QS I don't know and I guess you do. n.b. those will be stored on your node server device disk in the clear, at least for the moment
Since I wasn't able to garner any information about those controllers' XML device lists, I added a scheme to the Smartthings SmartApp to manually add devices for a bridge that doesn't enumerate them (like these Telnet controllers). So you should just set up a few such devices and see what happens; you'll of course need the LIP 'integration ID' numbers for each such device.
For the moment I added a rudimentary "Lutron Keypad" device handler that hopefully will provide some function for the various non-Pico keypads. Note that it uses the native Lutron button codes, so the best course of action is probably to make note of what button number it thinks is pushed when you do push a particular physical button. Note that you have to set a maximum button number, which is NOT the same as the number of buttons, but rather the largest native Lutron button code it might encounter.
I didn't really feel like implementing a full specific device handler for each of the zillion types of Lutron keypads; not at this point anyhow...
Anyway, give it a shot, if you like, and let me know what you find out. All my debugging has been with a regular Caseta SmartBridge Pro using only the Telnet interface, so it may well trip up when it talks to a real Homeworks QS or RadioRA 2 controller.
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHubhttps://github.com/billhinkle/lutronpi-server/issues/2#issuecomment-427952195, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AZQ7DRCeRh1QC9ubbd25Pvtm_wodsTPzks5ui6eGgaJpZM4WuW_A.
Oh one other thing: you can get the new telnet bridge to dump some additional debugging info (some comm stuff, e.g.) by adding an option to the startup command line. So for example:
node lutronpi/LutronPiServer.js XXXXXXXX=debug
where XXXXXXXX matches the unique bridge ID you gave your telnet controller as above. (Note that the path to LutronPiServer.js is just an example, you may have things set up differently, of course)
Bill,
1) From ST api, got the new LutronPi Server smartapp code from beta6, and the new keypad device driver from beta6 and put that into ST. 2) On Pi, copied new code from the beta6 repository for Lutron-auth.js, Lutron-bridge.js, Lutron-discovery.js; created: lutrontelnet-auth.js, lutrontelnet-bridge.js; and copied new code for lutronpi.js and package.jason 3) Ran npm install 4) Modified LutronPiServer.js (FYI, the id and password are the same as for RadioRA 2) 5) Opened smartapp LutronPi Service Manager on android (looking inr LutronPi Server Discovery) 6) Ran npm lutornpi/LutronPiServer on Pi
This Pi output would indicate that it connected ok to the HomeworksQS:
pi@raspberrypi:~/lutronpi $ node lutronpi/LutronPiServer lutronpi Version 2.0.0-beta.6 bridgeDiscoverList=[ [length]: 0 ] bridgeConnectList=[ BridgeConnect { bType: 'lutrontelnet', bID: '01F07F67', bIP: '192.168.x.xxx', bAuth: null, bInst: null }, [length]: 1 ] Requiring /home/pi/lutronpi/lutronpi/bridges/lutrontelnet-bridge Lutron Bridge 01F07F67 at 192.168.0.xxx created: #0 Lutron Bridge 01F07F67 #0 initializing Lutron Bridge 01F07F67 initial devices request Lutron Bridge 01F07F67 #0 Telnet Init (re-)trying Starting Telnet connection to Lutron Bridge 01F07F67 Lutron Bridge 01F07F67 confirming Telnet Lutron Bridge 01F07F67 Telnet Connected! Discovering SmartThings hub on local network... Ping 01F07F67... Pinged Bridge 01F07F67 T
However, that is as far as I get. The ST app just continues to look for the lutronpi server.
So, just to make sure a previous key or something was not allowing discovery, I deleted the entire lutronpi director and started over with a fresh clone (git could not find the beta6 directory), npm install etc. Got the exact same result.
I am sure I am missing something easy. Thanks so much for working on this.
Reagan
From: billhinkle Sent: Tuesday, October 9, 2018 7:46 AM To: billhinkle/lutronpi-server Cc: txwindsurfer; State change Subject: Re: [billhinkle/lutronpi-server] How to use Telnet not Hub (#2)
Oh one other thing: you can get the new telnet bridge to dump some additional debugging info (some comm stuff, e.g.) by adding an option to the startup command line. So for example: node lutronpi/LutronPiServer.js XXXXXXXX=debug where XXXXXXXX matches the unique bridge ID you gave your telnet controller as above. (Note that the path to LutronPiServer.js is just an example, you may have things set up differently, of course) — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.
"Telnet Connected!" is good news, at least. Since you reconfigured your lutronpi node files from scratch, do be sure that the node server is still signing on as "lutronpi Version 2.0.0-beta.6", just to be sure you've got this particular test version.
Anyway, the basic problem I'm seeing from the log is that the lutronpi server is not detecting the SmartThings hub on the local network. The ST hub broadcasts its identity and IP address using mDNS (in this case, a variant of the Bonjour protocal). At least the V2 hub I've got does that... I don't know what the original V1 or the very new V3 hubs do, so if you're using one of those, let me know.
When you see the "Discovering SmartThings hub on local network..." log, the lutronpi server starts looking for the SmartThings hub broadcast, and if it had found the hub, it would dump several lines of information about that hub. Since we aren't seeing that event logged, we're just not seeing the hub on the network. I understand that this discovery mechanism can be a little finicky if you have multiple LAN segments or some other kind of slightly unusual LAN configuration. Anything like that apply here? e.g. maybe the node server (RPi?) is one one IP subnet and the SmartThings hub on a different subnet? Etc. Can you ping the ST hub from the RPi? (Not definitive, but a start!)
It would be nice to get the SmartThings hub discovery working because that provides more robust restart after service interrupts, BUT... in lieu of sorting that out, you can also just provide the ST Hub IP address explicitly. Then the lutronpi server will proceed to try to communicate with the hub at that IP address. This is done with an additional parameter in your LutronPiServer.js startup spec; it comes AFTER the bridge(s) parameter, separated by a comma:
lutronpi.startup( [{type:"Lutrontelnet", id:"XXXXXXXX", ip:"LUTRONIP"}], SMARTTHINGSIP);
At least that will move on to the next stage; the lutronpi server will then start advertising itself TO the SmartThings hub and, more specifically, to the LutronPi SmartApp. Hopefully at that point the SmartApp will be able to discover the LutronPi server (using a DIFFERENT discovery mechanism they provide for SmartApps, call SSDP), and they can handshake and proceed.
Unfortunately, if there's something odd about the network that is preventing the lutronpi server from discovering the ST hub, it's not impossible that the same issues will prevent the discovery in the opposite direction (Hub detecting the server, in return). But I guess we'll see.
There was another guy that reported a similar lack of hub discovery on his network, but it kind of magically resolved itself after he did enough removing/re-installing/re-booting, so I never did learn what the underlying issue was.
btw I'll be out of town and partly incommunicado thru the weekend after noon Wednesday, so further debugging may be delayed or at least a bit sluggish at this end.
I bumped things around and started with fresh code on both ST and RPi. The ST hub and RPi are are the same subnet and I can ping ST from RPi. Anyway, went with the hardcoded IP and the connection was established. Tried to add several devices and the process moves along but always ends in unexpected error or unable to refresh. I am attaching server output for a sequence where I try to add a keypad. After adding the keypad device the app says to "Click Done or Click Back to add anther device". But, there isn't a Done button only next. Going with next produces some choices for identifying the button but at this point I get the unexpected error and/or unable to refresh.
Looking pretty good I think. Kinks but the basic structure is working. Let me know what I can provide that would help.
pi@raspberrypi:~/lutronpi $ node lutronpi/LutronPiServer
lutronpi Version 2.0.0-beta.6
bridgeDiscoverList=[ [length]: 0 ]
bridgeConnectList=[ BridgeConnect {
bType: 'lutrontelnet',
bID: 'XC0A801CA',
bIP: '192.168.1.202',
bAuth: null,
bInst: null },
[length]: 1 ]
Requiring /home/pi/lutronpi/lutronpi/bridges/lutrontelnet-bridge
Lutron Bridge XC0A801CA at 192.168.x.xxx created: #0
Lutron Bridge XC0A801CA #0 initializing
Lutron Bridge XC0A801CA initial devices request
Lutron Bridge XC0A801CA #0 Telnet Init (re-)trying
Starting Telnet connection to Lutron Bridge XC0A801CA
Lutron Bridge XC0A801CA confirming Telnet
Lutron Bridge XC0A801CA Telnet Connected!
Listening for SmartThings requests at 192.168.x.xx:5000...
Sending to SmartThings @ 192.168.x.xx:39500
Lutron Bridge XC0A801CA, Device=40, Button Code=6 Op=4
Lutron Pico mode: push/hold
Lutron Bridge XC0A801CA sent (manual/app) device update
Sending to SmartThings @ 192.168.x.xx:39500
Lutron Bridge XC0A801CA sent (manual/app) device update
Sending to SmartThings @ 192.168.x.xx:39500
Lutron Bridge XC0A801CA sent (manual/app) device update
Sending to SmartThings @ 192.168.x.xx:39500
Lutron Bridge XC0A801CA sent (manual/app) device update
Sending to SmartThings @ 192.168.x.xx:39500
Lutron Bridge XC0A801CA sent (manual/app) device update
Sending to SmartThings @ 192.168.x.xx:39500
Lutron Bridge XC0A801CA, Device=40, Button Code=6 Op=6
Lutron Pico mode: push/hold
Sending to SmartThings @ 192.168.x.xx:39500
Lutron Bridge XC0A801CA, Device=39, Button Code=87 Op=9
Lutron Pico mode: push/hold
ST hub at 192.168.1.55 (re-)subscribed to 1 bridge(s) at Wed Oct 10 2018 16:42:51 GMT-0500 (CDT)
ST hub signature=[ '192.168.x.xx', '39500', [length]: 2 ]
ST device list request: 1 bridges
Bridge XC0A801CA device list refreshed
ST device list request: 1 bridges
Bridge XC0A801CA device list refreshed
ST scenes list request: 1 bridges
Bridge XC0A801CA scenes list refreshed
Lutron Bridge XC0A801CA #0 isn't responding [1]
Lutron Bridge XC0A801CA reconnecting...
Disconnected Telnet from Lutron Pro Bridge XC0A801CA
Starting Telnet connection to Lutron Bridge XC0A801CA
Lutron Bridge XC0A801CA confirming Telnet
Lutron Bridge XC0A801CA Telnet Connected!
ST device list request: 1 bridges
Bridge XC0A801CA device list refreshed
ST device list request: 1 bridges
Bridge XC0A801CA device list refreshed
ST scenes list request: 1 bridges
Bridge XC0A801CA scenes list refreshed
Lutron Bridge XC0A801CA #0 isn't responding [1]
Lutron Bridge XC0A801CA reconnecting...
Disconnected Telnet from Lutron Pro Bridge XC0A801CA
Starting Telnet connection to Lutron Bridge XC0A801CA
Lutron Bridge XC0A801CA confirming Telnet
Lutron Bridge XC0A801CA Telnet Connected!
ST scenes list request: 1 bridges
Bridge XC0A801CA scenes list refreshed
Lutron Bridge XC0A801CA #0 isn't responding [1]
Lutron Bridge XC0A801CA reconnecting...
Disconnected Telnet from Lutron Pro Bridge XC0A801CA
Starting Telnet connection to Lutron Bridge XC0A801CA
Lutron Bridge XC0A801CA confirming Telnet
Lutron Bridge XC0A801CA Telnet Connected!
ST scenes list request: 1 bridges
Bridge XC0A801CA scenes list refreshed
Lutron Bridge XC0A801CA, Device=40, Button Code=6 Op=4
Lutron Pico mode: push/hold
XC0A801CA:40:6 button was released in 108126 ms (held)
Sending to SmartThings @ 192.168.x.xx:39500
Sending to SmartThings @ 192.168.x.xx:39500
Lutron Bridge XC0A801CA sent (requested) device update
Sending to SmartThings @ 192.168.x.xx:39500
Lutron Bridge XC0A801CA sent (manual/app) device update
Sending to SmartThings @ 192.168.x.xx:39500
Lutron Bridge XC0A801CA sent (manual/app) device update
Sending to SmartThings @ 192.168.x.xx:39500
Lutron Bridge XC0A801CA sent (manual/app) device update
Sending to SmartThings @ 192.168.x.xx:39500
Lutron Bridge XC0A801CA sent (manual/app) device update
Sending to SmartThings @ 192.168.x.xx:39500
Lutron Bridge XC0A801CA, Device=39, Button Code=87 Op=9
Lutron Pico mode: push/hold
Sorry for the long radio silence, was tied up longer than expected. Your log does show me a couple of problems that I can address (scenes, button LEDs), but the problem with the keypad setup has me scratching my head as to what you are seeing. "I try to add a keypad. After adding the keypad device the app says to "Click Done or Click Back to add another device". But, there isn't a Done button only next. Going with next produces some choices for identifying the button but at this point I get the unexpected error and/or unable to refresh."
Can you attach a screenshot here showing that "Click Done or Click Back to add another device" page that has Next instead? And most interesting to me, one of the page giving "some choices for identifying the button". Should give me a clue.
I'll add that SmartThings doesn't always show the same prompt in the upper right corner, depending on exactly how you reach a particular setup page, so I may have to change to a catchall "Done/Next". But the errors/refresh issue is the real problem. Tx for additional info.
btw I'd still like a look at your QS device XML if at all possible -- you tried to attach it way back, above ("Attached is the xml file that is retrieved."), but it didn't seem to go through.
Glad you still have time to look into this! See if you can access the screenshots here: https://www.amazon.com/photos/groups/share/jsXIuDHwRgu_-FOLSwtffw.E80B6CUHiZUlNNDmYvdlxf
I think they be in order and be self-explanatory but if not let me know. I basically added 3 buttons. Then in trying to save, got and unexpected error. I will send the XML in another email.
Reagan
This is the XML file. DbXmlInfo.zip
OK, I'll put you through a few more paces...
First, would you please try what you were doing before, using the same code base at your RPi and ST, maybe just try adding ONE scene the same way as your examples above... but also look at the SmartThings IDE Live Logging tab when you finish the set and get the "unexpected error" popup on your phone/tablet. There SHOULD be some more warning/error information logged in the Live Logging, which I'd really like to have a look at regardless of #2 below.
After that please grab and install updates from the same beta6 branch of both repositories: update https://github.com/billhinkle/lutronpi-server/blob/beta6/bridges/lutrontelnet-bridge.js (this goes in your lutronpi/bridges directory, overwriting the existing lutrontelnet-bridge.js) update https://github.com/billhinkle/lutronpi-smartthings/blob/beta6/smartapps/lutronpi/lutronpi-service-manager.src/lutronpi-service-manager.groovy (this goes in your ST IDE SmartApps tab replacing the existing lutronpi : LutronPi Service Manager Smartapp... don't forget to [Save] and [Publish] !)
In both cases, be sure not to inadvertently update from the master branch, you want beta6 branch.
Now, the MAIN thing is that instead of adding Scene/Virtual Button (which I have now renamed Scene/Phantom Button), I think you want instead to try add a Device (on the previous setup page in the SmartApp). For Device Type, look all the way to the bottom of the list and choose Keypad. This is my trial-version catchall for all the different non-Pico keypads; it might get fancier later on. Besides the Integration ID, you'll need to put in the maximum button number you think you'll encounter (or just a very large number, for trial purposes.)
I had been assuming that, like the Caseta bridges, phantom buttons (e.g. scenes) were always associated with the main controller at Integration ID #1 but I guess that may not always be true in the larger Lutron world? Anyway, try Keypad device, and maybe also try setting up some of your existing light dimmers or switches (again, as devices) and see how that goes.
thanks for testing
Tried to add keypad button for Library lights. Integration ID 25 Component Number 3. On Homeworks, each button on a keypad represents a scene. Might be just one light but treated like a scene. Mapping keypad button is really all that is needed:
93060f7f-3b06-4537-858d-baa6806dc51a 4:36:41 PM: info The LutronPi Service Manager SmartApp is being uninstalled 93060f7f-3b06-4537-858d-baa6806dc51a 4:36:41 PM: debug Unsubscribing from the LutronPi server B827EB09C88A 93060f7f-3b06-4537-858d-baa6806dc51a 4:36:38 PM: debug {XC0A801CA.1={dni=XC0A801CA.1, name=Library, virtualButton=1}} 93060f7f-3b06-4537-858d-baa6806dc51a 4:36:38 PM: debug {XC0A801CA.1={dni=XC0A801CA.1, name=Library, virtualButton=1}} 93060f7f-3b06-4537-858d-baa6806dc51a 4:36:38 PM: debug [] 93060f7f-3b06-4537-858d-baa6806dc51a 4:36:38 PM: debug at the LutronPi scene list handler 93060f7f-3b06-4537-858d-baa6806dc51a 4:36:37 PM: debug Discovering your LutronPi Scenes 93060f7f-3b06-4537-858d-baa6806dc51a 4:36:37 PM: debug {XC0A801CA.1={dni=XC0A801CA.1, name=Library, virtualButton=1}} 93060f7f-3b06-4537-858d-baa6806dc51a 4:36:37 PM: debug {XC0A801CA.1={dni=XC0A801CA.1, name=Library, virtualButton=1}} 93060f7f-3b06-4537-858d-baa6806dc51a 4:36:37 PM: debug [] 93060f7f-3b06-4537-858d-baa6806dc51a 4:36:37 PM: debug at the LutronPi scene list handler 93060f7f-3b06-4537-858d-baa6806dc51a 4:36:37 PM: debug {XC0A801CA.1={dni=XC0A801CA.1, name=Library, virtualButton=1}} 93060f7f-3b06-4537-858d-baa6806dc51a 4:36:37 PM: debug {XC0A801CA.1={dni=XC0A801CA.1, name=Library, virtualButton=1}} 93060f7f-3b06-4537-858d-baa6806dc51a 4:36:37 PM: debug [] 93060f7f-3b06-4537-858d-baa6806dc51a 4:36:37 PM: debug at the LutronPi scene list handler 93060f7f-3b06-4537-858d-baa6806dc51a 4:36:37 PM: debug Discovering your LutronPi Scenes 93060f7f-3b06-4537-858d-baa6806dc51a 4:36:36 PM: debug Subscribing to SSDP updates for urn:schemas-upnp-org:device:LutronPi_BridgeThing:1 93060f7f-3b06-4537-858d-baa6806dc51a 4:36:36 PM: warn Unable to add LutronPi device as lutronpi:LutronPi Bridge Server with DNI B827EB09C88A [ERR=grails.validation.ValidationException: Validation Error(s) occurred during save():
After updating the groovy and device driver (says Scene/Phantom Button) this is the live logging. (Forgot to update .js code) so this is the revised output showing errors:
11e173e3-d11e-4fa4-a975-832927775e37 6:31:52 PM: debug SSDP event at 1539991912952 name:ssdpTerm value:urn:schemas-upnp-org:device:LutronPi_BridgeThing:1 11e173e3-d11e-4fa4-a975-832927775e37 6:31:52 PM: debug Discovering SSDP updates for urn:schemas-upnp-org:device:LutronPi_BridgeThing:1 at 1539991912089 11e173e3-d11e-4fa4-a975-832927775e37 6:31:17 PM: debug Subscribing to SSDP updates for urn:schemas-upnp-org:device:LutronPi_BridgeThing:1 11e173e3-d11e-4fa4-a975-832927775e37 6:31:17 PM: error Unable to add LutronPi device as lutronpi:LutronPi Bridge Server with DNI B827EB09C88A [ERR=grails.validation.ValidationException: Validation Error(s) occurred during save():
Sorry once again for the response delay. It looks like the SmartApp isn't able to create the child device that makes the connection to the LutronPi server (this: Unable to add LutronPi device as lutronpi:LutronPi Bridge Server with DNI B827EB09C88A). The B827EB09C88A should be the MAC address of the LAN port on the LutronPi Server's host device (e.g. Ethernet port on your Raspberry Pi or whatever). Assuming that is true, I wonder whether you've got ANOTHER SmartThings SmartApp/device already talking to that same hardware, at that same MAC address? Because that would be a problem: SmartThings basically only seems to allow one SmartApp to any one LAN device MAC address. So if you've got something else already tying up that MAC address (e.g. an MQTT bridge to SmartThings? something like that) then you'll have to figure out a way to run on a different LAN port at a different MAC address.
Now it is my turn to be sorry for the very long delay. Was out of the country and out of contact for awhile. The problem is probably exactly what you describe since I have Mosquito running on the same Pi as I was trying to run the Bridge server. I will set up a new Pi for the Bridge Server and try again.
From: Bill Hinkle Sent: Tuesday, October 23, 2018 3:53 PM To: billhinkle/lutronpi-server Cc: txwindsurfer; State change Subject: Re: [billhinkle/lutronpi-server] How to use Telnet not Hub (#2)
Sorry once again for the response delay. It looks like the SmartApp isn't able to create the child device that makes the connection to the LutronPi server (this: Unable to add LutronPi device as lutronpi:LutronPi Bridge Server with DNI B827EB09C88A). The B827EB09C88A should be the MAC address of the LAN port on the LutronPi Server's host device (e.g. Ethernet port on your Raspberry Pi or whatever). Assuming that is true, I wonder whether you've got ANOTHER SmartThings SmartApp/device already talking to that same hardware, at that same MAC address? Because that would be a problem: SmartThings basically only seems to allow one SmartApp to any one LAN device MAC address. So if you've got something else already tying up that MAC address (e.g. an MQTT bridge to SmartThings? something like that) then you'll have to figure out a way to run on a different LAN port at a different MAC address. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.
I can't use my Lutron Connect bridge but rather want to use the telnet port on the Lutron main repeater. I tried all the modifications I could think of in LutronPiServer.js to use the telnet instead of a Lutron Hub but have not been successful. Thanks