Strikes count sensor for AS3935

[RichardDern]

Describe the problem you have/What new integration you would like

It might be nice to have a strikes count sensor for the AS3935.

Please describe your use case for this integration and alternatives you've tried:

Every time the sensor publishes an update, it could also send number of strikes that happened since the last update. It would be reset to 0 after updating corresponding sensor.

Additional context

[OttoWinter]

I don't think the AS3935 exposes that data. It mainly only exposes if a lightning storm is nearby and how far away it is. I think the sensor is mainly made for UPS and devices that need to know if there might be power surges.

See also the datasheet https://www.embeddedadventures.com/datasheets/AS3935_Datasheet_EN_v2.pdf

CC: @TheEggi (do you know if the AS3935 exposes that data?)

[RichardDern]

It doesn't, but one could use a global variable increased every time the IRQ is triggered, and reset to 0 after data is sent.

[OttoWinter]

In that case I would recommend using a separate pulse_counter sensor. Connect the IRQ pin to your ESP and count the pulses with that. It's then also in a nice format in pulses/min (or another time unit of your choosing) and you can integrate it over time with integration.

Edit: looks like the AS3935 implementation already has an interrupt on the IRQ pin. So two things then:

• The implementation currently registers an interrupt on that pin. But the datasheet says the IRQ pin is held high until data is read out, so we don't need to use a pin interrupt at all (makes the code simpler).

• We can expose that value as a sensor in the future.

[RichardDern]

Oh, I haven't thought about using the pulse counter. That's a much better idea !

[RichardDern]

Actually, I think the pulse counter solution won't work, as you need to check for every pulse wether it's noise, human-originated or actual lightning. At least, this is how the MOD-1016 works.

[TheEggi]

The binary sensor should only get triggered if there was a real interrupt - but I guess there was still an issue with the handling. Thanks for fixing that @OttoWinter

[OttoWinter]

@TheEggi No no the previous handling was fine! I just realized when going through the datasheet that the IRQ line gets pulled high until the data is read out. So using a pin interrupt for that was a bit unnecessary, I just switched out the interrupt for a polling mode.