Thanks for being willing to help out with this @potent glacier !
I'm on Pacific Time and need to run into work in 5 minutes, but when I get home I'll drop in this thread some of the info my model is giving me
and I can check anything in the Z2M logs, etc. to help figure out the necessary tweaks to make the blueprint work - and hopefully (if you want) you can update your public blueprint for everyone
#Z2M Lutron Dimmer Blueprint Troubleshooting
1 messages · Page 1 of 1 (latest)
most important would be: what payload are you getting in mqtt when you manipulate the knob?
also are you using legacy: false for your knob?
I have found that not setting that seems to cause issues with the blueprint
also, it's recommended to be set that way in the docs: https://www.zigbee2mqtt.io/devices/Z3-1BRL.html#lutron-z3-1brl
Looking at your blueprint, do you actually get meaningful data from the 'action' field?
I never get anything other than 'brightness' or '' from mine.
Wait, nevermind, just didn't read it through.
I think it gives different information if you are using legacy, but for me a brightness_move_to_level is basically the only thing it gives iirc
and then action_level tells what brightness it should be set to
if action_group == 6874, then that's a button press, and then action_level will be either 0 or 255
off or on
I don't have the action_group from mine. You're using Z2M, right?
Have you ever managed to get them to report faster while rotating the dial?
I only get a report every two seconds or so while rotating the dial on mine
It can easily go from 2->255 in one report, makes dimming jerky.
Hmm, some of my dimmers have action_group, some don't.
The one I did my testing on didn't.
have you got any/all of them using legacy: false?
are they running the same firmware on the knobs?
mine report fast enough that I don't really notice 🤷
idk the exact timing but unless we haven't messed with them in awhile (few hours or more) they tend to be fine
they are a bit "sleepy", but also the battery lasts a long time... so that's a plus? lol
I've had mine for... almost two years? and haven't had to replace the battery in either one that I can remember
It actually seems to be that they randomly do and don't report action_group.
Yea, I have legacy false.
Long day
Ok, yes - using legacy false option for the device
Let me see what payload info I get
MQTT publish: topic 'zigbee2mqtt/Bathroom Dimmer', payload '{"action":"brightness","brightness":2,"linkquality":14,"update":{"state":"idle"},"update_available":false}'
MQTT publish: topic 'zigbee2mqtt/Bathroom Dimmer', payload '{"action":"brightness","brightness":255,"linkquality":14,"update":{"state":"idle"},"update_available":false}'
MQTT publish: topic 'zigbee2mqtt/Bathroom Dimmer/action', payload 'brightness'
Received Zigbee message from 'Bathroom Dimmer', type 'read', cluster 'genOnOff', data '["onOff"]' from endpoint 1 with groupID null
No converter available for 'Z3-1BRL' with cluster 'genOnOff' and type 'read' and data '["onOff"]'
Received Zigbee message from 'Bathroom Dimmer', type 'commandMoveToLevelWithOnOff', cluster 'genLevelCtrl', data '{"level":95,"transtime":2}' from endpoint 1 with groupID null
MQTT publish: topic 'zigbee2mqtt/Bathroom Dimmer', payload '{"action":"brightness","brightness":95,"linkquality":14,"update":{"state":"idle"},"update_available":false}'
Is this helpful?
@potent glacier Is this helpful? also just pinging because this thread will archive after 24hrs idle
i looked at it briefly but have been busy and not super able to troubleshoot
let me see what mine looks like just to check
so an inactive one looks like:
{
"action": "",
"brightness": null,
"linkquality": 81,
"update": {
"state": "idle"
},
"update_available": false
}
a spin looks like:
{
"action": "brightness_move_to_level",
"action_level": 241,
"action_transition_time": 0.02,
"brightness": null,
"linkquality": 81,
"update": {
"state": "idle"
},
"update_available": false
}
and a press looks like:
{
"action": "brightness_move_to_level",
"action_group": 6874,
"action_level": 255,
"action_transition_time": 0.07,
"brightness": null,
"linkquality": 81,
"update": {
"state": "idle"
},
"update_available": false
}
so idk that this helps much, but that's what my payloads look like
@cloud comet if you don't have it, I'd grab MQTTExplorer and see how your payloads look there, just to get a closer look
also it's indispensable for pretty much any situation dealing with mqtt
@potent glacier wow I forgot all about MQTTExplorer - I'm such a noob
Ok, here's idle:
"action": "",
"brightness": 2,
"linkquality": 58,
"update": {
"state": "idle"
},
"update_available": false
}```
Spin:
"action": "brightness",
"brightness": 66,
"linkquality": 59,
"update": {
"state": "idle"
},
"update_available": false
}```
Press:
"action": "brightness",
"brightness": 0,
"linkquality": 59,
"update": {
"state": "idle"
},
"update_available": false
}```
Ok so I compared our payloads and got something working after making a couple edits to your original blueprint
Starting around line 25:
attrs: '{{ trigger.to_state.attributes }}'
action: '{{ attrs["action"] }}'
brightness: '{{ attrs["brightness"] }}'
transition_time: '{{ attrs["action_transition_time"] }}'
trigger:
- platform: state
entity_id: !input 'aurora'
to: brightness
condition:
- condition: template
value_template: '{{ action == ''brightness'' }}'
action:
- choose:
- conditions:
- condition: template
value_template: '{{ brightness in [0, 255] }}'
sequence:
- service: light.toggle
data:
transition: '{{ transition_time }}'
target: !input 'light'
default:
- service: light.turn_on
target: !input 'light'
data:
transition: '{{ transition_time }}'
brightness: '{{ brightness }}'```
Right now spinning the dial - dimming is sensitive, a bit jerky, and if I exceed 255 brightness it turns off; goes to 0
Progress!
Ignore this message - just sending to keep from archiving. I have a feeling I might be a little busy today and don't want to lose progress on this
You can unarchive a thread by responding to it again. Bascially all archiving does is drop it off of the list of threads under the channel on the channel list.
@cloud comet I bet I can work out how to support both structures in my blueprint
might not get to it for a few days though, pretty busy myself lately
On mine the action_group for click is 11721
And I don't seem to get an action_group when it's just brightness/turned
entity_id: sensor.livingroom_dimmer_action
state: ''
attributes:
action: brightness_move_to_level
action_level: 124
action_transition_time: 0.02
brightness: 2
device:
applicationVersion: 1
dateCode: '20181019'
friendlyName: Livingroom Dimmer
hardwareVersion: 1
ieeeAddr: '0xffff000fe7fc35c5'
manufacturerID: 4420
manufacturerName: Lutron
model: Z3-1BRL
networkAddress: 36221
powerSource: Battery
softwareBuildID: '3.8'
stackVersion: 1
type: EndDevice
zclVersion: 3
elapsed: 1189
linkquality: 255
update:
state: idle
update_available: false
icon: mdi:gesture-double-tap
friendly_name: Livingroom Dimmer action
last_changed: '2022-04-14T18:25:04.075165+00:00'
last_updated: '2022-04-14T18:25:05.261521+00:00'
context:
id: 5282274c4834a6f44719a7b191ae20cd
parent_id: null
user_id: null
for: null
attribute: action
description: state of sensor.livingroom_dimmer_action```
This is what I get for a click
entity_id: sensor.livingroom_dimmer_action
state: ''
attributes:
action: brightness_move_to_level
action_group: 11721
action_level: 255
action_transition_time: 0.07
brightness: 2
device:
applicationVersion: 1
dateCode: '20181019'
friendlyName: Livingroom Dimmer
hardwareVersion: 1
ieeeAddr: '0xffff000fe7fc35c5'
manufacturerID: 4420
manufacturerName: Lutron
model: Z3-1BRL
networkAddress: 36221
powerSource: Battery
softwareBuildID: '3.8'
stackVersion: 1
type: EndDevice
zclVersion: 3
elapsed: 48325
linkquality: 119
update:
state: idle
update_available: false
icon: mdi:gesture-double-tap
friendly_name: Livingroom Dimmer action
last_changed: '2022-04-14T18:25:14.875497+00:00'
last_updated: '2022-04-14T18:26:03.186800+00:00'
context:
id: 03ccc02882353661ae0584617b04e2be
parent_id: null
user_id: null
for: null
attribute: action
description: state of sensor.livingroom_dimmer_action```
interesting
it's really odd to me that the same device on the same firmware gives such different payloads in z2m
I am also on firmware 20181019 on both of mine
my z2m version is "1.21.2 commit: 4492212", standalone docker
with a zzh stick
seems the last edit for that device wouldve been in april 2021: https://github.com/Koenkk/zigbee-herdsman-converters/blame/master/devices/lutron.js
i picked mine up in sept 2020, but theyve been working mostly the same ever since
the only other person i know thats used them much is @acoustic lava
hope he doesn't mind the ping 😬
Mine are bound to devices
ahh ok
I can't remember why I initially opted to not bind them directly tbh
I got wifi bulbs for my color bulbs so I need mine to go through HA.
I moved over to ZHA since my thermostat isn't properly supported by Z2M. When listening for the ZHA event trigger.event.data.args[0] is the brightness and trigger.event.data.args[1] is the action. 7 is a button press, 2 is a brightness change. Sometimes turning it off shows up as a brightness change and not a button press so I consider it a button press if brightness is 0 or the action is 7.
description: ''
trigger:
- platform: event
event_type: zha_event
event_data:
device_ieee: ff:ff:00:0f:e7:fc:35:c3
condition:
- condition: template
value_template: '{{ trigger.event.data.args[0] == 0 or trigger.event.data.args[1] == 7 }}'
action:
- service: light.toggle
data: {}
target:
entity_id: light.kitchen_and_dining_room_all_lights
mode: single
description: ''
trigger:
- platform: event
event_type: zha_event
event_data:
device_ieee: ff:ff:00:0f:e7:fc:35:c3
condition:
- condition: template
value_template: '{{ trigger.event.data.args[0] != 0 and trigger.event.data.args[1] == 2 }}'
action:
- data_template:
brightness_pct: >-
{% if trigger.event.data.args[0] >
(states("var.kitchen_dimmer_last_action_level") | int) or
trigger.event.data.args[0] == 255 %}
{% if (((state_attr("light.kitchen_and_dining_room_all_lights","brightness") | float )/255*100) + 1) * 1.4 > 100 %}
{{ 100 }}
{% else %}
{{ ((((state_attr("light.kitchen_and_dining_room_all_lights","brightness") | float )/255*100) + 1) * 1.4) | int}}
{% endif %}
{% else %}
{% if (((state_attr("light.kitchen_and_dining_room_all_lights","brightness") | float )/255*100) - 1) * 0.6 < 0 %}
{{ 0 }}
{% else %}
{{ ((((state_attr("light.kitchen_and_dining_room_all_lights","brightness") | float )/255*100) - 1) * 0.6) | int}}
{% endif %}
{% endif %}
transition: 0.2
entity_id: light.kitchen_and_dining_room_all_lights
service: light.turn_on
- service: var.set
data:
entity_id: var.kitchen_dimmer_last_action_level
value_template: '{{ trigger.event.data.args[0] }}'
mode: parallel
max: 500
For my setup -
Button firmware: 20181019
Z2M Current version: 1.18.1-1 (1.18.1 commit: 1.18.1)
And I'm using a deCONZ/ConBee II
I couldn't unbind no matter what I tried, so I ordered a new button and this time I'm keeping it strictly to Z2M to mitigate that issue going forward
with tubes endorsement I'm thinking of attempting direct bind on mine lol
lol nooooooooooooooo
It was easy to bind them, and I was able to do a group by binding each individually
I'm using a Conbee for mine too.
I seem to get better results with the Lutron dimmers with ZHA than I did with Z2M.
I don't sometimes have missing fields
I don't need to do a group with them (unless I'm misunderstanding), because I have each one controlling a single bulb each. they're for the main lights in each bedroom
ZigBee bulbs of course
this thread screams conbee issue
i looked in because I have 3 of these devices w/ no issues - though when I automated via ha I didn't like the dimming lag. So I used the controller software to direct bind the bulbs
I imagine they are just integrated differently via conbee
but I agree for the most part
Meh, conbee or not it works great for me in ZHA.
I blame Z2M personally.
I had a couple device bugs that cleared up once I moved to ZHA.
Yea, doesn't sound like your setup needs that.
I have 2 zigbee bulbs in my bathroom. In HA they're grouped but can be controlled individually as well. When I was binding the device to them them using the manufacturer instructions, I was able to bind to each individually so when I used the device it worked for both as if they were a group.
It was so seamless, easy, and worked really well. But because I tested it on a bulb in my closet first (and because I couldn't unpair/unbind it) every time I used the bathroom lights it was also controlling the closet light 😂
Sounds like the best thing is to direct bind....but I'm too damn stubborn lol
@potent glacier when you get a little less busy do you think you'll still try to update your blueprint to accommodate the conbee weirdness? or could you help me figure out the transition smoothness, and the turning off if the dial goes over 255?
I am planning to check it out soon, but am still pretty wrapped up in crap atm
No worries. Any time you can split off to help, and whenever that could be, is going to be helpful to me. Let me know if you need a winter jacket, wetsuit, or some outdoor apparel and I can hook you up with a discount/coupon for your help (if you’re in US/Canada)
I have 3 on z2m no issues
did you direct bind them to any bulbs, or do you use a blueprint/automation?
I just threw together an automation and tested it fine, while its still direct bound to 6 bulbs
I don't use blueprints
@cloud comet I haven't forgotten this just so you know
@potent glacier much appreciated!!
hey @cloud comet can you try this one? https://www.toptal.com/developers/hastebin/sinijoqowa.yaml
Sorry for the delay - attended a beautiful wedding this weekend and have been sick all week.
I tried this out and it worked wonderfully. I have 2 dimmers, right now, so I'm goin to roll this out to both of them and test them out for a week or so. If you want I'll come back with some feedback around any glitches I experience if you want to wait before publishing an update
Note I'm using "action" instead of "brightness" as the entity when testing so far, but will play around with it this weekend a little bit more
Thanks again for your help. If you want that discount code/coupon for a winter jacket or gear let me know
haha I'll keep you in mind 😉
either action or brightness should work iirc, they should both have the same attributes
Been having trouble getting a second dimmer setup. Everything in MQTT Explorer and Z2M logs look correct. I can see the brightness being updated whether I toggle or I spin the dimmer. It's almost like the automation itself doesn't link the device action to the entity. This is only impacting the second dimmer and the second automation. The first dimmer and first automation work fine. 🤦♂️
To make things more interesting, the original/first dimmer now has "action_group", and a couple more, in the payload when it previously did not
those should work, hmm
maybe check in the automation trace where it's breaking down?
I'm using the updated blueprint for mine and they're still working with action_group
I duplicated the automation that is working, and modified with the new/second device and a new entity, but that isn't working either
Let me look
Ok, so it doesn't run, never executes. (Trace: Stopped because of unknown reason "null")
e: Even if I try to "run actions" from browser it won't run
But if I switch the blueprint to your original one, it's triggers or it runs/executes but it doesn't do anything. Trace: expected float for dictionary value @ data['transition']
hmm
Have you had any luck figuring out why a second automation doesn't execute? I reached out in the #blueprints-archived channel to see if it was some setting I needed to adjust, but ultimately it sounds like it comes back down to the code
I don't really have any idea tbh