KeyMaster Z-Wave lock manager and scheduler

Some changes are in the works to hopefully accommodate zwave and ozw in a single version.
Please stand by.

Do you have an eta on when that will be done

If you’d like to test, you can pull the files from my repo: https://github.com/firstof9/lock-manager/tree/ozw-version/custom_components/lock-manager

Here is error I get when I hit check config

                        Error loading /config/configuration.yaml: while parsing a block collection
  in "/config/packages/lock-manager/patiodoor/patiodoor_lock_manager_common.yaml", line 369, column 7
expected <block end>, but found '?'
  in "/config/packages/lock-manager/patiodoor/patiodoor_lock_manager_common.yaml", line 388, column 7

Are you running HA 0.115 ?

yes I am 0.115.4

I am running your code from your github

Keep in mind I haven’t tested these, but I did just push a new lock_manager_common.yaml if you’d like to try.

How do you create a dummy sensor? What’s the minimum that you need for a dummy sensor?

It’d be a template sensor.

https://www.home-assistant.io/integrations/binary_sensor.template/

that fixed my error but I can’t get codes to set, I am checking z-wave config panel and under node user codes code 1 nothing

That’s not how you check, you have to physically test them with the old integration.
OR
Press Save Config
and check inside the zwcfg_xxxxxx.xml

I sorry I don’t understand what you mean by old integration or press Save Config and check inside the zwcfg_xxxxxxxx.xml

Go to your lock, enter the code see if your lock unlocks.

The codes are not changing in zwcfg_xxxxxxxxx.xml

<Value type="raw" genre="user" instance="1" index="1" label="Code 1:" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="0x00" length="1" />

Just a fyi, I tried setting up lock-manager with code slots 6-10. Lovelace file is created correct but lines 373 and 395 in ***_lock_manager_common.yaml reflected slots 1 through 6 – not 6 through 10. Also, when I do lock_manager.generate_package it will do binary_sensors 1 through 6 even if I tell to do 1 to 10. Seems like the generate_package honors the FrontDoor.ini downloaded with the code updates?

One other thing, configuration option requires a sensor. But if, as me, there isn’t one? I resorted to create a dummy binary sensor instead. Could this have adverse effects?

Remove everything and install via HACS

1 Like

Posted another issue in the tracker recently regarding some more hard-coded entities. Hard-coded door sensor entity is still persistent in the newest 0.0.18-ozw version as well.

A PR has been submitted to resolve the hard-coded entities.

Nope, only if you are looking to use the open/close counter.

The ini file is no longer used and likely to be deleted from the repo shortly. There’s a PR submitted to resolve the hard-coded entities.

1 Like