My suggestion to ‘fix’ the null triggering problem is to add a trigger condition that only allows valid triggers thru to the actions. Z2M sends these null triggers out as part of the way it is designed, so screening them is important. For this one a condition block after the trigger would make your users very happy…
condition:
condition: template
value_template: '{{ trigger.to_state.attributes.action in ( ''single'',''double'',''long'') }}'
That will clean up everyone’s log and the only place you see them is if you look at the traces, there will be triggers that happen but fail the condition and die.
Due to requests, I wrote the condition for you…
I hope the author adds this to the actual blueprint, I cannot. However if users manually edit their copy of the blueprint code adding the condition after th trigger, it should only run the blueprint code if one of these things happen, Other event will trigger the blueprint but fai the condition and no nothing. If you stil cannot see traces in the default 5 allotted to fix your stuff, just add to the automation that calls the script a line to store more traces…
condition:
condition: template
value_template: '{{ trigger.to_state.attributes.action in ( ''single'',''double'',''triple'',''quadruple'',''hold'',''release'',''shake'',''single_left'',''double_left'',''triple_left'',''hold_left'',''release_left'',''single_right'',''double_right'',''triple_right'',''hold_right'',''release_right'',''single_center'',''double_center'',''triple_center'',''hold_center'',''release_center'',''single_both'',''double_both'',''triple_both'',''hold_both'',''release_both'') }}'