Lighting Detection and Surge Mitigation

Lightning Detection and Surge Mitigation

Introduction

   Lighting is common in central Florida, which is the lightning capital of the U.S. (but not the world, Rwanda has that distinction).  For those of us running computer networks, the possibility of lightning storms and their attendant strikes can wreak havoc on our computer hardware.  Many people power off their computers when not in use, but for many networks, the computers provide monitoring and control functions for which it is desirable to run without interruption.

   There is hardware available to help mitigate the potential for lightning/surge damage.  You cannot protect against lightning strikes, but many surges resulting from lightning are at a level that can be protected against. Both whole house and point-of-use devices are available.

Cloud to Ground Lightning Incidence


Detection

   For our purposes, we want to take further action to mitigate the possibility of damages resulting from surges.  It is first necessary to detect lightning and decide when action is necessary. You shouldn't shutdown the network when lightning is detected unless you have confidence that the potential for real damage is high.  Otherwise, in Florida, you would not have very much availability of your systems.

  There are several methods one can use to detect nearby lightning.  An interesting optical sensor was developed by one of the SmComp group members that "sees" the lightning flashes.  David Powell has designed the circuit which uses a solar PV cell and an ESP8266 to detect and measure the flashes.  It is still under development but holds great promise for a simple-to-use system. A more detailed description can be seen at github.

   A software only solution might be possible using the World Wide Lightning Location Network.  This network of academic systems uses special hardware to figure the location of lightning strikes and generates images showing them.  An interesting map is available at:  http://wwlln.net/new/map/  You can download their data by specifying a latitude, longitude and radius.  Both the map and the data are delayed by 30 minutes which makes it less useful for system protection.

   A similar system is at lightningmaps.org.  Its data is current but you are not able to download the data unless you are a contributor.  I really like this system when testing other methods of detection.

   Another method uses the RF spectrum to detect lighting discharges using a specially designed IC. The Sparkfun company sold a board built around the Franklin AS3935 integrated circuit (datasheet).  That board has unfortunately been discontinued.

  Still available, and one one of the easiest ways to detect nearby lightning strikes, is the Acurite 06045M  Lightning Detector (LD).  It also uses the Franklin sensor.  There is a user manual available.  The sensor is designed to display data on one of the Acurite display units.  The display units are not expensive and can be purchased with a sensor and rain gauge at Acurite's website.
Acurite 06045M Lightning Detector



   You do not have to use an Acurite display unit.  All Acurite sensors use a 433 MHz transmitter to broadcast their data to local display units.  We can leverage that transmitter by using a Software Defined Radio (SDR) to receive the 433 MHz signal from the LD sensor.  The SDR, coupled with software running on a Raspberry Pi (RPi) computer, will capture strike data and allow us to display and use the data.

   The software package, named rtl_433,  was created by Benjamin Larsson (merbanan). It listens on 433 MHz and decodes data from many popular devices.  Acurite devices are well supported, as well as those from other manufacturers.  It can be downloaded from github.

   Once you have the rtl_433 software running, you can direct its output into one of two programs I've written.  Either program will take data from rtl_433 and publish it to a MQTT broker for use on the network.  The first is a BASH version using a shell script to convert the data to MQTT publications, the second is a python program.  There is little functional difference between the two programs. Both programs must be setup with the broadcast id from the sensor.

   The requirement for an MQTT broker could be met by the Home Assistant home automation package.  However, that broker is deprecated, so you should install a different broker.  The Mosquitto broker works very well. This package allows you to display data from various sensors and switches and control them as well.  Automations allow action to be taken when certain conditions occur.

   Since all of the Acurite sensors use the 433 MHz band to broadcast their data, you can capture and display all of the sensor data in Home Assistant, such as temperature, humidity, wind, rain, etc.  You can even display your freezer and refrigerator temperatures on Home Assistant with these sensors and display unit from Amazon.



Methods

   Though nothing we can do will protect against a lightning strike, there are things we can do that will help us avoid damage on our network from various levels of power surges caused by nearby lightning strikes.  Commercial surge protection devices are available for the house level.  There are also point-of-use devices available as surge protective devices implemented as protected power strips.

   Another way to minimize damage from lightning surges is to disconnect the device from wall power.  The simplest way is to unplug the power cord from the wall.  As long as we are talking about  WiFi networked devices, then there should be little chance of damage.  However, if lightning strikes close enough, there can still be damage to devices as the electromagnetic fields can induce current in any nearby conductors.

   For our small computers, we would want to unplug them from the wall after first shutting down the operating system.  To do the "unplug" automatically rather than manually, we can use a computer controlled relay.  There are inexpensive relays available which offer 500 to 1000 volts of isolation between the various relay components. 

   If an RPi computer is powered by a UPS, you can simply disconnect the input power through a relay.  There three options here, described below:  1) shutdown the RPi and UPS and disconnect from wall power, 2) leave the computer running, powered by the UPS battery, but disconnected from wall power, and 3) shutdown and disconnect with the autoshutdown board.  With method 2, the batteries will support the RPi for a limited amount of time, depending on battery capacity.  RPi computers will usually run for six hours on my UPS3v2 design.


Method 1 - Shutdown and Disconnect

   The first option can be achieved with the use of my UPS3v2 uninterruptible power supply along with the Disconnector 1 board. The UPS design uses a ESP8285 Mini Lite controller to manage the UPS functions. The board is described on my UPS3v2 blog .  The Disconnector 1 board includes an ATTiny controller to restart the UPS and client computer after a period of time.

   Using a Disconnector 1 board, the regulator supplying power to the ESP8285 is connected to a circuit which controls power to the disconnector relay. So, when the UPS controller shuts down, the input power to the UPS and RPi is disconnected with a quad-pole relay.


The Disconnector 1 built using perf board with the Autostart controller



Diagram of Disconnector 1



   I use the Disconnector 1/Autostart design with several RPi computers which are powered by my UPS3v2 uninterruptible power supply.  Along with software I wrote, the combination allows them to monitor for dangerous lightning conditions, shutdown the client RPi and UPS controller, then completely disconnect from wall power.  After a one hour delay, the autostart circuit will restart the UPS allowing the client RPi to power up and start the OS and the operating programs.  More information is available on the project blog for autostart.


Method 2- Disconnect and Run

   For those situations where the computer needs to remain up through the storm, the Disconnector 2 board is used.  This board is powered by the wall power adapter and controlled by a transistor switch.  The transistor is controlled by the client RPI computer from a GPIO pin, which is in turn controlled by a configured Home Assistant switch.  An optocoupler isolates the RPi GPIO pin from the wall power circuit with approximately 2500 volts isolation.  The relay used provides isolation of 1000 volts.

Disconnector 2 circuit built on a perf board.

Diagram of Disconnector 2


   This is the method and circuit I use with my Home Assistant controller which should be powered on and running continuously.


Method 3 - Autoshutdown

   The third method of surge mitigation is used for the Lightning Manager.  That computer is a RPi Zero W and because it has an operating systems and a microSDHC disk, it must be properly shutdown.  To achieve this without using a full-blown UPS circuit, I used an Auto Shutdown design, originally conceived by someone with the screen name techniccontroller.  It can be seen at https://techniccontroller.de/mini-ups-raspberry-pi/   He uses a Perma-Proto perf board from Adafruit to implement his design.

   I built a board with Seeed Studio to act as the micro UPS for my RPi Zero W.

Autoshutdown 2 printed circuit board
Schematic of the Autoshutdown 2 board



    Like techniccontroller's design, it uses a purpose-built IC, the TL7705BCP Supply-Voltage Supervisor to monitor the input power. The power is buffered by a pair of 10F to 15F capacitors in series.  When the voltage drops below a certain level (~4.7V), it signals the RPi Zero to shutdown.  It will also then turn off the power to the RPi when the voltage drops to about 3 volts.

   Naturally, this provides no isolation from power for the RPi.  For now, the micro UPS is powered by a Sonoff switch controlled by HA.  It is one of the devices turned off at the 100% confidence level.  I am still working out in my head how best to isolate this device.


Lightning Manager

   For my network, data analysis is provided by my Lightning Manager, running on a RPi Zero W.  Data captured by the Acurite LD sensor, the rtl_433 package and either of my publishing programs is transmitted in JSON format and interpreted by Home Assistant.  It is then displayed on an HA screen:


   The sensor transmits a running count of lightning strikes which rolls over after 127 events.  The LM keeps track of the rollover and accounts for it in its calculations.


   This hardware/software chain produces an output message which looks like this:

rtl433/acurite/lightning -->   {"time" : "2019-07-24 11:51:14", "protocol" : 40, "model" : "Acurite Lightning 6045M", "id" : 248, "channel" : "A", "temperature_F" : 78.400, "humidity" : 56, "strike_count" : 56, "storm_dist" : 5, "active" : 1, "rfi" : 0, "ussb1" : 1, "battery" : "OK", "exception" : 0, "raw_msg" : "c0f86fb8d16cb8c599", "mod" : "ASK", "freq" : 433.956, "rssi" : -0.121, "snr" : 27.709, "noise" : -27.831} 

This entry in sensors.yaml receives the data in HA:

- platform: mqtt
  name: "acurite lightning strikes"
  state_topic: "rtl433/acurite/lightning"
  qos: 0
  value_template: '{{ ((value_json.strike_count)) }}'
  unit_of_measurement: 'strikes'


  HA retransmits the lightning sensor data with an automation every minute to provide only essential data without JSON encoding. This entry in automations.yaml that does this:

### retransmits
- id: retrans_lightning
  alias: 'Publish Lightning strikes to MQTT'
  trigger:
    platform: time
    minutes: '/1'
    seconds: 0
  action:
    - service: mqtt.publish
      data_template:
        topic: 'ha32163/lightning/strikes'
        payload: '{{ states("sensor.acurite_lightning_strikes") }}'
        retain: true

- id: retrans_lightning distance

  alias: 'Publish Lightning distance to MQTT'
  trigger:
    platform: time
    minutes: '/1'
    seconds: 0
  action:
    - service: mqtt.publish
      data_template:
        topic: 'ha32163/lightning/distance'
        payload: '{{ states("sensor.acurite_lightning_distance") }}'
        retain: true


   It is not enough to simply capture data from from the LD sensor and publish it.  You need to analyze the data to determine whether local computers should disconnect from wall power to protect themselves from surge-caused damage.  On my network, this is accomplished by the Lightning Manager (LM) software running on a RPi Zero W computer.  The Lightning Manager software is available on github.  Only the files detect.py and rules.py are strictly necessary on the manager.

  The other files allow the user to capture strike data in a SQL database and subsequently use it for test purposes.  The script file plays 4 different events which will cause the LM (in test mode) to come up with a 100% probability and all the clients to shutdown.  If you are knowledgeable in SQLite, you can use the database dump to populate a database for this purpose.

   This LM software subscribes to the retransmits and continuously analyzes the past 30 minutes of strike and distance data using a sliding window technique.  It decides what the risk is and makes that data available over a TCP socket. The socket is then accessed by network client software running on various RPi computers.  The client software on github is the file check_lightning.

   The following shows output from the LM software:

2019-07-24 11:59:00.013740
ha32163/lightning/strikes 56
myLightning = 56
array length= 30
mystart= 0
[56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56, 56]
same strikes= 30
strikedelta= 0   strikedelta2= 0
stormdistance= 5
Storm probability= 5

2019-07-24 11:59:00.146752
ha32163/lightning/distance 5
Storm distance= 5
same strikes= 30
strikedelta= 0   strikedelta2= 0
stormdistance= 5
Storm probability= 5
Connection 19925 from ('192.168.2.34', 35292)(client-checkin) 2/19926
Connection 19926 from ('192.168.2.69', 55466)(client-checkin) 2/19927
Connection 19927 from ('192.168.2.35', 34144)(client-checkin) 2/19928
Connection 19928 from ('192.168.2.34', 35330)(client-checkin) 2/19929


Actions

   The client computers run the previously mentioned check_lightning, available on github. This program connects to the TCP socket to receive messages relating to the lightning environment.  Below is an example of program startup on one of the RPis (Zero4, which although it is a RPi Zero W, it is supported by a UPS3v2 instead of the Autoshutdown board):

pi@zero4:~/checkin $ ./check_lightning
starting real cmd mode...
Version 1.4
running on host zero4 supported by ota6
with command URL http://ups-control-ota6./stop

Checking for good startup value

*********************
This is UPS-control-OTA6 at 192.168.2.61 supporting host zero4
Running UPSx-control v1.5d on a ESP8266_WeMos_D1_mini_Lite
Reboots: 0
Running for 238390 seconds  DM time to go: 114
Battery voltage(avg): 10.67 @ 100.4 degrees F
Supply power is on
On battery: 0 seconds
Charger is off for 223548 seconds
*********************

strikes 56 0 30 5 - OK to start up
strikes 56 0 30 5 - Minimal (5) storm detected
strikes 56 0 30 5 - Minimal (5) storm detected

   The program does a test connection to its supporting UPS and prints the UPS webpage on the program screen.

  When a client computer sees that the risk of a damaging strike is 100%, it issues a stop command via HTTP URL to its supporting UPS.  The UPS then uses its usual methods to shutdown the RPi, power it off, and also power itself off.  The act of the UPS turning itself off also powers off the relay on the Disconnector 1 board, this disconnecting the whole rig from wall power.

   The action is somewhat different for the Home Assistant RPi itself.  This computer uses the Disconnector 2 board controlled by HA to disconnect for a period of time.  The extract from automations.yaml to do this is:

# for ha32163, don't shutdown, merely switch to batteries
# disconnector on --> ha32163 power off after 5 second delay
    - delay: '00:00:05'
    - service: switch.turn_on
      entity_id: switch.ups1_disconnector

    - service: light.turn_on

      data:
        entity_id: light.rgb1
        effect: 'red_fade'
    - delay: '00:00:02'

    - service: light.turn_on

      data:
        entity_id: light.rgb2
        effect: 'red_fade'

   The logic may seem reversed,  but this is a disconnector board, not a connector board. The HA switch is turned "on", which turns on the optocoupler transistor, which turns off the relay driver and relay, and disconnects the system from wall power.  Additionally, I configured 2 RGB undercounter lights do do a red fade on and off when this happens.

   The file switches.yaml contains the config entry to define the GPIO 11 as the controlling pin for the switch:

- platform: rpi_gpio
  ports:
    11: ups1_disconnector


   There are many other steps in the automation which runs for 100% strike confidence.  For example, the watchdog items for the computers which are shutting down are disabled so I don't get notifications that the applications and computers have stopped.


Notifications

   In addition to the actions take during a lightning storm, there are notifications which occur at various stages during the storm. I use pushbullet as the notifier in HA. This component is easily configured in HA as an entry in the notifiers file:

- name: pushbullet
  platform: pushbullet
  api_key: !secret api_key

   There is an Android app that you must install and an account to create.  This video describes the process very well.  Pushbullet works great as a notifier, I highly recommend it.

   One of the preliminary notifications occurs when 5 strikes in the past 30 minutes have been detected. It is configured as such in the automations.yaml:

- id: lightning detected2
  alias: lightning detected2
  trigger:
  - platform: numeric_state
    entity_id: sensor.zero5_strike_delta
    above: '5'
  action:
    - service: notify.pushbullet
      data:
        title: Lightning detected2
        message: "Zero5 LD manager is reporting a lightning strike delta above 5"


not a complete document,

more to follow...


   To me, this is a fairly complicated project and is difficult to explain with clarity in this first draft. I apologize for the confusion.

Gerald Swann
Small Computer Club group member






Comments

Popular posts from this blog

UPS Project

Lawn Sprinkler project