Verisure lockdevice saved standard code not working

[hubbe74]

The problem

n Verisure lock device you can save a standard code, but when toggle lock you’re prompted to enter code anyway.

What version of Home Assistant Core has the issue?

023.10.0b9

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Verisure

Link to integration documentation on our website

https://www.home-assistant.io/integrations/verisure/

Diagnostics information

I

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[home-assistant[bot]]

Hey there @frenck, mind taking a look at this issue as it has been labeled with an integration (verisure) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `verisure` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign verisure` Removes the current integration label and assignees on the issue, add the integration domain after the command.

_{^{(message by CodeOwnersMention)}}

---

verisure documentation verisure source _{^{(message by IssueLinks)}}

[oyvindwe]

I can reproduce in version 2023.9.3

I think this is an issue with the lock entity in the frontend, that will always ask for a code even if a default code is configured.

[Joniss77]

I can reproduce in version 2023.9.3

I think this is an issue with the lock entity in the frontend, that will always ask for a code even if a default code is configured.

Same in version 2023.11.0

[oyvindwe]

Related issue: when locking/unlocking from a dashboard, I am not prompted for a code, but the configured default code is not passed in, resulting in this error:

 ValueError: Code '' for locking lock.inngang_nede doesn't match pattern ^\d{6}$

This seems to be a generic problem with the lock component, not specific to Verisure.

I'll continue investigating, I might be able fix this.

[jsundgot]

Still reproducible in 2023.11.1, has been like this since a 2023.9.x version - not entirely sure which one. Default code worked previously without interaction, new behaviour consistently prompts for code through all subsequent versions. Default code has remained configured in my configuration running HAOS.

Lock/unlock actions over HomeKit Bridge ceased at the same time, however lock status updates are received correctly over HomeKit Bridge.

Using manually (keypad) verified 6-digit PIN code. Have attempted to remove Default code from entity, revert to 4-pin and back to 6-pin. Various reboots attempted. No success. Suspected the error might be attributed to general lock entity behaviour as theorised above, and as such refrained from more drastic measures.

Unlike described above, I have been and am consistently presented with code prompt from dashboard lock entity interaction. Correct code input to prompt has always been successful.

Appreciate your efforts, @oyvindwe. My coding skills are close to nonexistent, however I'd be happy to assist with logs and troubleshooting to the extent I'm able.

[oyvindwe]

@jsundgot I might have been unclear - when I click the "LOCK" link to the right, I am not prompted for a code, and the lock is not locked. If I click the lock icon to the left, the entity view pops up, and locking here prompts me to enter the code (even if I have configured a default code):

Clicking "LOCK" issues a service call right away, this is the same as done by the HomeKit bridge.

Debugging, I see that the default code configured on the lock is not propagated to the service call from the lock component, the lock implementation in each integration has to retrieve it. This is currently only implemented in the matter integration.

I'll submit a PR for verisure that fixes this similar to the matter implementation, but I wonder if it should be a more generic fix.

The lock entity view also seems very immature. It does not work without entering a code (default code not honoured), and the slider changes position (but not colour) before submitting a code, and does not change back if you click "Cancel". I guess this is a separate issue.

[jsundgot]

@oyvindwe Appreciate the elaboration. My Lovelace card differs from yours; I use the Entity card, and it appears as such:

I don't have the 'Lock' textual option, rather the lock icon opens the entity view, which behaves identical to your description re: requiring a code, not honouring the default code, and not reverting to its initial position upon pressing "Cancel".

Implementing a fix for verisure will be much appreciated, however I agree with you that the default behaviour of the lock component (if my understanding serves me) should be to honour a default code where one exists, as there is no incentive for users to configure one if not required.

As a side note to this, some users might be stymied if they later change the default code utilised in HA on the physical lock itself, errors ensue, and they don't remember having configured the default code in the Settings dialogue (where not all users might think to look).

To avoid this becoming an issue, it might be an idea to ensure that an error prompt caused by an incorrect default code would communicate this very clearly, and perhaps even guide the user towards the Settings dialogue either by informing them textually, or linking directly to it if possible.

[oyvindwe]

@jsundgot good idea about handling wrong code. i think that is definitely out of scope for this issue, and more like a feature request.

While on the topic of out-of-scope issues, I am not happy about the lock config view displaying the default code either. Preferably it should not be returned in clear text from the backend.