Turns out the logs have a lot more spurious events with states of null and unavailable in addition to on and off events at least for TP Link devices. In the previous version I had guessed how to handle these events with respect to the state of the light/switch. Anyway after watching it more I came to the conclusion the only way to really deal with this was to add a state has table for all the light/switch entities seen in the log. On startup, the first time an entity is seen with a new state of either on or off it is added to the table and the action is scheduled. From that point on an event is only scheduled when the light/switch switches between off to on or on to off.
Turns out the logs have a lot more spurious events with states of null and unavailable in addition to on and off events at least for TP Link devices. In the previous version I had guessed how to handle these events with respect to the state of the light/switch. Anyway after watching it more I came to the conclusion the only way to really deal with this was to add a state has table for all the light/switch entities seen in the log. On startup, the first time an entity is seen with a new state of either on or off it is added to the table and the action is scheduled. From that point on an event is only scheduled when the light/switch switches between off to on or on to off.