[OBSOLETE] LutronPro Caseta v1.0

Wiki Projects & Stories
, ,
143

so i got a pro hub and nothing works anymore. I’m still using Nate’s original lutronpro.ps, deleted all cert files and updated the new ip address of the lutron pro bridge.

when i start “node runNodeServer.ps” it creates the certificates, runs for a while (and I can find it in the smartapp) and then ends with this message:
The device ID’s for leap and lip servers do not match! This might cause problems for you.
The merged data is:
[{“href”:"/device/1",“Name”:“Smart Bridge”,“FullyQualifiedName”:[“Smart Bridge”],“Parent”:{“href”:"/project"},“SerialNumber”:32556155,“ModelNumber”:“L-BDGPRO2-WH”,“DeviceType”:“SmartBridge”,“RepeaterProperties”:{“IsRepeater”:true},“ID”:1},{“href”:"/device/2",“Name”:“Pico”,“FullyQualifiedName”:[“Master Bedroom”,“Pico”],“Parent”:{“href”:"/project"},“SerialNumber”:30755654,“ModelNumber”:“PJ2-3BRL-GXX-X01”,“DeviceType”:“Pico3ButtonRaiseLower”,“ButtonGroups”:[{“href”:"/buttongroup/2"}],“AssociatedArea”:{“href”:"/area/2"},“ID”:4},{“href”:"/device/3",“Name”:“Main Lights”,“FullyQualifiedName”:[“Living Room”,“Main Lights”],“Parent”:{“href”:"/project"},“SerialNumber”:22387296,“ModelNumber”:“PD-6WCL-XX”,“DeviceType”:“WallDimmer”,“LocalZones”:[{“href”:"/zone/1"}],“AssociatedArea”:{“href”:"/area/3"},“ID”:3},{“href”:"/device/4",“Name”:“Pico”,“FullyQualifiedName”:[“Living Room”,“Pico”],“Parent”:{“href”:"/project"},“SerialNumber”:28559669,“ModelNumber”:“PJ2-3BRL-GXX-X01”,“DeviceType”:“Pico3ButtonRaiseLower”,“ButtonGroups”:[{“href”:"/buttongroup/3"}],“AssociatedArea”:{“href”:"/area/3"},“ID”:4}]
About to exit with code: 1
events.js:183
throw er; // Unhandled ‘error’ event
^

Error: connect ETIMEDOUT 192.168.1.2:23
at Object._errnoException (util.js:1022:11)
at _exceptionWithHostPort (util.js:1044:20)
at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1182:14)

Any ideas?

144

The actual crash isn’t (at least directly) coming from the “do not match!” warning.

The actual crash is a communications timeout with the Lutron bridge. The error message indicates it’s unable to connect the Pro-only Telnet communications channel (port 23).

Did you enable the Telnet support in the Lutron app (for this new Pro bridge)? Settings / Advanced / Integration / Telnet Support -> ON.

Hopefully that’s all it is for this one, so take a look. Barring that, I’d be interested in whether, if you scroll up on your server logging info, it at some point says “Telnet connected” or words to that effect, during startup.

However, even after that’s fixed, you still likely to be subject to the earlier “hang up” problem that you experienced with the Standard (non-Pro ) bridge, which is most certainly still present with the Pro bridge. Mine, anyhow!

If you get past THIS issue and run into the previous issue, you might still try the keep-alive-pinger version I mentioned above, a few days ago in this thread. There’s been ONE positive report so far, anyway.

As for the “do not match” warning, I think this particular case is due to you having two devices with the same name, albeit in different rooms (areas). Nate is currently only matching devices by name, not considering the Area field. So both of these “Pico” devices get matched to the 2nd instance, device ID 4.

Suggestion: rename one or both of the Pico devices in the Lutron app (to different names from each other, that is) and I suspect that will cure this warning. Hopefully. (There is a larger issue with these IDs that Nate has been trying to resolve, but hopefully this ain’t that.)

145

@BHO, I wasn’t aware of the Telnet setting. That got rid of the error message. I switched over to the ping version of lutronpro.js and renamed the Pico devices.

Everything seems to be working so far, I see the occasional “Ping!” in the command window.

Thank you so much, really appreciated!

146

Hi @BHO and @njschwartz I just want to report back and let you know that the periodic ping seems to be able hold the connection okay for me for days so it is a great improvement. The only minor issue I see now is that during process startup the current light level status is not reported to the server and therefore the smartthings app does not reflect the right values initially until you use the light at least once.

Best regards,
KK

147

Yeah, I had noticed that also. There’s not a real distinct “reconnection“ process between the hub and this server after configuration; they just sort of resume conversation. So long as the hub is listening to the server, I suppose there’s no harm in just shoving a status report up the wire upon initialization. That won’t help the case when the hub resumes after a power failure or (as yesterday) firmware update. Ideally the hub would ask for status update from the server when the hub reboots, or when it notices that the server has rebooted. But for the time being, maybe a quick update on server reboot can be patched in; I’ll take a look (unless Nate gets there first, don’t want to step on his toes!)

148

If I remember correctly, the status request on demand (the looping arrow button) doesn’t work either, right? Or it only works on standard bridge, I don’t remember. I think the status request handler code got a little messed up when Nate was converting the server back from pro only to pro-or-standard. I’ll see if I can move my patch over for that too.

149

@BHO running your script now for a long time working fine with the ping! Yesterday was the first error:
Ping!
About to exit with code: 1
events.js:183
throw er; // Unhandled ‘error’ event
^

Error: read ECONNRESET
at _errnoException (util.js:1022:11)
at TLSWrap.onread (net.js:615:25)

You mentioned a hub firmware update, I assume that was responsible for this?

150

Probably not DIRECTLY, no: the hub firmware update I referenced was the SmartThings hub getting an update, and this error is due to the Lutron bridge disconnecting.

The pinger will only encourage the Lutron bridge to stay connected if nothing else comes up, but I suppose there are any number of reasons for it to disconnect beside the timeout that the pinger is handling. For example, the Lutron bridge might’ve gotten a firmware update over the weekend too (without telling us!) and disconnected for a bit while updating and rebooting. Or it could’ve rebooted for some other reason.

In the long run, having a robust re-connection mechanism in the node server code would be best, but in the short run you can get around this kind of intermittent disconnect by starting the node server (runNodeServer.jr) from the pm2 utility or something similar (see the discussion of this, waaaay above). Among other things, pm2 will just restart the node server if it crashes, and you can set it up to restart the node server when its host computer restarts (I think you’re running Windows? but also Linux, etc.) Take a look here: http://pm2.keymetrics.io/docs/usage/quick-start/

(p.s. it’s not impossible that an interruption in the SmartThings communication, during some attempt to talk to it, might crash the app too… but this looks like it was caused from the Lutron end entirely)

151

@KKFH and @Doerfler too if you’re interested:

I did paste up yet another patched version of Nate’s code for the node server (lutronpro.js) that not only includes the 5-minute pinger, but now also:

  • restores the function of the ‘refresh’ button on the dimmer device page (the loopy arrow); it will now request the current level of the dimmer and update itself (e.g. if it gets out of sync with the Lutron)
  • will push the current level of all the dimmers up to the SmartThings hub when the node server starts up (or so I hope; I only have one dimmer to test!).

Give it a shot if you wish:

where the lutronpro.js file replaces the one you have in your node_modules/lutronpro folder.

But PLEASE make sure you keep a safety copy of any previous file so you have a fallback! No guarantees :slight_smile: but I’d be interested in your results or horrors.

The startup-time update is all kinda iffy because there’s really no guarantee that the SmartThings setup knows anything at all about the devices being refreshed, or that the Lutron devices haven’t changed, etc. (Esp. due to the ongoing problem with LEAP vs. LIP device numbers, which Lutron seems to change willy-nilly!) But shouldn’t hurt anything in any case, and seems to work in the USUAL case.

152

Thanks for the update, @BHO. I just installed the latest version and I do see in the std output that the zone settings are printed out. However, on the ST app the light level doesn’t seem to refresh properly, even after I pressed the refresh icon. These are the steps of how I can reproduce the issue:

  1. Start the node server
  2. Start the ST app and set some level on the app so that it is say at 50%
  3. Go to manually increase the light level to say 75%
  4. Go back to the app to see what it says. It will still say 50%
  5. Try to refresh the light status using the loopy arrow refresh icon and it still stays the same, even though something does seem to happen on the stdout of the node server.
153

@kkfh, ah well, that’s the risk of working from a sample of one unit! (mine, that is)

There’s something different about your setup than mine, clearly, but what? One particular thing of interest is your items #3-4 - I sort of remember that that works (worked!) ok with the original/official Nate’s ‘name brand’ lutronpro.js . Was that your experience? That is, with everything up and running, changing the actual physical dimmer switch would show up as a change at the SmartThings app page for that dimmer. Hate to think I made things worse, but…

I have a feeling it’s this tangle with the device IDs. You’ve got a Pro hub, right?

Couple of things you can do if you feel like pursuing this:

  1. Grab the entire log for that repro, just as you described it, and paste it in a note so I can take a peek. Maybe paste it at https://justpaste.it and just put the link into a reply here instead of pasting the whole thing in the thread. (I don’t think your password would show up in the log, but double-check!)

  2. If you want to go a step further, go to your SmartThings dev page at https://ide.smartthings.com and after logging in of course, go to Live Logging (top menu, near the right). Run through your repro again and capture THAT to paste and link. That’ll be interesting and useful too. That shows what SmartThings thinks is going on.

  3. While you’re there, also go over to the My Devices page (further to the left on the top menu and select the dimmer you’ve been using for your repro. Grab THAT page to the clipboard, paste and link. That’ll show what ST believes about the dimmer device.

Comparing all three of those items would be very revealing, but even #1 would be a good start. I don’t know if you care that much, sounds like a lotta work! But if you collect it, I’ll debug it.

154

@BHO - just some quick responses first before I go collect the debug logs:

  • My hub is non-Pro.
  • I did confirm that with your previous script (1.1.0.1) when I turn on and off the device using the wall control the ST app does reflect the on/off status properly. With 1.1.0.2 the on/off status is no longer properly reflected. So that functionality seems to have regressed for me. Does it still work for your setup?
155

Yep, it does still work OK on my setup, so the basics are still there; hopefully it will jump right out of the logs. I hope.

I have a Pro hub here, which I have rigged up in code to ‘simulate’ being a standard hub for testing… but it wouldn’t surprise me if there was some difference in the real thing that I haven’t accounted for. I do have a non-Pro hub I haven’t activated, so I can drag that out too if needed for diagnostics.

156

@BHO @kkfh I will try to install new version tonight (but not sure if i’ll find the time) and then report back…

157

@Doerfler thanks, nice to have another data point, and a Pro bridge at that. I think I did fix @kkfh 's issues with the standard bridge, but we shall see .

158

@Doerfler fwiw, the teething problems were indeed fixed and that update-SmartThings-levels-on-node-server-startup feature seems to be working correctly now on my tweaked version of lutronpro.js

159

@BHO runs beautifully. So far no problems.

Thanks!

160

Hey all! I just want to say sorry for not being around that last month or so. :confused: I haven’t abandoned this by any means, but haven’t had time to work on anything either. Thanks so much @BHO for taking up some of the issues, it is greatly appreciated. Don’t worry about stepping on toes at all. If you can improve it go for it.

Anyway, I do have some time over the next few days to look into things a bit so if there are still some issues/suggestions let me know. Thanks all!

1 Like
161

Does anyone here have a working piston for the Pico Remote? I am trying to get it to work with a non Lutron dimmer but when I add the 4:true, 5:true in the runNodeServer.js I get weird things happening; the lights go on and off , dim then go on again.
When I don’t have buttons 4 and 5 dimming buttons they work as expected.

image
image.png1178×2010 230 KB

162

Did anyone manage to ramp the dimming of lights while pressing the buttons on the pico and not after releasing them?