Maximilian Hildebrand

I'm not sure yet how to access the new unlatch_supported attribute. I though that I can do something like ``` def __init__(self, data: AugustData, device: Lock) -> None: [...] if...

> Code looks good. Should be good to merge once tests are added Ok great. I'll Look into that tomorrow

I've added a test for the hass lock.open action. Is this sufficient or are more tests needed?

The one check is failing because `homeassistant.exceptions.HomeAssistantError: Entity lock.online_with_doorsense_name does not support this service.`. That's correct because currently only devices with the Type 17 get the Unlock Support Flag set....

Well, I just found out that I can run the tests with pytest locally... Should have read the whole Development Workflow in the docs earlier, sorry

> Wow, thank you a lot, I was already frustrated, as the L1 could open the door.. You're welcome! Currently only the L2 will be getting the open feature, because...

> If the model id is not in diagnostics, it would be nice to add it there as well It is already. One can search for `"Type":` in the debug...

@bdraco The negative test is working. A lock that does not support unlatching (according to yalexs) does not have the open feature flag set. However, the positive test (https://github.com/home-assistant/core/pull/113795/commits/5996c5445f9b00bb2857f1872a5bfa17bbdf22c1) leads...

Hello @marcelo321, that's a good point. We already have a check if the "default" status code changed, before reporting a different status code. However, this check may be flawed if...

I just checked it more thoroughly and could replicate it using https://www.cloudflare.com/rate-limit-test/. Typically it should work this way: If the poison and the benign request both result in the same...