Closed scolby33 closed 1 year ago
Just did a bit of searching around and seems like a headache trying to workout what device supports what in regards to that vendor. Seems to be multiple of the same things also this post demonstrates that the action_group could be different for some reason but I'm not sure if it's referring to the same device or one similar from the same vendor...
I also noticed you didn't check the ensure legacy off checkbox. Can you please confirm legacy is off and all works with those actons.
If action_groups are the same for ZB-5004 then they both could be titled for this blueprint as they're essentially the same... Just after writing that line and looking at the title, are you sure it's ZB-5100 and not ZB-5001? Probably also why I struggled to google the device initially.
Edit: After looking at the files I can gather that the title was meant to be ZB-5001 lol
Ah, sorry about the mistyped name. I've updated the title and the commit message, but I'm not gonna try to mess with the branch name.
I think if the action groups are all different between devices (I recall reading similar threads when I was originally trying to get this to work with HA), then it's probably not a good fit for the Switch Manager at this time, since there's no good way to configure what the action group numbers are. I only have one of these remotes, so I can't verify whether that is the case.
I didn't understand the meaning of the ensure legacy off checkbox, but I have verified now. Zigbee2MQTT doesn't actually expose such a setting for this device:
Just checked on my installation. After seeing my tap dial it doesn't have it either but older remotes do. I assume (also logically makes sense) that newer devices never had a legacy format so it doesn't apply... I will need to update this in the doc's everywhere.
So with this, it's either merge and see whether another user faces a problem, or leave it in limbo until someone with more knowledge and experience with these devices can assert a blueprint. Or inform users to set a variable of some sort to use in the conditions (I really don't want to resort to this method but does make the blueprint accessable for a variety of scenarios).
For unrelated reasons, I had to factory reset my ZB-5001 today, and this resulted in new action group ID's for all of the buttons (still sequential, but with a different first value). I think adding a variable could work, or I'm happy to keep this as just a custom blueprint for myself if you'd rather not add blueprints requiring more configuration to the main repo.
Thanks for the insight. I'll close this for now which I'll reopen if there's some better option down the track. Will see how this integration develops over time before resorting to the variables method.
This remote is a bit weird, I'm not sure if the
action_group
numbers are the same for all instances of it. Also, I did my best with handling the oddness of the hold actions: holding the on button and off buttons send different actions, but they both have the same action on release. I hope my description of what the top two buttons do makes sense as well.Blueprint Checklist
Zigbee2MQTT