Hello gurus,
I have the following calendar automation which stopped working after upgrading from 2024.6.x to 2024.7.x. Any pointers to set me on the right path would be appreciated.
Your trigger is a time trigger, yet you’re trying to access calendar information. If you want to view future calendar information without a calendar trigger, you need to use the calendar entity or the get_events service call.
This configuration wouldn’t have worked before 2024.7.x either.
This automation was created ~1.5 yrs ago and has been working since without errors. Perhaps by chance?
The function of the automation was to trigger roborock robot to clean segments 1,2 every mon,wed,fri @10am. Segments 1,2 were identified based on calendar summary text of Vacuum: Office.
Per your recommendation, should I then remove time trigger, and make it into a condition like so:
@123, thank you for taking the time to respond. To test out the logic (per @petro’s recommendation) I consolidated various {time + calendar} triggers like so; but now calendar doesn’t trigger at all. Verified this via checking Developer Tools-->Events-->Start Listening.
calendar state shows the next scheduled event correctly.
Tried to trigger it by creating a new one-time calendar event both within 15mins and after 15mins of calendar re-check cycles. No signal message (rightfully so). No persistent notification either; but seeing that its the default action for this automation no notification implies no triggering.
I doubt that automation represents what petro suggested.
What specific event were you listening for?
Your automation uses the match_found variable incorrectly due to scoping rules. The variable’s value is set to 1 inside a conditions section and that’s the limit of its scope. Outside of that section, the variable’s value remains 0.
morikplay
(per petro’s recommendation) I consolidated various {time + calendar} triggers like so;
123 Taras: I doubt that automation represents what petro suggested.
Thank you for the continued guidance. Originally I had two triggers time + calendar. I understood the issue w/ the setup. Calendar trigger had no offset. Which meant both calendar and time trigger would be triggered at the same time. The reason why it kept working was most likely that calendar trigger was being triggered a few nano/micro seconds, in os queues, before time trigger. Something in the internals of HA processing logic changed such that time trigger is now being received+processed before calendar. This would explain the errors (and is congruent w/ both @123 + @petro 's explainations.
What I meant by consolidating {time + calendar} can be seen in the new automation. time trigger is removed and instead made as a condition in the actions section. Hopefully, this helps clarify the situation.
What specific event were you listening for?
state_change events.
Your automation uses the match_found variable incorrectly due to scoping rules. The variable’s value is set to 1 inside a conditions section and that’s the limit of its scope. Outside of that section, the variable’s value remains 0.
Ah. I did read through the link before created the automation. But, I misunderstood this part
if a variable is changed in a nested sequence block, that change will not be visible in an outer sequence block.
My choice block is different to last if block. What would be the recommended way to achieve the desired result: if any of the non-default conditions of the choice block match, then send signal notification
The easy way is to duplicate the signal notification in each choice block. But, thats makes the code bloated and not easy to change (in future).
I did come across few threads on lack of global variables. Trigger Template sensor for this use may cause issues when multiple calendar automations are executed in parallel.
If Calendar Trigger and Time Trigger are scheduled to occur at the same time, after being triggered by the Calendar Trigger, it would have been immediately triggered by the Time Trigger. Two triggers, microseconds apart. What happens next depends on the automation’s mode.
If mode is single, the second triggering is ignored because the automation is still busy processing the first trigger. A warning message is logged, reporting the incident.
If mode is parallel, the second triggering is processed by another instance of the same automation. It will complain about an undefined reference to trigger.calendar_event because it was triggered by the Time Trigger.
I wouldn’t test a Calendar Trigger that way. Simply check the automation’s trace. The trace will show all the details of the automation’s execution. If there’s no trace, then the automation wasn’t triggered.
Traces do show successful run. It also shows the flaw (you pointed) wrt match_found logic. Lights turn off per trigger but signal notification isn’t sent due to local variable scoping.