Change async_set_existing_doorbell_type_duration to send Ring int instead of bool

[briangoldstein]

I am currently working on adding code to the Home Assistant ring core component to support async_set_existing_doorbell_type and async_set_existing_doorbell_type_enabled. In working on the switch to enable/disable the in-home chime, I found that Ring is expecting a string, not a boolean value. Error below:

ring_doorbell.exceptions.RingError: Unknown error during query of url https://api.ring.com/clients_api/doorbots/: Invalid variable type: value should be str, int or float, got True of type <class 'bool'>

Ring is expecting 0 or 1 when enabling and disabling. I have tested the code change with a modified test.py with the following body between await ring.async_update_data() and await auth.async_close()

    # Fetch all available doorbells
    devices = ring.devices()
    doorbells=devices['doorbots']

    # Flip the status of the in-home chime for each doorbell
    for doorbell in list(doorbells):
        await doorbell.async_update_health_data()
        print()
        print()
        print('Address:    %s' % doorbell.address)
        print('Family:     %s' % doorbell.family)
        print('ID:         %s' % doorbell.id)
        print('Name:       %s' % doorbell.name)
        print('In-Home Chime Type: %s' % doorbell.existing_doorbell_type)
        print('In-Home Chime Status: %s' % doorbell.existing_doorbell_type_enabled)
        print()
        print()
        if doorbell.existing_doorbell_type_enabled:
            print('Turning Off In-Home Chime')
            await doorbell.async_set_existing_doorbell_type_enabled(0)
            time.sleep(5)  # Pause for 5 seconds
        else:
            print('Turning On In-Home Chime')
            await doorbell.async_set_existing_doorbell_type_enabled(1)
            time.sleep(5)  # Pause for 5 seconds
        print()
        print()
        print('In-Home Chime Type: %s' % doorbell.existing_doorbell_type)
        print('In-Home Chime Status: %s' % doorbell.existing_doorbell_type_enabled)

[gitguardian[bot]]

⚠️ GitGuardian has uncovered 2 secrets following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

Since your pull request originates from a forked repository, GitGuardian is not able to associate the secrets uncovered with secret incidents on your GitGuardian dashboard. Skipping this check run and merging your pull request will create secret incidents on your GitGuardian dashboard.

🔎 Detected hardcoded secrets in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
13592133	Triggered	Google API Key	2d5d4cc4531ae0b9e928dcfe212483a4229d2eef	ring_doorbell/const.py	View secret
13592133	Triggered	Google API Key	82088d9b35082b5d0e462dfcb9a312e66c89dcf0	ring_doorbell/const.py	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secrets safely. Learn here the best practices.
3. Revoke and rotate these secrets.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}

[coveralls]

coverage: 77.267% (-0.07%) from 77.334% when pulling 1591eb1557d052d6bcb885c693b3cfd4bc576bc2 on briangoldstein:master into da5bd8cf62420b2a16b226c227df0eb2801408a7 on tchellomello:master.

[sdb9696]

I've never actually used these methods. What do they actually do? Can you actually set a doorbell type to manual or digital. Is this something available on all devices that derive from doorbots? i.e. stickup_cams etc.

[briangoldstein]

It's only available for (most) doorbell models. It lets the Ring doorbell trigger the in-home doorbell chime.

Not present = you don't have one (or want to use it) Mechanical = the traditional ding dong physical bell Digital = the fancy digital versions of doorbell chimes

For digital, you can also set the duration, but I do not have a digital in-home chime so I can't test that aspect and will leave it out of the home assistant changes I will submit.

I used to use a homebridge automation that would turn the in-home doorbell off during the day to prevent the dogs from going nuts, but then would have it turn on at night when our phones are on do not disturb or if we had someone watching the house.

https://ring.com/support/articles/vk1ml/configuring-your-doorbell-for-an-in-home-chime

[sdb9696]

Ah ok that makes sense, very helpful thanks. So the doorbell doesn't actually know what kind of chime it's connected to? It has to be told in the app and the api?

[briangoldstein]

You're welcome! That is correct, this is what it looks like in the app when you set mechanical, digital, not present. I'll make sure to include some of this information when I submit the HA ring PR as well.

[sdb9696]

Cool. So I think it would be good to have test coverage for this, especially if it's going to be enabled in HA.

[briangoldstein]

Sounds good. I am brand new to pytest, so will read up on it this weekend, but may take some time to implement.

[briangoldstein]

@sdb9696 I've added a test for the async_set_existing_doorbell_type_enabled function. Please let me know if you had additional tests in mind, thanks!

[sdb9696]

Thanks for the PR @briangoldstein! N.B. I added some asserts and extra steps to the tests.

[sdb9696]

So that's now been released and should be bumped in HA once HA 125087 is merged. Feel free to hmu on discord (sdb9696) if you want to chat about how best to implement support for this in HA.