[OBSOLETE] LutronPro Caseta v1.0

@BHO, found a bug in your code. You don’t handle use cases when there are no buttons added to the Lutron hub which was true in my case.

So when initializing a bridge it was stuck in

Lutron Bridge <id> button groups request

In this case the response was with no content

{"CommuniqueType":"CreateResponse","Header":{"StatusCode":"204 NoContent","Url":"/buttongroup"}}

Once I figured out all this I was able to quickly patch the code: https://pastebin.com/H8A5urCb
Basically just stop waiting for more device updates after receiving a such response.

Hope you can merge it into your repo.

My app has had some crashes and I wonder if this is related. Been compiling screenshots to eventually post. Happens about once a week. Usually it’s after some button pushes. I think it’s related to someone holding a button on a pico as a long press which would indeed be undefined. Hmm.

@nekto - that was not my brightest moment! Nice catch & patch, thanks, will roll it in.

1 Like

@AdamHLG - yep, any logging / screencap / sequence-of-actions info you can supply would be a huge help. I’m guessing you are seeing the crashes at the lutronpi node server end? (As the SmartApp / ST devices would just log an error/warning).

Yes in the node server window. I can kind of see what happened before it crashed but not sure what it means. When it happens I just run it again. I thought I had screenshots but I don’t. Next time it happens I’ll screenshot it. Fortunately it is somewhat infrequent. Now that we’re talking about , it probably won’t happen for weeks.

@AdamHLG - ok, anything you can supply would be a start… I can always bug you for more info later. I’d love to put the problem to the sword!

ok @BHO it just crashed. I am at work and dialed in to get it. I know the housekeepers are there and I suspect they are mashing on the pico or caseta switches or pressing and holding buttons or who knows but they must have pressed or held something to crash it. Here is the text from the RPI window (I took screenshots also and made the RPI window bigger to capture more preceding events, but those events look normal to me from before it crashed):


Lutron Bridge 01F03A34, Device=29, Button Code=2 Op=3
Lutron Pico mode: push/hold
Sending to SmartThings @ 10.107.250.102:39500
Sending to SmartThings @ 10.107.250.102:39500
Sending to SmartThings @ 10.107.250.102:39500
Zone Status Received, Lutron Bridge 01F03A34 Zone 1 to 100%
Lutron Bridge 01F03A34, Device=29, Button Code=2 Op=4
Lutron Pico mode: push/hold
Caught exception: undefined
/home/pi/lutronpi/lutronpi.js:417
throw (err);
^

TypeError: Cannot read property ‘timerQuash’ of undefined
at Bridge. (/home/pi/lutronpi/bridges/lutron-bridge.js:1070:24)
at EventEmitter.emit (events.js:189:13)
at Bridge.picoHandler (/home/pi/lutronpi/bridges/lutron-bridge.js:1136:18)
at Bridge. (/home/pi/lutronpi/bridges/lutron-bridge.js:1037:17)
at Socket.emit (events.js:189:13)
at addChunk (_stream_readable.js:288:12)
at readableAddChunk (_stream_readable.js:269:11)
at Socket.Readable.push (_stream_readable.js:224:10)
at TCP.onStreamRead [as onread] (internal/stream_base_commons.js:145:17)
pi@rpi-caseta:~ $

@AdamHLG - ok, that’s a nice specific error, I should be able to find the bug and straighten that out. Probably trying to access the pico timeout after I’ve already killed the timer. Will advise.

1 Like

So fairly out of the blue I’ve started having trouble with my picos here. Only change has been I set up a different server on a different port but the same pi which is also hooked to a smartapp. As I was catching up here it looked like someone was saying smartthings likes one server per device per smartapp, is that right? If so is there an alternative to getting a second Pi?

Also I know we touched on this @BHO, but is there any way hooking up a second up a second lutron hub would work outside the effective local network? To refresh your memory it’s two routers in parallel both doing dhcp. Recently set up a second one downstairs, mine needs to be separate so it doesn’t get messed with, but it would be nice to be able to automate some of those things together. Currently it’s hooked up to a second smartthings hub with the official lutron integration, but it seems like this could bridge the gap for lighting between the two hubs.

I am still getting these errors fairly regularly now because they seem to be triggered when someone presses and holds a pico button. I know how to use the system, but guests are messing it up.

Sending to SmartThings @ 10.107.250.102:39500
Lutron Bridge 01F03A34 sent (manual/app) device update
Sending to SmartThings @ 10.107.250.102:39500
Zone Status Received, Lutron Bridge 01F03A34 Zone 6 to 0%
Sending to SmartThings @ 10.107.250.102:39500
Lutron Bridge 01F03A34, Device=9, Button Code=8 Op=4
Lutron Pico mode: push/hold
Caught exception: undefined
/home/pi/lutronpi/lutronpi.js:417
throw (err);
^

TypeError: Cannot read property ‘timerQuash’ of undefined
at Bridge. (/home/pi/lutronpi/bridges/lutron-bridge.js:1070:24)
at EventEmitter.emit (events.js:189:13)
at Bridge.picoHandler (/home/pi/lutronpi/bridges/lutron-bridge.js:1136:18)
at Bridge. (/home/pi/lutronpi/bridges/lutron-bridge.js:1037:17)
at Socket.emit (events.js:189:13)
at addChunk (_stream_readable.js:288:12)
at readableAddChunk (_stream_readable.js:269:11)

Any interim suggestions or settings on my end until there is a fix available? Thanks!

Hi @BHO. New user here. I have the code running on nodejs on my Synology NAS. It runs autodiscovery fine (finds my 4 Lutron bridges and connects to the one I didn’t skip) but gets stuck such that my mobile app doesn’t find any LutronPi servers (0 found). Nodejs output ends with:

> Lutron Bridge 01F27FCF confirming Telnet
> Lutron Bridge 01F27FCF Telnet Connected!
> Lutron Bridge 01F27FCA #1 initializing
> Lutron Bridge 01F27FCA #1 did not initialize:  Cannot retrieve persistent authentication
> Requiring  /volume1/homes/admin/lutron2/lutronpi-server-master/bridges/lutron-auth
> ---------------------
> Lutron Bridge 01F27FCA: [Enter] to skip, or enter user:
> ---------------------
> Lutron Bridge 01F23F9B #2 initializing
> Lutron Bridge 01F23F9B #2 did not initialize:  Cannot retrieve persistent authentication
> ---------------------
> Lutron Bridge 01F23F9B: [Enter] to skip, or enter user:
> ---------------------
> Lutron Bridge 01F23FA1 #3 initializing
> Lutron Bridge 01F23FA1 #3 did not initialize:  Cannot retrieve persistent authentication
> ---------------------
> Lutron Bridge 01F23FA1: [Enter] to skip, or enter user:
> ---------------------
> Discovering SmartThings hub on local network...
> 
> ...SmartThings hub mDNS found / now 1 service(s) : Thu Jan 31 2019 20:06:26 GMT-0500 (EST)
> ...SmartThings hub mDNS IP: 192.168.1.36
> ...SmartThings hub mDNS Name: 24FD5B000005613E
> ...SmartThings hub mDNS FQDN: 24FD5B000005613E._smartthings._tcp.local
> ...SmartThings hub mDNS Host: 24FD5B000005613E._smartthings._tcp.local
> ...SmartThings hub mDNS TTL (sec): 120
> Listening for SmartThings requests at 192.168.1.30:5002...
> Sending to SmartThings @ 192.168.1.36:39500

I see in the ST logs:

a53e7638-e65e-4659-95b0-cef76db04874 7:29:19 PM: debug Discovering SSDP updates for urn:schemas-upnp-org:device:LutronPi_BridgeThing:1 at 1548980959818

a53e7638-e65e-4659-95b0-cef76db04874 7:29:19 PM: debug Performing initial LutronPi discovery

a53e7638-e65e-4659-95b0-cef76db04874 7:29:19 PM: debug Subscribing to SSDP updates for urn:schemas-upnp-org:device:LutronPi_BridgeThing:1

And on the LAN, I see SSDP Notify broadcasts from the NAS with NT: urn:schemas-upnp-org:LutronPi_BridgeThing:1

Suggestions? Thanks.

@BHO, this turned out to be an issue with my switch configuration; it isn’t handling multicast properly. I got things working by plugging the NAS, Lutron bridge, and Smarthings Hub directly into my router. I’ll diagnose the switch configuration next (probably by adjusting the IGMP snooping setting, or some such) but wanted to let you know it doesn’t seem to be an issue with the code. I did upgrade to beta6 in hopes that would help. I’ll let you know if I encounter any issues. Thanks.

I am a little worried about Bill - he usually posts pretty quickly on this thread I hope he is ok.

@BHO just FYI if you do see this one day my errors never went away. I was able to trigger the error every time someone pressed and held any Pico remote button. That would knock the RPI node server offline. I ended up getting a Hubitat hub (which also supports multiple Lutron hubs) and the system is working under that methodology. As such I temporarily removed the RPI in favor of that solution. However, I still use ST for a few devices not compatible with Hubitat and if the crashing issue gets fixed one day I would like to re-implement this code. Thanks for all your hard work as always.

Any reason why it shows only the picos that are already paired with switches, the one not paired is not shown

I’m having the exact same “undefined timerquash” error as above, but basically, every single day at least once a day. I’d say it’s pretty much every time I actually use one of my devices. I’ll attach a screenshot.
FWIW, I’m probably the only person who ever uses these Pico’s, and I’m very careful not to hold them down. I click them very quickly, but the tiny led on them blinks rapidly for a couple of seconds, which makes it feel like it’s still sending a signal long after I click. (Whether it actually is, who knows…)

At any rate, I hope this bug can be fixed. This is such a great program, and the capability of using these Pico’s around the house sure would be handy.

Thanks

I hate to tempt fate here, but shortly after posting that, I changed the “Hold Timeout” setting to off on my Pico device settings in ST, and I haven’t had another one of these crashes.
I don’t really know the purpose of this setting, but based on the nature of the error, having “timer” in it, I figured I’d mess with anything that seemed to have to do with timers or timeouts.

Screenshot below, and if anyone knows what this or the setting above it does, I’d love to know. And I hope the author is ok.

1 Like

Thanks for this heads up! I will give it a try if I end up re-installing this code. The crashes became a problem because my family mashes on these Picos instead of a civilized short press like I do. I happened to read a thread about Hubitat and learned it has built in local support for dual Lutron hubs. for $99 I figured I would give it a try and, to my surprise, not only did it work, but it worked locally, and there was zero lag whatsoever. And when I say zero lag, I mean press a Pico - and my hue light instantly responds because Hubitat also runs the Hue Bridge locally. I still use SmartThings for other aspects of my HA however my Caseta system and Hue bridge are now migrated to Hubitat and I could not be happier. I use SharpTools.io for the front end to control the lights (in case you are curious) because there is no app (yet) for Hubitat.

But if you find this fixes the issue, I may run the code on the RPI again if I need to trigger lights or need Pico support for HA devices not yet supported by Hubitat (like Ring doorbell).

I do hope @bho is ok. He was very helpful to me (immensely helpful) and his sudden silence is curious. But maybe he just moved on to other projects too.

2 Likes

No problem. Hopefully it’s helpful to somebody. Hopefully it’s helpful to me! Still can’t be 100% sure my continued luck with the uptime is due to changing this, but so far so good. Looking at my Docker logs, I can see that before that setting, I was having to start the script 2-4 times/day. The last time I did that now was immediately after I posted that first screenshot, which was 3 days ago. I suppose I could see if it reaches a week milestone of uptime and then experiment with turning the setting back on to see if it crashes anything.

I will say, looking at the current output of the terminal on my LutronPi Docker, I have several entries where it says the button was “held:”

Lutron Pico mode: push/hold

Sending to SmartThings @ 192.168.86.81:39500

Lutron Bridge 01F281B0, Device=9, Button Code=2 Op=4

Lutron Pico mode: push/hold

01F281B0:9:2 button was released in 304 ms (held)

I can, assure you, however, those buttons were not held at all. Even the ones that say “pushed” are very close to the line, (236 ms, 300 ms–the 300 one being curious because it registers 304 as a hold)…
I’m the one using these, and there’s just absolutely no holding going on. --Especially as I’ve been aware that it could be causing the issue. I find it dubious that I’m anywhere close to 300 ms, and if I am, that should definitely not be considered a hold. I’m lightly clicking.

Just throwing it out there for reference, in case anyone is inspired to adjust anything based on my findings.

As for the Hubitat stuff: thanks for the suggestion. I find that, in pretty much every custom DTH thread on SmartThings Community, you have people who announce that they’re done with ST, and they’ve moved to Hubitat, or HomeAssistant, or OpenHab, and all their troubles are gone. I have to say, I’m doubtful that any one solution is perfect, and there are tradeoffs everywhere. ST has its hooks pretty deep in me, with my pool controller, Nest, all my Google Home/Chromecast/GoogleCast devices interfaced, my Lutron setup, ActionTiles running on multiple mounted tablets and touch switches in the house…not to mention the ever-growing tweaking and customizing I’m doing with WebCoRe. And I’m very happy with the reliability. I’m sure there are some ways to replicate some of what I have going here on another platform, but I’m very happy with it so far, and starting over and rethinking every one of these would take the fun out of this for me.
Honestly the only current headache I’ve had with ST is the LutronPi instability, and that only matters if I want to use Picos to control non-Lutron stuff. The official Lutron integration worked perfectly (and I do have plenty of official/hard-linked Lutron stuff to work with). At the moment, the entire Bridge Pro/Pico/LutronPi setup is only running 2 pico remotes. In the grand scheme of everything I have going on in my smart home, it’s pretty minor. Would be just as easy to replace those picos with $20 Android phones from WalMart running ActionTiles full-time.

But don’t think I’m not keeping an ear to the ground on the Hubitat/OpenHab stuff. As for local control: that’s one reason I got the Lutron stuff to begin with. The Picos that are linked to switches and dimmers don’t rely on network/cloud interaction. They just do their job first, instantly, and that gets reported up to the cloud after the fact. It all works without internet connection, and it’s perfectly instant. I’ve been through several phases with lighting and learned the value of instant-on-off and interactive dimming that isn’t reliant on the cloud, an app, a server, etc. That’s where Caseta shines. The use of the picos to run non-Lutron stuff is just a bonus. It would cost me quite a bit less than the price of a Hubitat hub to replace the 2 non-Lutron devices I’m controlling with picos at the moment with their Lutron equivalents (and I’d still have the devices I replaced to use elsewhere, or could sell them).

Anyway. Glad I could share, hope it helped, thanks for the reco, just sharing my perspective on it at this time.

Any chance someone has packaged this with Docker? Could someone point me to a usable docker container? Thanks!

I’m running it on docker on a QNAP NAS.

I don’t think the NAS aspect should matter, a docker is a docker, I think.
I can export mine later, but I have to cook dinner and stuff this evening.