[OBSOLETE] LutronPro Caseta v1.0

Wiki Projects & Stories
, ,
224

I went to use the pico today and it didn’t work. When I did the systemctl status lutron command, here is what I found:

Mar 13 02:05:00 raspberrypi2 node[377]: Device update recieved
Mar 13 02:05:00 raspberrypi2 node[377]: likely a manual change
Mar 13 02:05:00 raspberrypi2 node[377]: Received: ~OUTPUT,3,1,0.00
Mar 13 02:05:00 raspberrypi2 node[377]: Device update recieved
Mar 13 02:05:00 raspberrypi2 node[377]: likely a manual change
Mar 13 02:05:00 raspberrypi2 node[377]: Received: ~OUTPUT,5,1,0.00
Mar 13 02:05:00 raspberrypi2 node[377]: Device update recieved
Mar 13 02:05:00 raspberrypi2 node[377]: likely a manual change
Mar 13 11:27:02 raspberrypi2 node[377]: Received: shutting down the integration
Mar 13 11:27:02 raspberrypi2 node[377]: Disconnected from SmartBridgePro

I then rebooted the rapsberry pi and it started working again. But, here’s what the systemctl status lutronpro looks like now. Any suggestions what is happening?:

Mar 14 19:09:51 raspberrypi2 node[383]: Buffered data is proper json
Mar 14 19:09:51 raspberrypi2 node[383]: {“CommuniqueType”:“ReadResponse”,“Header”:{“MessageBodyType”:“OneZoneStatus”,“StatusCode”:"200 O
Mar 14 19:09:51 raspberrypi2 node[383]: true
Mar 14 19:09:51 raspberrypi2 node[383]: data in listenSSL
Mar 14 19:09:51 raspberrypi2 node[383]: Buffered data is proper json
Mar 14 19:09:51 raspberrypi2 node[383]: {“CommuniqueType”:“ReadResponse”,“Header”:{“MessageBodyType”:“OneZoneStatus”,“StatusCode”:"200 O
Mar 14 19:09:51 raspberrypi2 node[383]: true
Mar 14 19:09:51 raspberrypi2 node[383]: Received: ~OUTPUT,5,1,100.00
Mar 14 19:09:51 raspberrypi2 node[383]: Device update recieved
Mar 14 19:09:51 raspberrypi2 node[383]: likely a manual change
~

225

I never got a response on this, but I still have the issue so I’m reposting it (the forum gods be damned)…

One new thing I’ll preface with is that I can’t seem to uninstall the app (wanted to try re-installing it). I get an unknown error message - both from the app and the IDE. I imagine it I cleared the code out of the actual smart app and re-published, lots of interesting things would happen… but I think I’ll skip that one. I can only guess its indirectly trying to tell me that its got something associated with it and wants me to disassociate “it” from the app first, but there doesn’t seem to be any indication of what it is… Anyway…

Original post:

I don’t know how it happened, but I ended up with 2 pico remotes with the same creative name… “Pico”. What’s annoying is that regardless of changing it in the Lutron app or the ST app, in the list of ‘Select Pico’s’, they always show up as “Pico”. I pulled this out of the ST installed apps state info:

{
30736646={
	deviceType=Pico3ButtonRaiseLower,
	name=BedroomPico,
	deviceID=9,
	hub=80687123-79c6-4880-b63a-1064b0e2d107,
	dni=30736646,
	hubIP=null
},
29941572={
	deviceType=Pico3ButtonRaiseLower,
	name=LRPico,
	deviceID=6,
	hub=80687123-79c6-4880-b63a-1064b0e2d107,
	dni=29941572,
	hubIP=null
},
28749349={
	deviceType=Pico3ButtonRaiseLower,
	name=Pico,
	deviceID=10,
	hub=80687123-79c6-4880-b63a-1064b0e2d107,
	dni=28749349,
	hubIP=null
},
11923899={
	deviceType=Pico3ButtonRaiseLower,
	deviceID=8,
	name=ALLPico,
	hub=80687123-79c6-4880-b63a-1064b0e2d107,
	dni=11923899,
	hubIP=null
},
11799027={
	deviceType=Pico3ButtonRaiseLower,
	deviceID=7,
	name=Pico,
	hub=80687123-79c6-4880-b63a-1064b0e2d107,
	dni=11799027,
	hubIP=null
}

}

For a while I was getting this error, but I think it may be unrelated as I was having some issues and ultimately ended up needing to reboot the SBPro:

Error: This socket has been ended by the other party
at TLSSocket.writeAfterFIN [as write] (net.js:365:12)
at /usr/local/lib/node_modules/lutronpro/lutronpro.js:626:30
at Layer.handle [as handle_request] (/usr/local/lib/node_modules/lutronpro/node_modules/express/lib/router/layer.js:95:5)
at next (/usr/local/lib/node_modules/lutronpro/node_modules/express/lib/router/route.js:137:13)
at Route.dispatch (/usr/local/lib/node_modules/lutronpro/node_modules/express/lib/router/route.js:112:3)
at Layer.handle [as handle_request] (/usr/local/lib/node_modules/lutronpro/node_modules/express/lib/router/layer.js:95:5)
at /usr/local/lib/node_modules/lutronpro/node_modules/express/lib/router/index.js:281:22
at Function.process_params (/usr/local/lib/node_modules/lutronpro/node_modules/express/lib/router/index.js:335:12)
at next (/usr/local/lib/node_modules/lutronpro/node_modules/express/lib/router/index.js:275:10)
at jsonParser (/usr/local/lib/node_modules/lutronpro/node_modules/body-parser/lib/types/json.js:109:7)
at Layer.handle [as handle_request] (/usr/local/lib/node_modules/lutronpro/node_modules/express/lib/router/layer.js:95:5)
at trim_prefix (/usr/local/lib/node_modules/lutronpro/node_modules/express/lib/router/index.js:317:13)
at /usr/local/lib/node_modules/lutronpro/node_modules/express/lib/router/index.js:284:7
at Function.process_params (/usr/local/lib/node_modules/lutronpro/node_modules/express/lib/router/index.js:335:12)
at next (/usr/local/lib/node_modules/lutronpro/node_modules/express/lib/router/index.js:275:10)
at expressInit (/usr/local/lib/node_modules/lutronpro/node_modules/express/lib/middleware/init.js:40:5)

In any case, the pico naming is (apparently) my “squeaky wheel” at the moment as the above error stopped occuring. I did a little searching and it doesn’t like like I can directly edit the app data without adding some code to the app to let me change it etc.

Any idea why the names wouldn’t update? Or is that on purpose and I just did something dumb after not reading all of the posts (wouldn’t be the first time…)

227

I believe “shutting down the integration” is a message from the Lutron Pro Bridge itself, as it disconnected its Telnet channel to the node server. No idea why it would do that… maybe to install a firmware update? The node server is not really currently equipped to figure that out and reconnect by itself.

Not sure I see a problem with your log after rebooting the Pi… those just look like dimmer (zone) level updates from the Lutron bridge, which should get passed along to the SmartThings hub.

228

@Jeff_Johnson fwiw both I and Mr. @SmartHomePrimer (Doug) replied to your original query on February 6th – scroll up a ways and you should see those. Doug had a possible recovery approach, for one point of interest.

Aside from those earlier notes, your question made me wonder what a preferred device renaming strategy would be… it’s kind of the worse of both worlds right now. SmartThings (re-)names persist regardless of what Lutron says subsequently? Or even propagated all the way back to Lutron? (I think I figured out how to do that…) Or, Lutron (re-)names always overwrite SmartThings names, even if renamed?

229

Gah - I think I was looking for an ‘@’ and din’t notice that you actually replied to mine… Sorry - I’ll take a closer look. I’m used to the old forums where the replies got indented etc. Its not quite as obvious in this new style thats taken over. :man_shrugging:

230

Ok - so I went back through what you wrote - and the write up on installation and I think something’s up because I even removed the picos from the lutron pro, so it shouldn’t be discovering anything at all, but I still see 5 things (unchecked) showing up in the Service Manager. Not sure if I just completely mucked things up or what - though I believe at some point I had started with njschwartz’s version then switched to yours… but I’m pretty sure all the important bits for connecting etc. didn’t change…(?)

231

@Jeff_Johnson hmmm I have a faint memory of having ‘stuck’ devices and SmartApp when I first started poking at this setup, and I believe the issue might’ve been that I still had references to the stuck devices in other SmartApps. Like the Advanced Button Controller app, probably. So maybe double-check for that possiblity, where you might’ve selected the Picos elsewhere and need to de-select them and THEN delete?

Barring that, you might be able to kill them off by going to the SmartThings IDE (where you install the SmartApp originally), and go to the Devices page, select a stuck device, and Delete from its own page, that button being wayyy at the bottom. (Sorry if you’ve already tried that and I missed it.)

If one or the other or both approaches works, then once you’ve gotten rid of the stuck devices you should hopefully be able to remove the SmartApp (service manager) itself. (I’ve been able to kill all devices by just removing the SmartApp itself, but I guess that’s when everything is working properly.)

232

Thanks…not a programmer, but it would be nice if it could re-connect or at least let us know through the app it is disconnected…

233

Lutron Pro Service Manager SmartApp caches them permenently until the app is removed. It’ll find new ones when added to the Lutron Caséta app, but it won’t release the old ones.

  1. In the SmartThings app, go into My Home and delete all your Picos
  2. Go into Automation and delete the Lutron Pro Service Manager SmartApp
  3. Double-check in the Lutron Caséta app that your picos are named the way you want them.
  4. Go into Marketplace > SmartApps and reinstall the service manager (it’ll find your node.js server and your pico again, but you have to be paitent. They don’t show up right away).
  5. Go into ABC and reassign your mappings to the correct Picos (If you’re not using Advance Button Controller, you really should. It’s a great SmartApp). There’s no need to redo the mapping with ABC, you just point the saved mappings at the correct pico remotes, save, save again, and you’re done!
234

Noticed a weird situation. Haven’t looked into the code to try to fix it. I had this running just fine on an RPi, but don’t like the Pi for reliability reasons. Setup a VM to run it in since I couldn’t figure out a way to get SSDP to work in a docker container.

Removed everything from ST, went to Marketplace to install the app. It detected both the RPi and my VM. I chose the VM IP address, but it kept trying to get all the devices from the RPi IP address, and would just sit there not discovering any devices even though the RPi should have had them. Finally, I unplugged the RPi and started over, and everything worked fine from my VM setup.

235

Hey, sorry, kept getting busy to follow up - I think in the end it was the RPi that needed to be removed from the devices and re-added. I had pulled all the lutron devices, picos and otherwise and still couldn’t uninstall the app (just gave a vague error like, ‘error.’) Once the pi was gone, the app let go. In retrospect, I wonder if I had started there if it would have solved the problem - removing and re-adding the pi.

Suffice to say, everything’s back online and working - using ABC too, though (have this same problem with the Hue remotes), the secondary functions (held), while useful, I always forget about… I should start labeling things :stuck_out_tongue:

Thanks for the help!

1 Like
236

I have the same problem. Have to open the app to remember what the Hue Dimmer’s “other” functions do! :grin:

If you really want to get lost in what your Hue Dimmer can do, check out iConnect Hue. He lets you program up to 5 pushes, plus a hold function per button!

237

Dear god… I can only imagine trying to get my GF to remember that… I have a hard enough time getting her to use the --1-- command she uses for ‘hey google’ (face palm every time).

238

hey @bradsileo I’m guessing that you’re using the Telnet interface to talk to the shades? Can you share what the LAN traffic looks like for typical shade operations… I suppose the Telnet uses the same DEVICE/OUTPUT verbs as the dimmers, but do you have any typical {Communique} status messages? Which would be useful for non-Pro.

239

Update: I resolved my issues by removing all 25 Lutron local lights and remotes and removing everything and reinstall everything… I leave the rest here as a reference.

Hello

I have an issue just with all remotes (but for a test I was working with device 11), but the lights turn on and off via this implementation… remotes were working in the past. I did move to a new PI installation and that may be caused it or it could be something else. I’m not sure what I should do now… I did try deleting device 11 in the IDE and rediscovered it in the app. I did the same with the PI. I deleted all the certs on the PI and it recreated them just fine. I deleted all the node files (except sh run script) and did ‘npm install lutronpro’ again… still the button events don’t make it to ST (nothing in the app or IDE)?

This is what is see when I press button 1 for a very short time in the node command line window:

Received: GNET> 
Connected!
Received: ~DEVICE,11,2,3

11
[ { '4': true, '5': true, device: '3' },
  { '4': true, '5': true, device: '5' },
  { '4': true, '5': true, device: '7' },
  { '4': true, '5': true, device: '9' },
  { '4': true, '5': true, device: '11' },
  { '4': true, '5': true, device: '13' },
  { '4': true, '5': true, device: '15' },
  { '4': true, '5': true, device: '17' },
  { '4': true, '5': true, device: '18' },
  { '4': true, '5': true, device: '20' },
  { '4': true, '5': true, device: '22' },
  { '4': true, '5': true, device: '25' },
  { '4': true, '5': true, device: '26' } ]
4
long hold
Received: ~DEVICE,11,2,4

11
[ { '4': true, '5': true, device: '3' },
  { '4': true, '5': true, device: '5' },
  { '4': true, '5': true, device: '7' },
  { '4': true, '5': true, device: '9' },
  { '4': true, '5': true, device: '11' },
  { '4': true, '5': true, device: '13' },
  { '4': true, '5': true, device: '15' },
  { '4': true, '5': true, device: '17' },
  { '4': true, '5': true, device: '18' },
  { '4': true, '5': true, device: '20' },
  { '4': true, '5': true, device: '22' },
  { '4': true, '5': true, device: '25' },
  { '4': true, '5': true, device: '26' } ]
4
long hold
button was released
253
Received: ~OUTPUT,10,1,100.00

Device update recieved
 likely a manual change
data in listenSSL
Buffered data is proper json
{"CommuniqueType":"ReadResponse","Header":{"MessageBodyType":"OneZoneStatus","StatusCode":"200 OK","Url":"/zone/5/status/level"},"Body":{"ZoneStatus":{"href":"/zone/5/status","Level":100,"Zone":{"href":"/zone/5"}}}}

true

Any idea what I should do next?

240

The node server seems to be working ok with the Pico with ID # 11, from what you posted. And if your device discovery at the SmartThings end seems to work, then communication must be at least partially OK. Perhaps the best next move is to return to the SmartThings IDE and watch the live logging when you press this Pico’s buttons, and see what, if anything is logged. I don’t recall exactly what Nate is logging in that channel, but I think it should show whether the button presses are making to the SmartApp, and hopefully whether they’re making it to the corresponding SmartThings device handler. That might provide a clue.

Any chance the problem is further down the chain, e.g. in the setup of whatever SmartApp or other device handler you’re triggering with the Pico presses?

241

Just a heads-up to the other Lutron users here: chatter on one of the Lutron homebrew boards suggests that a new Lutron bridge firmware update is being rolled out that kills their Lutron communications interface ( Home Assistant, in this case). Some reports suggest a change in the SSL certificate/authentication and some suggest a different (or additional) change. (I just rebooted my Lutron bridge here to see if it would do a firmware update, but nothing yet on my account.)

So it might hit this project’s code as well, depending on what the changes do. Don’t know yet, but forewarned is forearmed, I guess.

242

annnnddddd… minutes after that post, my Lutron bridge apparently finished quietly downloading new firmware, rebooted itself and installed that firmware, and crashed the node server with an SSL invalid certificate error.

Good news is that (so far) just a erase/rm of the appCert, localCert, privateKey certificate files and restarting the node server did seem to rebuild usable new certificates, and I’m back up and running. Hopefully that will also work for anyone else that gets hit with this change. (And hopefully there are no further down-the-road complications)

243

Figures… finally get the kinks worked out… Wonder if their firmware updates come via a different URL/Domain/IP that I could block on my router without disturbing the app/remote access… Normally I like to be on the bleeding edge of things (which more often than not, bites me in the ass…), but the ‘beta’ thing doesn’t have that ‘sneaky sneaky’ draw to it that it did when we were… ahem… aquiring copies of Mac OS 8 - Copland (I think it was called) back in HighSchool… such is life. Now its, ‘how do we protect them from themselves’ lol

Here’s hoping they don’t break anything useful…

244

Heh, and mid reply to your post… :stuck_out_tongue: