I can’t even remember testing an automation by skipping its trigger and condition. Almost all of my automations use the Trigger State Object. Manually triggering this kind of automation is pointless because then the Trigger State Object will be undefined (and everywhere it is used in the automation will fail). To test this kind of automation, it must be triggered.
In the case where the automation doesn’t refer to the Trigger State Object, at least in my applications, it tends to be simpler and I don’t normally need to do much debugging. However, if I do want to debug it, I can test it as a script first. When functional, I can either have the automation simply call that script or just copy-paste the script’s code into the automation’s action. Easy-peasy.
So skip_condition is not something I rely on for debugging purposes but to each his own.
+1 on that. I feel it would be best if More info would act on the instance in real life operation only, eg like the lights more info, where one can set brightness or color wheel.
Not for developing. As a matter of fat, I would even mind if the ‘Execute’ button would be taken out of the more-info…
Developing is what one does in dev tools, and yes, all requested functionality is available, except the toggle for the condition skipping.
Which now is available in the service fields as an automation parameter skip_condition, which in itself is not correct either because it simply isn’t a parameter for the automation (see docs) and might be quite confusing as it is now.
Replacing this ‘parameter’ with a toggle would seem to solve both issues?
my 2 cents.