Further…
I don’t have a spare optical pulse detector, but I know from tests I carried out many years ago that the output is a logic ‘high’ (3.3 or 5 V) when the sensor is illuminated and the LED is lit. I am only able to test with a mechanical switch using the internal pull-up in the pulse input, and this presents a permanent 3.3 V to the pulse input (confirmed with a multimeter) and the switch pulls the input to GND when closed.
I have checked and the above sketch and library perform exactly as required: the sketch runs with a permanent logic ‘high’ on the pulse input and does not count pulses; when the switch is closed, it counts one pulse even if the switch remains closed for an extended period, and does not count another pulse when the switch is released.
The effect of the pull-up on the input should exactly emulate (as far as the logic is concerned) the permanently lit sensor, so I am unable to replicate your fault.
You might wish to note that emonLibCM allows you to specify the switch debounce period, which should be zero for the optical pulse detector, and the edge on which to trigger, rising ( 0 → 3.3 V) or falling (3.3 V → 0). The default is
EmonLibCM_setPulseMinPeriod(20, (byte)FALLING); // 20 ms
There is more about the circuitry inside the optical pulse sensor here, including measurements: First try with EmonPi - Pulsecount stuck at 1; some is repeated here: Monitoring energy via utility meter pulse output — OpenEnergyMonitor 0.0.1 documentation