FutureTense
[Feature Request] BE469 configuration options
ptdalen added some YAML to modify the options on the BE469. I’d like to add this to keymaster. But the question I have is will this work for other locks?
@firstof9 Look at the YAML in this and this. You have a Kwikset so you should be able to verify this works for you.
I’d prefer to have one universal config screen, but we night have to create multiples on a lock by lock basis. Have the user select the lock model in setup, then build the YAML for the automations and UI. For now it’s probably easiest to just create a new view for the UI. After it’s working, we can try something sexier, like a pop up.
Thoughts?
Absolutely will vary from lock to lock. I got my configration options from the xml files for the locks with the original zwave , but for any lock I'd expect the options to be found in the same place. Here is the gui for zwave-js
In this case the important take away is the "number" [143-112-0-3] Beeper 143 is the node, 112 is the command class, not needed to set configuration options, not sure about the 0, but 3 is the Parameter needed for the set configuration with HA zwave-js set config service.
For my lock the item that get's sent is the full text, zwave converts that to what is needed to make the actual change
Like this
Which I used input_select: lock_zwave_option_3_front: name: Enable or disable the beeper. options: - Enable Beeper - Disable Beeper
and - service: zwave_js.set_config_parameter entity_id: lock.front_door data_template: parameter: >- {% if trigger.entity_id == 'input_select.lock_zwave_option_3_front' %} 3 value: >- {{ trigger.to_state.state }}
in order to support this (and I'd only want to add support for this in zwave_js, trying to add it for every integration will be a frustrating experience), we'd have to dynamically generate the YAML during generate_package service calls. It's possible. Probably something we'd want to control through a configuration option too (have some checkbox that, if true, generates the file)
We can iterate through the config parameters from the node so it shouldn't matter what the device type is
Oh I see what you're planning. Definitely will need to be a toggle, I'll be having it off for sure, nothing useful in my config to adjust from HA.
Just pure curiosity since I dont have any yale locks. You dont have any config options, or they are different?
My Kwikset lock has none of those options.
What options does your lock have, if any? Creating a template for every lock shouldn’t be difficult. People with new locks can add them as a PR
My Kwikset lock has none of those options.
What options does your lock have, if any? Creating a template for every lock shouldn’t be difficult. People with new locks can add them as a PR
My point is we shouldn’t have to pre-make these templates. We can create a dashboard on the fly.
We can iterate through all the configuration options for the lock, similar to how we do for the code slots sensors, and generate them into the yaml/lovelace templates.
Right, so we'd end up with two extra files, one more yaml file which creates all the input helpers and automations for the config options, and one additional lovelace file that would have the UI config
Exactly, a couple of new files generated, and you have to add 2 views. (Man I wish I could do that programmatically). How difficult would it be to generate these, regardless of the lock type? Suppose we implemented that. We could always add a custom screen for a specific lock. So if someone has a Schlage469, they would check that somewhere in settings. During generation it would use the custom fancy screen. But if they picked the Kwikset, it would use the auto-gen screens — until someone creates one and adds it to the project.
Why do you want to maintain static files per lock? Why not generate it programmatically for every lock type? That to me seems safest because different firmwares may have different parameters. Plus it’s just a ton of extra work and files to maintain those files for what feels like little to no value
Just wanted to add, No idea how much work this may or many not be. If it's a lot of work, it might just be a better "blue print" project. I mean the actual Yaml, is super straight forward, but to have to have yaml for many locks and firmware, etc might be a lot. Like you pointed out with the Yale lock it really adds no value. I dont know much about locks other than the schlage be469 and 599. I do like the ability to change these settings, but maybe Schlage is really the only ones with a lot of options?
If this does get some traction and continue, I think you could determin the lock type without even asking. It's in the device info
