Yes the shades work exactly the same as other dimmers. To get it working I added discovery of the shades in the Smartapp and created a new device type for “SerenaHoneycombShade”. Let me know if you want the code and I’ll work on posting it. Probably should fork @njschwartz repo so I can send a pull request. I just hacked it locally for now.
I’ve seen this issue before somewhere in this thread but I can’t find it now. I’ve got 12 pico remotes hooked up to this server. If I leave out any custom config for ramping then each click works fine but when I set ramping for 2 devices in the config then one click logs two clicks or when I set ramping for 12 devices in the config, 1 click gives me 12 clicks in the log. I’ve tried webCoRe and ABC for my button programming with same result so that’s not it. Any ideas?
I’m having this issue.
Hey I got this setup and its great. Really nice being able to use the Picos to control whatever you want. One quick question, does anyone know if you can run the homebridge server on the same raspberry pi as the Lutron bridge? I’d like to play with homebridge, but not if its going to break my Lutron setup.
Thanks for any answers in advance.
It sure can I have both running on the same server. No issues running them at the same time.
Hey so I got Homebridge running on my pi server now too, but I seem to have broken my Lutron setup somehow. It starts to run, and then I get the following error and it stops:
Connected!
/home/pi/node_modules/node-ssdp/lib/ssdpHeader.js:69
return Buffer.from(this.toString(extraHeaders), ‘ascii’)
^
TypeError: ascii is not a function
at Function.from (native)
at Function.from (native)
at SsdpHeader.toBuffer (/home/pi/node_modules/node-ssdp/lib/ssdpHeader.js:69:17)
at /home/pi/node_modules/node-ssdp/lib/index.js:517:23
at /home/pi/node_modules/async/dist/async.js:3096:16
at eachOfArrayLike (/home/pi/node_modules/async/dist/async.js:1055:9)
at eachOf (/home/pi/node_modules/async/dist/async.js:1103:5)
at Object.eachLimit (/home/pi/node_modules/async/dist/async.js:3158:5)
at SsdpServer.SSDP._send (/home/pi/node_modules/node-ssdp/lib/index.js:507:9)
at /home/pi/node_modules/node-ssdp/lib/server.js:171:10
at Array.forEach (native)
at SsdpServer.advertise (/home/pi/node_modules/node-ssdp/lib/server.js:145:27)
at Timer.listOnTimeout (timers.js:92:15)
any ideas whats wrong?
I got the issue of the repeating commands solved. I just undated Node from v 7 to v 9 and did a fresh install of lutronpro and it works. Now that I have ramping working, I’m wondering what some of you are using for ramping with ABC… I’ve tried anywhere from 500 ms to 1000ms for frequency in the runNodeServer file and I’ve tried anywhere from 3% to 15% per command in ABC smart app. I’m controlling window blinds with my picos and it seems a bit laggy. By the time I let off the button, it’s already sending more commands…
I managed to fix it by reinstalling Nodejs. all good again. thx
If anyone is interested in trying a rather extensive update of this Lutron/SmartThings lashup, I’ve got one that handles multiple Lutron bridges and improved communications, among many other changes.
I’ve forked Nate’s stupendous work into a new version I’ve re-badged as LutronPi 2.0.0. Unfortunately, it’s different enough that it’s not backwards compatible – if you want to try it you’ll need to get both the new SmartThings bits and the new Node.js server bits. (It’s also different enough that I had to just fork it from LutronPro rather than do a pull request, hence the new name. (attn: @njschwartz , check my license and attributions and copyright assignment – let me know if you find anything problematical! )
- handles multiple Lutron bridges at once, with a consolidated device list at SmartThings
- does not require you to store your Lutron id/password in-the-clear.
- automatically discovers Lutron bridges, and the SmartThings hub, on your local network - no IP addresses required
- extensive automatic communications recovery in case of disconnects, bridge power loss, change of IP addresses.
- server restart handshake with SmartThings to ensure reconnect and refresh dimmer levels, etc.
- Lutron shades support (rather thinly tested so far, I’m sorry to say, try it and let me know!)
- dimmer fading (ramping-over-time) for Pro only
- all (?) known Pico type supported natively with specific device handlers & enhanced virtual buttons
- all Pico button and timing configuration done at SmartThings end, not at the node server
- Picos can be used for close/open contact triggers in SmartThings upon press/release
- SmartThings virtual Picos can trigger corresponding Lutron functions (optionally)
- trigger other SmartThings events when you trigger a Lutron scene (from SmartThings)
- SmartThings notifications when Lutron bridges change devices, or go offline, or the node server itself goes offline
- revised SmartThings device screens (tiles) and new ones for additional Picos, shades
- and more, though mostly under the covers - see the respective README files
The basic setup is much the same as Nate’s current LutronPro: a server application running under Node.js on some independent computer, laptop, Raspberry Pi or other embedded computer; a set of SmartThings SmartApp and Device Handlers. The respective README files should explain enough to do the setup pretty easily, for anyone that’s been through it before.
The Node.js server end is here: https://github.com/billhinkle/lutronpi-server
The SmartThings SmartApp and device handlers here: https://github.com/billhinkle/lutronpi-smartthings
See the respective README files in the respositories for more info. btw, I would suggest the current Node.js version 8 or 9, but it SEEMS to work ok on Node.js version 6.11 at a minimum.
I would be VERY interested in any feedback anyone would care to provide, good bad or indifferent. If you try it, feel free to use the respective Github “Issues” tab for feedback. Or direct message me here, if you have extensive logging – probably best not to clutter up this thread with that.
1 Like
@BHO this looks awesome Bill! Can’t wait to give it a go. Should I completely remove v1.0 node server and all Pico remotes from ST before getting started? I use them in webcore pistons so it shouldn’t be a big deal to plug them back into the variables but if it’s not going to hurt running both servers at the same time then that wouldn’t be bad either just to preserve a sure working version. Looks like you’ve made some enhancements to the ramping features which has always given me fits. Could you elaborate on that? The latency was just too bad with ramping (I was using them to control some custom window shades with a DTH that essentially simulated a light) so I eventually just took ramping out of the piston but I’d love for it to work. By the time I let off the button, the window shade would just keep opening for a few more seconds so it wasn’t very useful.
@jacobwtyler ah, I forgot to comment on that issue. I THINK that you can run this version and Nate’s older version in parallel at the same time in SmartThings, but I am 99% sure that you would have to run the Node.js LutronPi 2,x Server on a different computer than the LutronPro 1.x Server. (If not different computers, than at least different interfaces, one on wifi, one on hardwire, e.g, and I couldn’t tell you how to enforce that, actually.) The reason is that SmartThings decides where to send incoming network traffic by MAC address, which of course would be the same if you were running both servers on the same computer. However, I don’t think you’ll break anything if you try!
If the two systems are both running at the same time, of course they will reflect the same Lutron devices, but you wouldn’t have to mess up your current pistons until you wanted to (if ever).
The ramping I changed was to incorporate the intrinsic ramping functions that the Lutron bridge provides for its own devices. So it really doesn’t do much for the lag you see on the Pico buttons hold-to-repeat. It’s just a really, really, long round trip for those button presses since each “repeat” goes from the server to the ST hub to the ST Cloud, through the SmartApp, through the device handler, back to SmartThings cloud, and on to your shade device. So it’s laggy and not much to be done until if/when ST allows that sort of thing to operate entirely locally.
Two notions, though.
I added a feature also implements a contact closure for each Pico press/release cycle, separately from the button pushed/hold/repeat. So you could use a contact-sensing scheme (in a piston, maybe?) that sees the Pico button as a contact rather than a button, and starts moving the shade when you press the button and stops when you release. That might reduce the lag markedly. (Unfortunately, the round trip is SO laggy that I had to implement a minimum closure ‘debounce’ time for this feature to avoid Smarthings deciding the button was opened before it was closed, sometimes. Now that’s lag!) This might be a viable approach, even with a few 100ms of lag remaining.
The other, less convenient, approach: I also implemented an architecture that allows other ‘bridge drivers’ to be plugged into the server, so long as they’re written to emulate the API implemented for the Lutron bridges, and also implemented a way for bridge drivers to eavesdrop on what other bridges are telling SmartThings. So in theory one could write a simple (?) driver to monitor the Pico presses right in the node server itself and do something more direct from there without going through the ST cloud at all. But that’s pretty elaborate 
1 Like
Hi Bill, I’m trying to install your 2.0 on a Pi, and I’m getting 404 not found: lutronpi@latest when I run the install script in the server folder. Any guidance?
Thanks
@adiventure just get in the lutronpi-server directory and run npm install and leave off the lutronpi part. (In my case, sudo npm install because of permission issues). That seemed to download all the node_modules that I needed. someone please correct me if I’m misleading him but I’ve got the server up and running now. Beautiful. I’ll have to test it some other time.
Hmm, when I try to do that I get:
pi@raspberrypi:~ $ node lutronpi-server/lutronpi
/home/pi/lutronpi-server/lutronpi Version 2.0.0 2018.05.10 1200Z
internal/modules/cjs/loader.js:550
throw err;
^
Error: Cannot find module ‘loglevel’
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:548:15)
at Function.Module._load (internal/modules/cjs/loader.js:475:25)
at Module.require (internal/modules/cjs/loader.js:598:17)
at require (internal/modules/cjs/helpers.js:11:18)
at Object. (/home/pi/lutronpi-server/lutronpi.js:64:13)
at Module._compile (internal/modules/cjs/loader.js:654:30)
at Object.Module._extensions…js (internal/modules/cjs/loader.js:665:10)
at Module.load (internal/modules/cjs/loader.js:566:32)
at tryModuleLoad (internal/modules/cjs/loader.js:506:12)
at Function.Module._load (internal/modules/cjs/loader.js:498:3)
@adiventure That would be because npm is looking for lutronpi as a project on the npm repository website rather than the local copy that you’ve already put in place. I’m guessing that the server files ended up in a slightly wrong configuration. Maybe you ended up with a directory structure ‘one level too deep’ like lutronpi/lutronpi-server/package.json and so forth?
I’ve clarified the README just now to show that if you’re using ‘git clone’ that you should specify the (empty!) directory that you want to clone into, for example
git clone https://github.com/billhinkle/lutronpi-server lutronpi
However you copy the files into your local directory, you should have in the top directory:
package.json lutronpi.js LutronPiServer.js (and some other stuff) along with bridges/ and lib/ subdirs
npm install lutronpi says (in this case) “install the application in the lutronpi directory according to the package.json file you find in that directory”.
So best bet is to clean things out entirely and redo, or just move the existing files around to the right level, or even just npm install whateverthedirectoryis that actually contains the package.json file.
Let me know if that straightens things out of if there is further trouble. Sorry for the difficulty!
EDIT: Yep, looks like @jacobwtyler had exactly that situation and just chose to work with the existing directory arrangement. Apologies for the vague git command! I am a git noob.
That’s odd as I thought I had it at the right directory level, i.e. home/pi/lutronpi-server, which is where, as I understand it, commands kinda default to on Pi. Should it be /lutronpi-server instead?
In essence I’m getting two separate errors, the original NPM one, but also the Cannot find module ‘loglevel’ one. Are they the same cause? @BHO
@adiventure Sorry about all that – it’s all about how npm handles directory names vs. module names, apparently.
Your location starting with /home/pi is just fine. At this point, I think the EASIEST fix is to rename the application directory (while you’re currently in its parent /home/pi ):
mv lutronpi-server lutronpi
and then (now that you have /home/pi/lutronpi with package.json & lutronpi.js IN that subdir):
npm install lutronpi
should install the application properly (by downloading the modules it needs, loglevel being just the first of many). Once that goes through
node lutronpi
or
node lutronpi/lutronpi
should get things started, fingers-crossed.
@bho No problem with the name change, but still getting the 404 at the install step:
pi@raspberrypi:~ $ mv lutronpi-server lutronpi
pi@raspberrypi:~ $ npm install lutronpi
npm ERR! code E404
npm ERR! 404 Not Found: lutronpi@latest
npm ERR! A complete log of this run can be found in:
npm ERR! /home/pi/.npm/_logs/2018-05-18T00_48_52_594Z-debug.log