good luck with that! I think the real win here would walking be them through the pre-approval, not the integration itself haha
BTW, if you get this resolved, I did discover an issue today so I’ve created another beta release and you should use that
Using latest beta. Added wife’s Zoom account. Can confirm multiple sensors working.
Thanks again for your work!
@raman325 I noticed that when my laptop wakes up from sleep (while Zoom app is completely closed) the sensor turns on, then after a few seconds turns off again.
Is it a bug? The problem is that I have an automation that announces the status to the whole house.
Well that’s annoying! Is your laptop the one running Home Assistant? If not, I can’t explain it to you since we primarily get the Zoom status from webhook events that Zoom itself sends to Home Assistant. The only thing I can think of is that maybe your laptop connects to Zoom briefly when you start your laptop up?
I can add some debug logging that might help figure this out. I will push an update tomorrow with some additional logging and let you know when you can update to the latest beta
@raman325 You don’t have to. I think I can do something about it on my end.
Edit: Looks like using the sensor’s status
attribute (In_Meeting
, Available
) gets around the issue.
ok well it looks like I already have the debug logging in place, so if you do want to investigate further, you can enable debug logging for the component and see what’s happening when you first turn on your laptop. With that being said, the status attribute is definitely a more granular version of the sensor, binary sensor turns on if you aren’t in the Available
status, so it covers In_Meeting
, Do_Not_Disturb
, etc.
Works great. Thanks!
@raman325 I found that restoring a full snapshot of HA for some reason invalidates previously created OAuth tokens, thus requiring each account to be setup and authenticated once again. Any way to avoid this when restoring a backup?
Thanks for your awesome work.
What is the actual behavior after the restoration? I don’t think we can prevent the invalidation from occurring - you get a new refresh token on every new token request, so when you go backwards, both your session token and your refresh token have already been invalidated. But I don’t think the integration detects invalid auth, requiring you to reauth, which I should be able to handle. I suspect you have to delete the integration and re-add it, is that correct?
Yes, I had to delete and recreate.
After restoration the integration showed a 401 error in the log and stopped working (sorry, I restarted before I was able to copy the stack trace).
All good, I will look into this soon
Turns out I tried to handle this but did it incorrectly. It should work with the latest - I tested it by manually invalidating my access and refresh tokens and starting HA up.
Hi, I am running HA in docker on a synology NAS. I am using a reverse proxy with SSL certificate handled by synology. I have managed to get the ZOOM integration in HA installed and finished, but the problem I am having is in the final stage when I try to install the app in zoom. It seems to start installing properly but then the web page comes up with “The site cannot be reached”. I noticed in the URL https://www.mydomain.duckdns.org:5001/?code=xxxxxxxxxxxxxxxxxxxxxxx
that the port number is changing to 5001 which is the port to acces the UI on the synology NAS.
@DaWix this is a bit out of scope for the integration, but I happen to own a Synology Diskstation, and to me it sounds like you have DSM configured to auto-redirect the user to your UI port. Try disabling that setting and trying again
I’m not sure where to begin with this, but I was previously using this integration easily and happily shortly after this integration was released last Fall. Followed the no nonsense instruction on the github site and was up and running with no problems. Whenever I entered a meeting (or left one) HA would typically recognize the status within a few seconds, but no longer than 20 seconds at times. That was the good old days.
I don’t know what has changed but it hasn’t worked correctly for months. It doesn’t seem to ever recognize a meeting starting or ending after any length of time. Removing and readding the integration with the UI will typically correctly show my current Zoom status at that very moment in time of readding-whether in a meeting or not- but wont’ recognize any status change beyond that. I don’t know what to do. All the required event subscription/scope options are checked.
Also, for whatever reason, my actual Zoom app says “In Meeting,” HA seems to think it’s “Do Not Disturb.” Not at any point am I ever manually changing my Zoom status to “Do Not Disturb,” yet HA seems to think that’s all I ever am. Either I’m Available, or I’m Do Not Disturb. None of the other “options” in the UI seem to show up when viewing the binary sensor.
Hi @ManImCool at any given time, the binary sensor can either say that you are on Zoom, or you aren’t. Zoom has more granularity than that, so there is a status attribute on the entity. Is that what you are referring to?
BTW if at any point you want to talk about this in more detail, reach out to me on Discord with the same username. If there’s an issue that needs to be resolved I’d like to understand what it is - for what it’s worth it works fine on my end.
I’ve been testing the integration for a while now. And I just can’t live without it. It’s working flawless. My number one integration.
Great job raman325
Hi @raman325,
noob question: when adding the ‘Zoom Event Name’, is that the entity name, entity id?
trigger:
platform: event
event_type: zoom_webhook
event_data:
event: <ZOOM_EVENT_NAME>
^this
It’s the event name as documented here: https://marketplace.zoom.us/docs/api-reference/webhook-reference/