Lutron integration interpreting Pico Presses as Releases & also missing presses

🧰 Built-In Apps and Drivers Built-in Apps
1

Last night started having problems w/turning on Hue bulbs w/Picos.

Just two Hue bulbs in particular, two other Hue bulbs (same model) in different rooms are working fine w/Picos that control them.

Looking at logs it appears that the Lutron hub or the Lutron integration is intermittently interpreting Pico button presses as releases. Examples below - all "Releases" shown in the logs below were normal "quick" button presses I was doing while testing, but they are being identified as releases. Below logs are from one Pico, but this is happening across multiple Picos, old and new, w/new batteries.

25-01-01-1773
25-01-01-1773873×70 13.9 KB

25-01-01-1774
25-01-01-1774861×69 14.5 KB

25-01-01-1775
25-01-01-1775842×68 14.4 KB

While testing w/live logs open today I've also seen presses on the Pico not being registered in the logs at all - in some cases nothing appeared when I pressed a button on the Pico, verified it registered the press w/the flashing LED.

The Picos and bulbs have been working together happily for over a year and a half now until this started last night.

I did power cycle the Hue and Lutron hubs (pulled power as I couldn't find any other way to do so) and also shut down/pulled power/restarted w/the HE hub.

Appreciate any suggestions.

2

Are you seeing the debug events for the button presses if you have debug logging enabled in the telnet device for the integration?

3

Thanks for the reply...it's been so long since I've ever had to even think about the Lutron integration that I had totally forgotten about the the Telnet device...

Things have gotten worse overall...having failures around the house, w/numerous different Picos so not a simple battery issue, unfortunately. Was hoping it would be that...

One example - below are logs from three different Picos, each w/a button press six times. In spite of all that button press activity, this all the logging I got w/Telnet, Pico, and device controlled (Hue bulbs) logging enabled. Dev361 is the Lutron Telnet device.

image
image894×491 88.7 KB

The logs include more of the false "Released" logging for button presses (I had modified my button rule to act on "released" events to try to make things stumble along while I'm figuring out what's gone wrong, so that's why those Released events are processed),

Note that the logs for this session completely lack any button press events from two of the Picos I did six button presses on - below is the Picos that I had filtered for in the logs, but they show zero events in the logs...so I got a lot of the "skipping" that I noted in my OP, button press events are disappearing somehow.

image

Another set of logs from an earlier session pressing buttons six times on several Picos, similar loss/unlogged button events, and Press events registered incorrectly as Release events.

image
image861×491 87.8 KB

So summary:

  • Started two nights ago
  • Is affecting Picos throughout my home
  • Some button press events get completely dropped
  • Some button press events get registered/logged incorrectly as "Release" events
  • Pico battery levels not an issue - replaced batteries in devices, and affects Picos around the house

Thinking I should roll back to .144 just to rule out a platform version issue, but will wait for your comments. I updated to .145 on 12/31, coincidentally these issues started that evening.

Anything else you want me to test/get logs for, etc.?

1 Like
4

Some of my logging settings had "expired" in the tests above...refreshed debug logging setttings and re-ran the test of six presses on each of the three picos. Logs from that below:

Three picos, each had six button presses that are tied in Button Controller to toggle Hue bulbs - Pico Green Lamp (was Backyard lights) controls the Green Lamp bulb, Pico Master Bedroom Dana2, and Pico Master Dana control Dana Bed Lamp.

image

Logs: Actions were: Green Lamp pico - six button presses, followed by Pico Master Bedroom Dana2, and Pico Master Dana, also six presses each.

Green lamp did not turn on or off at all through all six presses, no reaction.
Dana Bed Lamp: Was already on - turned off on at sixth press of Master Bedroom Dana 2, and turned on at sixth press of Pico Master Dana. Other than that, no reaction to any of the presses.

25-01-02-1789
25-01-02-17891538×579 125 KB

25-01-02-1790
25-01-02-17901527×770 163 KB

5

I was trying to do this one step at a time:
Are all the button debug logs in the telnet integration for the picos (press/release only will show) logging?, lets start there.
This one is a yes or no.
So until we rule out anything to do with the Lutron integration we're just making this harder to trace

6

Just to make sure I understand your question...you're asking if all the button presses I've initiated on the Picos are appearing in the Telnet device debug logs.

If that's the question, the answer is no - the Telnet integration does not appear to be registering all of the button actions. In the logs below I completed 18 button presses spread across three Picos (6 presses each). I only see (if I read/understand below logs correctly) four "info" lines logging button actions from the Lutron Telnet device logging:

25-01-02-1792

7

I recently had an issue with PICO's being shown in Hubitat's logs but they weren't actually doing anything on hubitat itself. It was quite strange. Finally did a power cycle on the Lutron hub and haven't had a problem since.

8

Yeah I was kind of hoping I'd be able to see if button presses are logged at all on the Lutron app, but I don't see anything in there that logs when a button press has occured on a Pico connected via the Lutron integration.

9

Do you see light switch info on the hubitat logs (use live logs). Did you power cycle the lutron hub?

10

Thanks.

Yes - power cycled the Lutron hub, the Hue bridge, and shut down dance w/my C8-Pro.

Not sure what you mean by "light switch info." Logs posted above in a couple of my messages...the Picos control Hue bulbs.

11

I didn't know if you had any lutron switches or dimmers besides the picos

12

Ah, I get it. Yes, you're right, I only have Picos, no other Lutron devices. I use the Picos across my entire house to control Hue bulbs and fans.

1 Like
13

If you roll back to an earlier version of the platform does the problem go away?

14

Was going to do that, but was waiting to see if Mike had any suggestions before I rolled back. If I don't hear back from him in the next couple of hours, will probably try that...my wife makes most use of Picos/light control at night, and I'd like to avoid another night of "Why doesn't this work!?" WAF is losing ground...

Doesn't seem like it should be affected by platform version

15

FWIW I tried rolling back to .144 where I had no issues (or on any previous platform version), and that didn't help at all...Picos are still completely unreliable to control bulbs.

Other buttons (Jasco switches configured via driver to have buttons) work 100%, as does another button (Aqara) both of which are configured to control the same Hue bulbs. Controlling devices via Hue app also works reliably.

So does not appear to be a Hue issue...something up w/Picos and/or the Lutron hub. Time to get a new Lutron hub? Really hope not... :frowning:

16

Before even thinking of getting a new lutron hub (never saw one go bad) remove the pico from lutron hub, factory reset the pico and re add it (or one of them) to see how that behaves...

1 Like
17

Did you try moving the pico in question closer to the bridge to see if it’s a range issue?, also maybe a new battery in that pico?
If you’re not seeing each and every button press register in telnet logging then Hubitat isnr going to be able to respond.
Is it just this one pico?, or are others being flakey as well…

18

Another possibility is that your home network is having issues, like a continuous broadcast storm that is overwhelming parts of the network, or specific devices like the Lutron Hub. Just a hypothesis. :thinking:

I had some strange (non-Hubitat related) issues a while back that I tracked down to a very chatty Silicondust HD HomeRun TV tuner. It was blasting out mDNS broadcast packets. Once I unplugged it, everything went back to normal.

1 Like
19

@danabw - this.

I've seen weird things happen when a Pico battery is low.

2 Likes
20

Thanks for the reply, Mike.

This morning I've played around w/standing closer to the hub while using the Picos in the bedroom, and do find much more consistent results when doing that. So there does seem to be a range issue involved.

However, I can also get repeated failures from other Picos in the family room that are closer to the Lutron hub than where I am when I moved the bedroom Picos to to test the range idea.

The issues are frustratingly variable...I'll find I'm able to control two lamps (total of three bulbs) in the family room almost w/out issue for several on/offs (not rushing the button presses), and then things will start to go south and the lights don't respond reliably.

Two of the four in the bedroom have new batteries, another is a new Pico (meaning hadn't connected/used it previously) that I added to help test/troubleshoot. All of them are showing the same problems, so issues seem to be regardless of old or new batteries/Picos.

Yup, get that, and just can't think of why this problem would have started.

Multiple Picos are flaky - four in the bedroom, two in the family room at the other side of the house (and closest to the Lutron hub).

My wife just reminded me of something...about two weeks ago I moved one of my APs (Unifi NanoHD) into the office, which is where the Lutron Hub is. The Nano and my other AP, U6-LR, are set as below, and have been on the same 2.4 GHz Wi-Fi channels for several years. Nano is first line below, U6-LR second line.

image

My understanding was that Lutron's Clear Connect and Wi-Fi don't interfere w/each other, but could the relocation of the AP be an issue? I moved it two weeks ago and didn't have any Pico issues until three days ago, so doesn't seem like the AP move is related, but :man_shrugging:. I did move the AP back to its original position in another room but the problems persist...