Lutron Variables (Physical and Digital interactions) in 2.3.5.104

[JoshBI555]

So here is an interesting one..

I have a global variable set up that uses a rule which reports the last state of certain Lutron dimmers using the %text% feature. The idea is because Lutron reports the difference between a digital and physical interaction, I can parse that word to decide whether I should execute certain fades. I noticed some of that logic has gone wonky in 2.3.5

I can see in the event log for certain Lutron dimmers digital interactions are now showing up as physical, but that are set by the hub and should clearly be digital. Problem is that it is sporadic, but it only seems to apply to certain dimmers as far as I can see. A scene can be activated via a mode change, and the interaction logged as physical when it should be logged as digital. I can turn off the scene manually and then enable it again to display the correct digital interaction, but not every time.

I thought maybe I should reboot Lutron Hub and Hubitat, but no go there. I have rolled back to 2.3.4.153 to see if maybe it's been weird longer than I have known about, but I noticed it was wonky pretty quick while cooking and having the lights fade on me in the kitchen.

Any ideas would be appreciated.

[bravenel]

Due to the fact that your Lutron devices are virtual devices created within an integration, and that Lutron itself does not report "physical" or "digital", the integration is attempting to tell which is which. It has inadequate information to go on. So, you see it as wonky. There is little or no chance of this working the way you want reliably.

[JoshBI555]

HI There,

Thank you as always for you insight and response. I would only say the integration must of been doing a great job at fooling me, because in the 1+ year I have been running this, it's been pretty flawless. It's operating again with the roll back, but again, I could be perceiving it. The only other way I can think to make this work, is the same I make my thermostat overrides work. Create a sub expression that compares the expected level of the mode to the level currently set, and then decide how to handle the fade at the next mode change.

[Bullfrog]

I have been using Hubitat and Lutron Ra2 for 2+ years now and can confirm that physical vs digital has never been reported - it's all reported as physical for me whether real physical or if a Zooz motion sensor turns it on via a rule in RM. Even controlling the dimmer via the Connect App reports as physical. in this snip:
1 - RM triggered by a motion sensor
2 - Physical presses of the dimmer
3 - Lutron App

[bravenel]

All I can say is that nothing has changed with the Lutron Integration in this regard for quite some time.

[JoshBI555]

@Bullfrog

super interesting. Take a look at mine. Called by the hub via the set level command as digital, and then set locally at the actual switch in the wall logged as physical. This is how I have been automating.

[bravenel]

If it's of any help, here is how it works:

Every command made by the hub over telnet to the Lutron system is responded to by the Lutron system, basically echoing back the same command. If a Lutron switch is physically activated, the Lutron system sends an identical message over telnet to the hub. So the Luton Integration is constantly receiving these basically identical messages from Lutron.

If the Hubitat device representing a Lutron device is commanded, for example by an app, the driver sets a flag. When a response comes from the Lutron system, if the driver sees that the flag is set it generates a digital event. If the flag is not set it generates a physical event.

To further complicate matters are the Lutron phantom buttons. If an app causes a Lutron device to turn on or off by the intermediation of a Lutron phantom button, the device driver was not directly commanded to cause that. Consequently, the flag does not get set, and the response is therefore interpreted by the driver as a physical event -- even though it was a digital event caused by an app. It is not possible for the Hubitat hub to know what the programming of the phantom buttons is, so these events are inscrutable to the Lutron Integration.

As far as I know, physically interacting with a Lutron switch or dimmer in the real world will result in a physical event. In the case of an app commanding an integration device, that will generally result in a digital event -- but not in 100% of cases. Net result: physical vs digital is not a viable method to tell what actually happened to a Lutron device.

This description above has been the implementation of Lutron Integration for five years, and there is nothing about 2.3.5.xxx that would have changed this.