Multiple resources disconnected event

When I disconnect multiple things at the same time: webcam, controller and mic (pull all 3 USB wires out), I do not get room alerts reliably. I have seen that sometimes we do not get one of the resource disconnected.

Hey @ameya,

Can you check your Webhook logs to see if each event is sent?

Thanks,
Tommy

Hi Tommy.

We cannot collect any logs because they are not available for the application type we are building
See following thread

Please advise

Hey @edwardm, thanks for posting and using Zoom!

Are you sending back a 200 OK response each time you receive a webhook? If not, Zoom thinks the webhook was sent to an invalid url and will not send future ones.

Also can I ask your use case for disconnecting all 3 wires at the same time?

Thanks,
Tommy

I am pretty sure we do. Will dobule check.

Also per Ben’s suggestion posting here list of Q&A Ben suggested to help and troubleshoot the situation

Does your Zoom account meet all the prerequisite criteria here: https://marketplace.zoom.us/docs/api-reference/webhook-reference/zoom-room-events/zoom-room-alert?

[Edward Melomed] Correct, it does
Are you intentionally triggering one of these specific events that are listed as being supported: High CPU Usage, Low Batter, Charging or Connection Issues in a Zoom Room Device (computer, controller, or scheduling display), Room Controller Disconnections/Reconnections, Camera Disconnections/Reconnections, Missing Camera/Microphone, Speaker Disconnection/Reconnections?

[Edward Melomed] As described in the case referred below we are intentionally triggering some of the events to test this functionality.
Have you subscribed your app in Zoom Marketplace to the necessary webhooks?

[Edward Melomed] We do
Have you installed the app (initialize the webhook deliveries to the endpoint you define)?

[Edward Melomed] Yes.
If you’re using an OAuth app, have you created a Webhook-Only app (to provide you access to the Webhook Logs for testing)?

[Edward Melomed] Creating Webhook-Only app is an option, but:

1. This is significant overhead

2. Going forward we would like to use our OAuth App to service range of functionality: From the Room Monitoring to reporting and analytics around Zoom usage. We would like to minimize number of times we ask Account Admin for permissions to authorize our application. .
Have you used your Webhook-Only app for triggering test events, waiting at least 5 minutes propagation into Zoom Marketplace Webhook Logs (there is latency in reporting the webhook logs in Marketplace)?
Have you tested other webhook events (some basic ones such as Meeting Started) to be certain your app is subscribed/receiving events from Zoom properly?

[Edward Melomed] We have. We are subscribed to the range of events. We are seeing events being triggered. The problem is with event reliability.
Have you checked the Dashboard for your account to see if there is supporting data in Dashboard that demonstrates these events are not being broadcast?

[Edward Melomed] We did try to corelate with Zoom Dashbaord. For example we have seen cases where Zoom Dashbaord would report “Scheduling Display Disconnected” and walking to a particular room we have seen display itself showing online.
Have you tried switching your app in Zoom Marketplace to use an external webhook consumer testing service such as https://webhook.site as the destination for your webhook events (to be proof-positive it isn’t internal to your webhook consumer code/service that’s causing the disruption in the events)?

[Edward Melomed] We have used webhook.site. At the same time we have invested quite a bit of effort to make our webhook consumption code robust. We have implemented redundancy in our code and we are logging each event we receive in multiple ways.

At the end of the day webhook.site is not a replacement for logs.

1 Like

Hey @emelomed,

After confirming you are sending a 200 OK response back, please send us all relevant data, like Zoom Room IDs, time ranges, steps to reproduce the issue, and any other data you have so we can investigate in the logs on our end.

Thanks,
Tommy

1 Like