v0.7.1

Small enhancement so that updates to the statuses list will immediately be reflected in the state of the binary sensor

v0.7.0 - Statuses that turn binary sensor on are now configurable!

Per user feedback, I have reverted the change in v0.6.2 to include In_Calendar_Event as a status that turns the binary sensor on by default. The defaults are once again:

• In_Meeting
• Presenting
• On_Phone_Call

Now you can use the Options flow (Configuration > Integrations > Zoom > Options) to change which statuses are used. This will allow users to add In_Calendar_Event if they want to but it will not be forced on you.

v0.6.2 - Add 'In_Calendar_Event' for on status

I missed one status that will turn the binary_sensor on: In_Calendar_Event

So to recap, the sensor will turn on when the event is one of the following:

• In_Meeting
• Presenting
• On_Phone_Call
• In_Calendar_Event

Otherwise it will be off

v0.6.1 - Better logic for binary_sensor state

The existing logic for the binary_sensor state had the sensor on too often.
Previous strategy:off when the status is Available
New strategy: on when the status is one of In_Meeting, Presenting, and On_Phone_Call

This should make the state more useful, but the attribute that shows the status straight from Zoom is still available if you need more granularity

v0.6.0 - Multiple account support

While technically the integration already supported multiple accounts, practically speaking this wouldn't work because without publishing the custom Zoom app, your app can only be linked to the account it was created under. Now you can specify multiple sets of client ID, client secret, and verification token combinations for each account you want to link to. Check the updated README for instructions on how to do this.

v0.6.0-b2

BUG FIX: The event names that were being created were too long to get stored in the recorder. This change fixes that and future proofs us

v0.6.0-b1

Experimental support for multiple accounts has been added in this release. In order to support multiple accounts, you must use configuration.yaml instead of the UI to specify verification tokens, client IDs, and client secrets. If you previously used the UI to set the integration up and want to add support for multiple accounts, remove the existing config entry and restart your HA instance before attempting to do it.

Example configuration.yaml entry:

zoom:
  - client_id: <client_id>
    client_secret: <client_secret>
    verification_token: <token>
    name: <Account nickname>

The name parameter is new and is required if you have more than one entry. When you attempt to set up a Zoom integration, you will have to pick from a list of the names you provided. By doing this, you are telling the integration which client ID/secret and verification token to use with the account you are about to link.

v0.5.0 - Now with reauth support!

Could be because of the network blip today but I had to reauthorize HA to use Zoom. Previously this would require removing and reinstalling the integration, but now the integration should hopefully detect the need for reauth and trigger a notification in the UI. The reauth can be done without having to remove and re-add the integration.

v0.4.2 - Schema bug

It looks like Zoom made some changes to their API that was causing the schema validation of the event to fail. The change to the schema will fix this and should allow for more flexibility going forward

v0.4.1 - Bug Fixes

Fixed cases where the binary sensor may show as unavailable even though it can still receive webhook events.