I failed to notice until half a year later that you replied to me. Yes, my final/3rd paragraph is what I was referring to what you’re describing.
But that was a secondary/trivial problem, my primary problem was the 2nd paragraph, which isn’t what you were talking about.
In any event, I can’t remember what I did many months ago but I eventually got it working again and it has since worked flawlessly with 100% perfection to date. I use it all the time.
My usage dropped a bit during summer, but given the current variant going around and unvaccinated/idiot rates, it appears my use of this integration is going to increase again. Thanks for the good work!
For one, the structure of event_data has changed, and you would actually want to have the event_data look like this:
event_data:
status:
event: <ZOOM_EVENT_NAME>
I’ve updated the README accordingly.
in terms of the issue you actually asked about, I’m not sure why you are getting that because it looks right to me… is your indenting correct? If you think it is, would you mind pasting the full automation so I can see it?
You have trigger twice. Remove the second one and pull everything underneath trigger in by one indent similar to what you have done for the condition and action
ok I’m back. had to do a pretty serious do-over. my pi bit the dust and I now have a fresh clean system running. No 500 error, but I cannot get this to fire.
try removing the context from the trigger. If you have set up the Zoom integration for multiple accounts and want to trigger on a specific one, there’s probably additional information in the event_data that you can use to filter on instead. If that doesn’t help, confirm that the binary_sensor is indeed on when the event comes in
OK I just tested it and I realized there is a bit of a bug. It turns out that because the data is under the status key, HA requires you to match the full data under the status key and not just one key. I will consult with the core devs on whether this needs to be fixed in core or in the integration. Stay tuned, and sorry for the wild goose hunt!
OK, just pushed a new release that changes the event data structure so that you can trigger just based on the zoom webhook event name (this means you will have to change your automation back to what you originally had). If you don’t see the option to update the integration in HACS, click the … on the Zoom card in HACS and click Update information which will force HACS to check for updates
Thanks for getting back to me … saw the update was pending along with an update for HACS. Ran both and restarted. I can still trigger the light manually when I run actions … but not when I initiate a call on Zoom.
Still nothing … I’m just going into zoom and starting a call. No lights. Tried also scheduling and joining a meeting as well. Again I can initiate with the run actions command, but not when zoom is actually running a live call.
The following worked for me, although it wasn’t always reliable, possibly because the binary sensor relies on these events too and may not change state until after your automation runs (not sure):
is your binary sensor turning off and on as expected? If not, you may need to verify that the account you are using for the Zoom app is the same one you linked the integration to.
Assuming the binary sensor is turning on and off as expected, try removing the condition clause entirely so you just have the trigger and action