Conditional Trigger on Device Brightness not working

I am trying to set a trigger for when a light goes to 100% brightness, using Lutron RadioRa2 lights. The idea is that a single tap on the dimmer switch brings the light to a default brightness (typically 85%), and a double tap takes it to 100%. So my code looks for a light going to 100%, basically enabling something extra to happen when I double tap a lightswitch. In this example, I want my son's nightstand light to come on when I double tap the wall switch for his overhead light.

I've included a screenshot of the trigger conditional below.

However, when I take the light to any arbitrary brightness level, the trigger is activated, as seen in the log below (I have the trigger dump the full contents of the indigo device into the log, upon execution, for troubleshooting):

Code: Select all

   Lutron RRA2/Caséta Debug       Received an Output message: ~OUTPUT,56,1,9.00
   Trigger                         Sebastian Full Bright
   Lutron RRA2/Caséta             Received: Dimmer Sebastian - Overhead level set to 9.00
   Lutron RRA2/Caséta             Sending: "Sebastian - Nightstand Lamp" set brightness to 100 with fade 2
   Lutron RRA2/Caséta Debug       Sending network command:  #OUTPUT,83,1,100,2
   Script                          device: address : 56
batteryLevel : None
blueLevel : None
brightness : 9
buttonGroupCount : 0
configured : True
defaultBrightness : 100
description :
deviceTypeId : ra2Dimmer
displayStateId : brightnessLevel
displayStateImageSel : DimmerOn
displayStateValRaw : 9
displayStateValUi : 9
enabled : True
energyAccumBaseTime : None
energyAccumTimeDelta : None
energyAccumTotal : None
energyCurLevel : None
errorState :
folderId : 3595879
globalProps : MetaProps : (dict)
     com.jimandnoreen.indigoplugin.lutron-radiora2 : (dict)
          address : 56 (string)
          notes :  (string)
          zone : 56 (string)
greenLevel : None
id : 1482389170
lastChanged : 2016-12-06 14:53:05
lastSuccessfulComm : 2016-12-06 14:53:05
ledStates : []
model : RadioRA 2 Dimmer
name : Sebastian - Overhead
onBrightensToDefaultToggle : False
onBrightensToLast : False
onState : True
ownerProps : com.jimandnoreen.indigoplugin.lutron-radiora2 : (dict)
     address : 56 (string)
     notes :  (string)
     zone : 56 (string)
pluginId : com.jimandnoreen.indigoplugin.lutron-radiora2
pluginProps : emptyDict : (dict)
protocol : Plugin
redLevel : None
remoteDisplay : True
states : States : (dict)
     brightnessLevel : 9 (integer)
     onOffState : on (on/off bool)
subModel :
supportsAllLightsOnOff : False
supportsAllOff : False
supportsColor : False
supportsRGB : False
supportsRGBandWhiteSimultaneously : False
supportsStatusRequest : True
supportsTwoWhiteLevels : False
supportsTwoWhiteLevelsSimultaneously : False
supportsWhite : False
supportsWhiteTemperature : False
version : None
whiteLevel : None
whiteLevel2 : None
whiteTemperature : None
   Lutron RRA2/Caséta Debug       Received an Output message: ~OUTPUT,56,29,6
   Lutron RRA2/Caséta Debug       Received an Output message: ~OUTPUT,56,30,1,28.00

Any ideas what the issue is here?

[jay (support)]

Pretty sure this is a question for the RadioRA plugin developer. Indigo triggers based on what the device is saying.

I do wonder about these two lines from your log above:

Code: Select all

   Lutron RRA2/Caséta             Sending: "Sebastian - Nightstand Lamp" set brightness to 100 with fade 2

Doesn't that mean the device is getting set to brightness of 100? Also, further down:

Code: Select all

defaultBrightness : 100


Doesn't that mean the default brightness is 100?

Pretty sure this is a question for the RadioRA plugin developer. Indigo triggers based on what the device is saying.

Doh! I've done a bit of work on the plugin myself, I might have to take a look... I thought since it was a generic device trigger it would be a problem a step or two above the plugin level...

I do wonder about these two lines from your log above:

Code: Select all

   Lutron RRA2/Caséta             Sending: "Sebastian - Nightstand Lamp" set brightness to 100 with fade 2

Doesn't that mean the device is getting set to brightness of 100? Also, further down:

Jay - that is one of the trigger actions -- setting the nightstand light to 100% after the overhead light has been turned to 100%

Code: Select all

defaultBrightness : 100


Doesn't that mean the default brightness is 100?

I think that is the default brightness when the "On" button is hit in the indigo interface for the light, it should have nothing to do with what happens when the physical dimmer on the wall is touched.

Interestingly, I am able to use python code to effectively get around this issue, with code like this (from another trigger):

Code: Select all

light = indigo.devices[1438848136]
if light.brightness == 100:
   indigo.device.removeDelayedActions(light)
elif light.brightness == 0:
   indigo.device.removeDelayedActions(light)
else:
   indigo.device.removeDelayedActions(light)
   indigo.device.turnOff(light, delay=300)

This makes me think the issue is more with the internal logic of the trigger, than the plugin....

Is there anyway to get more logging or debugging of what's going on behind the scenes with the trigger execution?

Just to clarify, in the log example I showed above, the light was set to brightness of 9%:

Code: Select all

Lutron RRA2/Caséta             Received: Dimmer Sebastian - Overhead level set to 9.00

and

Code: Select all

brightness : 9

[jay (support)]

This makes me think the issue is more with the internal logic of the trigger, than the plugin....

Highly unlikely - that particular code hasn't changed since Indigo 2 and if there were a bug there I'm quite confident that it would have been found by now. Device states, including on state and brightness, are controlled by the plugin or interface that owns the device. Indigo triggers will only fire when a device's state is updated and matches a trigger. This is why I'm wondering if there may be some logic internal to the plugin that's causing the brightness to get temporarily set to 100 (causing the trigger to fire) then back to what it's actually supposed to be. I don't know if that's the problem but it's a possibility.

One thing you can definitely try though: change the switch to a different device (not a RadioRA switch) if you have one that you can manually operate and see if it continues to happen. That would help identify if it's a device or Indigo trigger problem.

For now I'll use the python logic to get around the issue, but I'll also work over the plugin code to see if I can find the issue.


Sent from my iPhone using Tapatalk

[matt (support)]

I think you are seeing a side effect of some logic in the Indigo Server that occurs when a module transitions from OFF to ON. Depending on the module type and its flags, Indigo will try to set the brightness automatically in those cases to what it thinks the hardware is defaulting to so Indigo's UI mirrors the actual state. This is mainly for INSTEON modules that, when turned ON (at the switch), do not broadcast out their brightness – Indigo has to guess what brightness it likely went to (or poll out the state later).

In this case though we don't want that logic to occur. I need to open up access for plugins to some of those device flags, or find some other way to circumvent the behavior. I'll add that the API ToDo/request list.

I think you are seeing a side effect of some logic in the Indigo Server that occurs when a module transitions from OFF to ON. Depending on the module type and its flags, Indigo will try to set the brightness automatically in those cases to what it thinks the hardware is defaulting to so Indigo's UI mirrors the actual state. This is mainly for INSTEON modules that, when turned ON (at the switch), do not broadcast out their brightness – Indigo has to guess what brightness it likely went to (or poll out the state later).

In this case though we don't want that logic to occur. I need to open up access for plugins to some of those device flags, or find some other way to circumvent the behavior. I'll add that the API ToDo/request list.

That makes sense, and would explain the behavior. Probably by the time the python code gets executed the brightness state has updated to the correct value, and that's why the logic works there. In the mean time it's easy enough to test for brightness in the python code...

I'll keep an eye on the change logs for this. If there's anything else I can do to help with the process let me know.

I think you are seeing a side effect of some logic in the Indigo Server that occurs when a module transitions from OFF to ON. Depending on the module type and its flags, Indigo will try to set the brightness automatically in those cases to what it thinks the hardware is defaulting to so Indigo's UI mirrors the actual state. This is mainly for INSTEON modules that, when turned ON (at the switch), do not broadcast out their brightness – Indigo has to guess what brightness it likely went to (or poll out the state later).

In this case though we don't want that logic to occur. I need to open up access for plugins to some of those device flags, or find some other way to circumvent the behavior. I'll add that the API ToDo/request list.

Matt - just curious if this is still on the list. I continue to have this nagging issue with my conditional triggers - even with using python to check the values, sometimes if the dimmers are being adjusted continuously the code hits on the temporary 100% brightness level and I get a false trigger...

[matt (support)]

To try to debug this further try creating a Device State Changed trigger for the brightness (on any change) and have that log the current brightness:

light = indigo.devices[1438848136]
indigo.server.log("%s is now %d" % (light.name, light.brightness))

Also maybe sprinkle some debug logging in your Triggers (or other scripts) that are checking for when the brightness is 100%.

Oh, and also create 2 Triggers for when the Device State transitions to ON and to OFF and log those as well.

Maybe then when we compare the log results from normal and failure cases we can better figure out what is occurring?

Matt - I'll play around with this tonight to get some debugging info for you.

Based on what you've said, I'm pretty sure the issue is that my code catches the brightness during the brief period when the brightness is (incorrectly) reported as 100%. While the slight delay in having the brightness level check in python will usually get past the first false 100% reading, I believe what is happening is that as someone in the room manually adjusts the light brightness the python test code is activated many times, and there are several false 100% brightness in the system, and the python code just happens to randomly catch one of those 100% readings... I think the only way around this (somewhat edge case) is to have some flag in the plugin API to disable the default brightness level....

-Ray

Alright, after being silent for 1.5 years, I finally got around to looking at this again. (In the mean time, I made it work, with a 2 second persistence timer device on the brightness, but I don't like that lag).

Anyways, I set up triggers on device on, any change in brightness, and brightness becomes 100. I've attached a screenshot of the last trigger below. Then I changed the brightness of the light to 1%, and all three triggers hit, but by the time the script executed, the brightness level had corrected to 1%.

Code: Select all

Dec 7, 2018 at 12:33:48 PM
   Trigger                         Testing - Turn On
   Trigger                         Testing - Brightness Change
   Trigger                         Sebastian Full Bright Test
   Trigger                         Testing - Brightness Change
   Script                          Sebastian - Overhead  turned on, is now 1
   Script                          Sebastian - Overhead is now 1
   Script                          100 brightness triggered, Sebastian - Overhead is now 1
   Script                          Sebastian - Overhead is now 1


I also notice that the brightness change trigger is getting triggered two times, which makes sense if the device brightness is first going to 100% and then to the correct, 1% level.

Here's the plugin code that updates indigo device states when it receives a change in a light output, and I think I see the problem here. When the plugin receives a change in brightness, it first updates the state of the light to On, and then updates the brightness level. Should it just be updating the brightness level?

Code: Select all

zone = self.dimmers[id]
                if int(level) == 0:
                    zone.updateStateOnServer(ONOFF, False)
                else:
                    zone.updateStateOnServer(ONOFF, True)
                    zone.updateStateOnServer("brightnessLevel", int(level))
                self.logger.debug(u"Received: Dimmer " + zone.name + " level set to " + str(level))


Sent from my iPad using Tapatalk

[matt (support)]

Yes, setting brightness to > 0 should automatically change the on state.

Yes, setting brightness to > 0 should automatically change the on state.

Perfect, I'll let Joe know. Should be an easy fix!

Just wanted to circle back on this. Lutron RR2 plugin 7.2.3 fixes this issue.