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):

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):

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.

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 - 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....

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%.

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?