Added Zigbee2MQTT Lutron Aurora Dimmer (Z3-1BRL)

[The-Croz]

Blueprint Checklist

• [x] You viewed the README and conformed to the naming conventions
• [x] You ordered the actions as stated in the README action order
• [X] All filenames are lowercase and uses '-' for spaces and not '_' while using {service-name}-{switch-name-or-type}.yaml format
• [X] Images are png
• [X] Image backgrounds are transparent and is cropped to the device boundries
• [X] Images has a maximum width of 800px and maximum height of 500px
• [X] There are no missing buttons or actions
• [X] Your integration/service is running on the latest version
• [X] You have tested your blueprints and made sure each button and action works

I felt it necessary to include some info in the blueprint as these switches are a little odd compared to others. There is only one "action" the switch sends and the press and rotate are differentiated by the action_transition_time in Zigbee2MQTT. Feel free to tweak that info description as needed, but this blueprint has mine up and running great controlling lights in my home! I'm loving using this integration.

[Sian-Lee-SA]

Is your setup using legacy enabled? Just need to check because I've hard coded and trying to get users to switch legacy off. You mentioned the action topic and how it's not providing the information needed to properly handle so I assume it is off. I have had contributors head over to Zigbee2MQTT to fix up the action topic to send better more fulfilled information, I believe this one has been overlooked because sounds like everything you need should be supplied via the action topic. Also thanks for the complement. Once confirmed your blueprint is designed with legacy off then I can merge. Thanks

Edit: I also appreciate the time taken to explain this through the info. So kudos

[The-Croz]

@Sian-Lee-SA Legacy is disabled. For whatever reason, this is one of those oddball switches in Zigbee2MQTT they have never adjusted to match standard JSON payload structure and the documentation here. With legacy disabled as recommended, a standard JSON payload looks like this:

{
    "action": "brightness_move_to_level",
    "action_group": 1,
    "action_level": 255,
    "action_transition_time": 0.07,
    "brightness": 255,
    "linkquality": 51,
    "update": {
        "installed_version": 3080,
        "latest_version": 3080,
        "state": "idle"
    },
    "update_available": null
}

And with it enabled, it actually matches their documentation like this:

{
    "action": "brightness",
    "brightness": 255,
    "linkquality": 72,
    "update": {
        "installed_version": 3080,
        "latest_version": 3080,
        "state": "idle"
    },
    "update_available": null
}

Do you prefer to keep it as is with legacy false? Since the recommendation is that it is disabled? Or enabled since it matches the documentation?

[The-Croz]

Further investigation... with legacy enabled (which is actually the default for some reason) the only action in any payload is brightness with a value. With legacy disabled, I was able to use conditions based on different action_transition_time values so the button press and dial rotation could be distinguished. Looks like legacy disabled is the best option as is also detailed in this thread, so there should probably be a note included under "info" to make sure users disable legacy since it is on by default. Thoughts?

[Sian-Lee-SA]

Keep legacy disabled as thats pretty much what their standard is meant to be and what I'll always be telling people to do as it helps conform to a standard. These kind of things and half baked integrations from other services is the cause of most headaches and it's very unfortunate. I only see one problem with targetting the topic as you have that if there is a battery update or anything to cause another message to pass through that topic (even just a simple update on the lqi) then it will retrigger the condition if action stays as it is.

I also think older devices they keep legacy enabled because they don't want to screw with already made configurations but ultimately my next update will inform people to ensure they have legacy off when using the Zigbee2MQTT blueprints

[Sian-Lee-SA]

Just confirm there's no retriggers on a generic update on the topic because its possible they remove the action params if it's just a standard update message

[The-Croz]

Yeah I'm with you. Wish it was consistent coming from the main Zigbee2MQTT platform, but as long as its known consistently to keep legacy off when using Switch Manager it should alleviate issues with the few edge cases.

I'm only seeing the "brightness_move_to_level" action when the button is pushed or dial is rotated, so I think the condition I put in the blueprint should prevent any issues just fine. In fact, the Aurora sends two payloads with every push/rotate for some reason, one with the action data and another with no action, so the condition also "debounces" those messages and it looks like the Aurora kind of clears itself out after each action by resetting it to a blank action.

I've been listening for messages for a little while and had the blueprint up and running for a while with no issues. There's no battery exposed that will publish updates on the topic and link quality only seems to update whenever a button is pushed anyway. Sorry for the long winded explanations, just making sure I am clear on everything I can be!

[The-Croz]

Here's the non-action payload to confirm!

{
    "action": "",
    "brightness": 255,
    "linkquality": 91,
    "update": {
        "installed_version": 3080,
        "latest_version": 3080,
        "state": "idle"
    },
    "update_available": null
}

[Sian-Lee-SA]

Ok that sounds promising then, I just recall a similar issue with a PR a while ago which updates caused retriggers but doesn't seem to be the case here. I also like the informative responses so no need to be sorry for it... Thanks for the last payload. Seems good to me, if any issues down the road then can deal with it then.. Thanks again for contributing!

Edit: Also like the image you chose too

[The-Croz]

Glad to hear it! Happy to help with testing/resolving any issues that may come up for other users down the road. Just tag me. Actually sent you a small donation earlier today on Paypal for all your work on this, keep it up! Really would be nice for this to make its way into HA Core one day. Makes configuring buttons and switches so much easier.

[Sian-Lee-SA]

Ohh Thank you! You're my first Paypal donation and there wasn't a respond button or anything unlike BuyMeACoffee, only an email address but felt a bit invasive to email you to say thanks. But glad you mentioned it so I can formally thank you, it definitely gives motivation :heartpulse: