Integration of the AS3835 lightning sensor board python script into weewx with exfoliation

[WH3080]

Hi,

I purchased and installed the MOD1016 lightning sensor module from embedded adventures (http://www.embeddedadventures.com/datasheets/MOD-1016_hw_v4_doc_v2.pdf).

The module is based on the AS3935, a programmable fully integrated Lightning Sensor IC that detects the presence and approach of potentially hazardous lightning activity in the vicinity and provides an estimation on the distance to the head of the storm. The embedded lightning algorithm checks the incoming signal pattern to reject the potential man-made disturbers (http://media.digikey.com/pdf/Data%20Sheets/Austriamicrosystems%20PDFs/AS3935.pdf).

I hooked the board up to my Raspberry Pi B+ through I2C. My Raspberry is generally running headless, i.e. without a monitor or keyboard, except for maintenance. Phil Fenstermacher published a python library (https://github.com/pcfens/RaspberryPi-AS3935), which I used for the installation. The demo.py script is now running and actually detecting lighning (which I verified with www.lightningmaps.org). 

The installation files are located in /home/pi/RaspberryPi-AS3935/

The demo script (below) is printing the results to the screen. I would of course like to "reroute" this output into weewx and show it on exfoliation. I searched the internet for an adaptable python script to accomplish that goal, but failed. My own python knowledge is close to zero.

Could you please help me to integrate the sensor output into weewex with exfoliation?

Minimal goal:

Create an "automatic start script" that loads demo.py at the raspberry startup automatically (like weewx). Print the output into a file (txt or html) located in the the exfoliation folder containing all FTP upload data, so it's automatically uploaded with all the orher exfoliation files.

Maximum goal:

True integration into weewx and exfoliation. Use the distance coding (0 - 40 km) to create "perimeter" circles on a Google map within exfoliation, load a "red alam banner" to display within exfoliation and have speex exclaim the detected ligthning and distance on the homepage of the exfoliation skin.

I'm sorry to bother all of you with this probably very basic stuff, but lightning detection is really exciting :-)

Thanks,

WH3080

---

This is the current demo.py code from Phil Fenstermacher:

#!/usr/bin/env python
	from RPi_AS3935 import RPi_AS3935
	import RPi.GPIO as GPIO
	import time
	from datetime import datetime
	GPIO.setmode(GPIO.BCM)
	# Rev. 1 Raspberry Pis should leave bus set at 0, while rev. 2 Pis should set
	# bus equal to 1. The address should be changed to match the address of the
	# sensor. (Common implementations are in README.md)
	sensor = RPi_AS3935(address=0x00, bus=0)
	sensor.calibrate(tun_cap=0x0F)
	sensor.set_indoors(True)
	sensor.set_noise_floor(0)
	def handle_interrupt(channel):
	time.sleep(0.003)
	global sensor
	reason = sensor.get_interrupt()
	if reason == 0x01:
	print "Noise level too high - adjusting"
	sensor.raise_noise_floor()
	elif reason == 0x04:
	print "Disturber detected - masking"
	sensor.set_mask_disturber(True)
	elif reason == 0x08:
	now = datetime.now().strftime('%H:%M:%S - %Y/%m/%d')
	distance = sensor.get_distance()
	print "We sensed lightning!"
	print "It was " + str(distance) + "km away. (%s)" % now
	print ""
	pin = 17
	GPIO.setup(pin, GPIO.IN)
	GPIO.add_event_detect(pin, GPIO.RISING, callback=handle_interrupt)
	print "Waiting for lightning - or at least something that looks like it"
	while True:
	time.sleep(1.0)

[mwall]

On Saturday, September 20, 2014 12:54:13 PM UTC-4, WH3080 wrote:

The demo script (below) is printing the results to the screen. I would of course like to "reroute" this output into weewx and show it on exfoliation. I searched the internet for an adaptable python script to accomplish that goal, but failed. My own python knowledge is close to zero.

Could you please help me to integrate the sensor output into weewex with exfoliation?

there are two parts to your problem:

1) get the data from the sensor and put it into a database.  you should write a weewx service to do this.  since you already have demo code in python, simply put that into a weewx service.  that will be much more robust than running the demo script in a separate process then reading output from the demo script into weewx.

as a starting point, see the attached 'snowdepth' service.  in the newArchiveRecord method, instead of reading a value from file, read the data directly from the sensor using the demo code.  save the data into a new field in the database such as 'range'.  see the customization guide for details about how to extend the weewx schema.

2) display the data from the database.  the easy version of this is to simply display the range (and direction, if you can get it) values.  these can be displayed and plotted as you would any other observation in weewx (see the customization guide for details).

putting the data onto a google map requires a bit more work but is not too difficult.  one approach would be to inject the range values into some javascript that plots the rings corresponding to the range values.  this can be done using weewx templates.

m

[WH3080]

Hi Matt,

thanks for pointing me in the right direction. I will give it a try and report back with results in due time.

Best,

WH3080

print "It was " + str(<span class="n" style="box-sizing:

...

[WH3080]

Hi Matt,

I want to start working on the weewx service now for the lightning module. Since weewx 3.0 was just released and also installed on my system, I'm wondering whether I should I still work from your recommended snow depth template, or is there another more current file I need to use?

Thanks!

WH3080 

[mwall]

On Sunday, December 7, 2014 2:59:04 PM UTC-5, WH3080 wrote:

Hi Matt,

I want to start working on the weewx service now for the lightning module. Since weewx 3.0 was just released and also installed on my system, I'm wondering whether I should I still work from your recommended snow depth template, or is there another more current file I need to use?

that example should still work.  have you tried it?

m

[Steve Meltz]

This sounds like fun! The sensor is quite inexpensive, so I might want to try this. Do you have the sensor indoors or out? The spec sheet says it will work indoors: this would be a great advantage to me.

Thanks, Steve

[mwall]

On Thursday, December 11, 2014 8:34:42 AM UTC-5, Steve Meltz wrote:

This sounds like fun! The sensor is quite inexpensive, so I might want to try this. Do you have the sensor indoors or out? The spec sheet says it will work indoors: this would be a great advantage to me.

please post pictures when you start measuring a foot or two of snow indoors ;)

m

[Steve Meltz]

Gee..I didn't realize lightening detectors worked on snow, too!!  Maybe the static charge on the snow flakes? I'll let you know the next time it snows here in South Florida!  :)

Steve

[WH3080]

Hi Matt and Steve,

the sensor is a tiny PCB which I hooked up to my rpi indoors. The rpi is connected via ethrnet to my router and the WH3080 console. I played with the demo.py script and the sensor actually does detect lightning at various distances. I verified it with a leading commercial lightning detection service (http://www.euclid.org/blids.html) and the amateur community (http://www.blitzortung.org/Webpages/index.php?lang=en&region=3).

Technically, the sensor actually detects a low frequency signal which caused that crackling sound on your grandma's old radio, when lightning was in the area.

Matt suggested I write a service based on the snow depth example. I want to try that over x-mas. However, I am not python savvy and just started taking Eric Grimsons virtual MIT Python classes here: http://ocw.mit.edu/6-00F08 and https://www.youtube.com/watch?v=k6U-i4gXkLM&list=PL4C4720A6F225E074

Any help is greatly appreciated.

WH3080

[gjr80]

Hi,

Good to hear it works, when I saw you first post on this module back in Sep I ordered one shortly afterwards hoping I could get it going by end of year. Sadly it is still sitting in its little packet as unfortunately I have since spent most of my time getting Weewx-WD running under v3. If you still need it, I would be happy to help out in a couple of weeks. Do keep us informed how you get on.

Gary

[WH3080]

Hi Matt,

I made some progress. With the code below weewx flawlessly reads and logs (syslog) the AS3935 data. See syslog entry below.


# -*- coding: utf-8 -*-
#!/usr/bin/env python

"""
distance: a service for weewx that reads the AS3935 lightning sensor range.

Based on Phil Fenstermacher's RaspberryPi-AS3935 library and demo.py script. https://github.com/pcfens/RaspberryPi-AS3935 and Matthew Wall's support.

[Engines]
    [[WxEngine]]
        archive_services = ..., user.distance.Distance

"""

from RPi_AS3935 import RPi_AS3935

import RPi.GPIO as GPIO
import time

import syslog
import weewx
from datetime import datetime
from weewx.wxengine import StdService

GPIO.setmode(GPIO.BCM)

# Rev. 1 Raspberry Pis should leave bus set at 0, while rev. 2 Pis should set
# bus equal to 1. The address should be changed to match the address of the
# sensor. (Common implementations are in README.md)

sensor = RPi_AS3935(address=0x03, bus=1)
sensor.set_indoors(True)
sensor.set_noise_floor(0)
sensor.calibrate(tun_cap=0x6)

def handle_interrupt(channel):
    time.sleep(0.003)
    global sensor
    reason = sensor.get_interrupt()
    if reason == 0x01:

        syslog.syslog(syslog.LOG_INFO, "AS3935 detected noise level too high - adjusting")  

        sensor.raise_noise_floor()
    elif reason == 0x04:

        syslog.syslog(syslog.LOG_INFO, "AS3935 detected disturber - masking")

        sensor.set_mask_disturber(True)
    elif reason == 0x08:
        now = datetime.now().strftime('%H:%M:%S - %Y/%m/%d')
        distance = sensor.get_distance()

        syslog.syslog(syslog.LOG_INFO, "AS3935 sensed lightning!") 
        syslog.syslog(syslog.LOG_INFO, "It was " + str(distance) + "km away. (%s)") % now

pin = 17

GPIO.setup(pin, GPIO.IN)
GPIO.add_event_detect(pin, GPIO.RISING, callback=handle_interrupt)

syslog.syslog(syslog.LOG_INFO, "AS3935 is waiting for lightning.") 

while True:
    time.sleep(1.0)

Jun 14 14:01:23 raspberrypi weewx[9809]: engine: Initializing weewx version 3.1.0
Jun 14 14:01:23 raspberrypi weewx[9809]: engine: Using Python 2.7.3 (default, Mar 18 2014, 05:13:23) #012[GCC 4.6.3]
Jun 14 14:01:23 raspberrypi weewx[9809]: engine: pid file is /var/run/weewx.pid
Jun 14 14:01:24 raspberrypi weewx[9811]: engine: Using configuration file /home/weewx/weewx.conf
Jun 14 14:01:24 raspberrypi weewx[9811]: engine: Loading station type Simulator (weewx.drivers.simulator)
Jun 14 14:01:24 raspberrypi weewx[9811]: engine: StdConvert target unit is 0x1
Jun 14 14:01:24 raspberrypi weewx[9811]: engine: Archive will use data binding wx_binding
Jun 14 14:01:24 raspberrypi weewx[9811]: engine: Record generation will be attempted in 'hardware'
Jun 14 14:01:24 raspberrypi weewx[9811]: engine: Using archive interval of 300 seconds
Jun 14 14:01:24 raspberrypi weewx[9811]: engine: Using binding 'wx_binding' to database 'archive/weewx.sdb'
Jun 14 14:01:24 raspberrypi weewx[9811]: engine: Starting backfill of daily summaries
Jun 14 14:01:24 raspberrypi weewx[9811]: engine: Daily summaries up to date.
Jun 14 14:01:24 raspberrypi weewx[9811]: AS3935 is waiting for lightning - or at least something that looks like it
Jun 14 14:17:01 raspberrypi /USR/SBIN/CRON[9848]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)

Now I want to try archiving the sensor data to eventually plot it. If understand the snowdepth example correctly, it reads its data from a file, whereas I need to read it from the sensor directly.

Here is my attempt to this. What do you think?

# -*- coding: utf-8 -*-
#!/usr/bin/env python

"""
distance: a service for weewx that reads the AS3935 lightning sensor range.

Based on Phil Fenstermacher's RaspberryPi-AS3935 library and demo.py script. https://github.com/pcfens/RaspberryPi-AS3935 and Matthew Wall's support.

[Engines]
    [[WxEngine]]
        archive_services = ..., user.distance.Distance

"""

from RPi_AS3935 import RPi_AS3935

import RPi.GPIO as GPIO
import time

import syslog
import weewx
from datetime import datetime
from weewx.wxengine import StdService

GPIO.setmode(GPIO.BCM)

# Rev. 1 Raspberry Pis should leave bus set at 0, while rev. 2 Pis should set
# bus equal to 1. The address should be changed to match the address of the
# sensor. (Common implementations are in README.md)

sensor = RPi_AS3935(address=0x03, bus=1)
sensor.set_indoors(True)
sensor.set_noise_floor(0)
sensor.calibrate(tun_cap=0x6)

def handle_interrupt(channel):
    time.sleep(0.003)
    global sensor
    reason = sensor.get_interrupt()
    if reason == 0x01:

        syslog.syslog(syslog.LOG_INFO, "AS3935 detected noise level too high - adjusting")  

        sensor.raise_noise_floor()
    elif reason == 0x04:

        syslog.syslog(syslog.LOG_INFO, "AS3935 detected disturber - masking")

        sensor.set_mask_disturber(True)
    elif reason == 0x08:
        now = datetime.now().strftime('%H:%M:%S - %Y/%m/%d')
        distance = sensor.get_distance()

        syslog.syslog(syslog.LOG_INFO, "AS3935 sensed lightning!") 
        syslog.syslog(syslog.LOG_INFO, "It was " + str(distance) + "km away. (%s)") % now

pin = 17

GPIO.setup(pin, GPIO.IN)
GPIO.add_event_detect(pin, GPIO.RISING, callback=handle_interrupt)

syslog.syslog(syslog.LOG_INFO, "AS3935 is waiting for lightning.") 

while True:
    time.sleep(1.0)

class Distance(StdService):
    def __init__(self, engine, config_dict):
        super(SnowDepth, self).__init__(engine, config_dict)     
        d = config_dict.get('Distance', {})
        distance = sensor.get_distance()
        syslog.syslog(syslog.LOG_INFO, "It was " + str(distance) + "km away. (%s)") % now
        self.bind(weewx.NEW_ARCHIVE_RECORD, self.newArchiveRecord)
   
    def newArchiveRecord(self, event):
        try:
            with sensor.get_distance()
                value = str(distance)
            syslog.syslog(syslog.LOG_INFO, "Lightning range archived. It was " + str(distance) + "km away. (%s)") % now
            event.record['distance'] = float(value)
        except Exception, e:
            syslog.syslog(syslog.LOG_ERR, "distance: cannot read lightning range" % e)

Best,

WH3080

[mwall]

On Sunday, June 14, 2015 at 8:36:37 AM UTC-4, WH3080 wrote:

Here is my attempt to this. What do you think?

you have an interrupt-driven sensor, but weewx services are invoked synchronously on each archive record or loop packet.

you might want to run a standalone program that captures the lightning strike data, i.e., the time of each strike and the distance to each strike, and saves the results to database.  then run a weewx service that queries the database for a summary every archive interval.

another approach is to keep the gpio interrupt callback within the weewx service, incrementing counters as lightning strikes, then have the service summarize on each archive interval.  that approach might look something like this (i'm not sure how GPIO handles the interrupts - does it have a separate thread?):

# -*- coding: utf-8 -*-
#!/usr/bin/env python

"""
distance: a service for weewx that reads the AS3935 lightning sensor range.

Based on Phil Fenstermacher's RaspberryPi-AS3935 library and demo.py script.
 https://github.com/pcfens/RaspberryPi-AS3935 and Matthew Wall's support.

[Lightning]
    address = 0x3
    bus = 1
    noise_floor = 0
    calibration = 0x6
    indoors = True
    pin = 17

[Engine]
    [[Services]]
        data_services = ..., user.lightning.Lightning

"""

from RPi_AS3935 import RPi_AS3935
import RPi.GPIO as GPIO
import time

import syslog
import weewx
from datetime import datetime
from weewx.wxengine import StdService

from weeutil.weeutil import to_bool

class Lightning(StdService):
    def __init__(self, engine, config_dict):
        super(Lightning, self).__init__(engine, config_dict)
        svc_dict = config_dict.get('Lightning', {})
        addr = int(svc_dict.get('address', 0x03))
        bus = int(svc_dict.get('bus', 1))
        indoors = to_bool(svc_dict.get('indoors', True))
        noise_floor = int(svc_dict.get('noise_floor', 0))
        calib = int(svc_dict.get('calibration', 0x6))
        pin = int(svc_dict.get('pin', 17))

        self.data = []

        GPIO.setmode(GPIO.BCM)
        GPIO.setup(pin, GPIO.IN)

        # Rev. 1 Raspberry Pis should leave bus set at 0,

        # while rev. 2 Pis should set bus equal to 1. The
        # address should be changed to match the address of
        # the sensor. (Common implementations are in README.md)

        self.sensor = RPi_AS3935(address=addr, bus=bus)
        self.sensor.set_indoors(indoors)
        self.sensor.set_noise_floor(noise_floor)
        self.sensor.calibrate(tun_cap=calib)

        GPIO.add_event_detect(pin, GPIO.RISING, callback=handle_interrupt)

        self.bind(weewx.NEW_ARCHIVE_RECORD, self.read_data)

   
    def read_data(self, event):
        avg = None
        count = len(self.data)
        if count:
            avg = 0
            for x in self.data:
                avg += x[1]
            avg /= count
        self.data = []
        event.record['lightning_strikes'] = count
        event.record['avg_distance'] = avg

    def handle_interrupt(channel):
        try:   
            time.sleep(0.003)
            reason = self.sensor.get_interrupt()
            if reason == 0x01:

                syslog.syslog(syslog.LOG_INFO, "lightning: noise level too high - adjusting")  

                self.sensor.raise_noise_floor()
            elif reason == 0x04:

                syslog.syslog(syslog.LOG_INFO, "lightning: detected disturber - masking")

                sensor.set_mask_disturber(True)
            elif reason == 0x08:
                now = time.time()
                value = sensor.get_distance()
                self.data.append((now, value))

                syslog.syslog(syslog.LOG_INFO, "lightning: strike at %s km" % value)
        except Exception, e:
            syslog.syslog(syslog.LOG_ERR, "lightning: callback failed: %s" % e)

[WH3080]

Hi Matt,

many thanks for your advice. Running a separate program, having it write the lightning data to a file and then weewx read  it from there was my first idea (see beginning of the thread). However, you advised, that I'd rather create a weewx service and have it read the sensor directly. Thus I tried to do that. At least weewx started the service and read the sensor, but eventually got stuck, i.e. the normal loop never started.

I just tried your newly coded Lightning extension (and also edited the weewx.conf file) like this:

[Lightning]
    address = 0x3
    bus = 1
    noise_floor = 0
    calibration = 0x6
    indoors = True
    pin = 17

[Engine]

    # This section configures the engine.

    [[Services]]
        # These are the services the engine should run:
        prep_services = weewx.engine.StdTimeSynch
        data_services = user.lightning.Lightning
        process_services = weewx.engine.StdConvert, weewx.engine.StdCalibrate, weewx.engine.StdQC, weewx.wxservices.S$
        archive_services = weewx.engine.StdArchive
        restful_services = weewx.restx.StdStationRegistry, weewx.restx.StdWunderground, weewx.restx.StdPWSweather, we$
        report_services = weewx.engine.StdPrint, weewx.engine.StdReport,

Do I also need to amend the the squlite data base? That has not worked so far (I followed the instructions in the user guide / customization guide).

Unfortunately I know nothing about how GPIO handles the interrupts. Perhaps someone else in the forum has an idea.

Here is the log that shows weewx crashing with the new lightning script :-(

Thank you anyway for refining my crude attempt.

Best,

WH3080

Jun 14 19:18:03 raspberrypi weewx[11506]: engine: Initializing weewx version 3.1.0
Jun 14 19:18:03 raspberrypi weewx[11506]: engine: Using Python 2.7.3 (default, Mar 18 2014, 05:13:23) #012[GCC 4.6.3]
Jun 14 19:18:03 raspberrypi weewx[11506]: engine: pid file is /var/run/weewx.pid
Jun 14 19:18:04 raspberrypi weewx[11508]: engine: Using configuration file /home/weewx/weewx.conf
Jun 14 19:18:04 raspberrypi weewx[11508]: engine: Initializing engine
Jun 14 19:18:04 raspberrypi weewx[11508]: engine: Loading station type Simulator (weewx.drivers.simulator)
Jun 14 19:18:04 raspberrypi weewx[11508]: engine: Loading service weewx.engine.StdTimeSynch
Jun 14 19:18:04 raspberrypi weewx[11508]: engine: Finished loading service weewx.engine.StdTimeSynch
Jun 14 19:18:04 raspberrypi weewx[11508]: engine: Loading service user.lightning.Lightning
Jun 14 19:18:04 raspberrypi weewx[11508]: engine: Caught unrecoverable exception in engine:
Jun 14 19:18:04 raspberrypi weewx[11508]:     ****  invalid literal for int() with base 10: '0x3'
Jun 14 19:18:04 raspberrypi weewx[11508]:     ****  Traceback (most recent call last):
Jun 14 19:18:04 raspberrypi weewx[11508]:     ****    File "/home/weewx/bin/weewx/engine.py", line 831, in main
Jun 14 19:18:04 raspberrypi weewx[11508]:     ****      engine = EngineClass(config_dict)
Jun 14 19:18:04 raspberrypi weewx[11508]:     ****    File "/home/weewx/bin/weewx/engine.py", line 77, in __init__
Jun 14 19:18:04 raspberrypi weewx[11508]:     ****      self.loadServices(config_dict)
Jun 14 19:18:04 raspberrypi weewx[11508]:     ****    File "/home/weewx/bin/weewx/engine.py", line 141, in loadServices
Jun 14 19:18:04 raspberrypi weewx[11508]:     ****      self.service_obj.append(weeutil.weeutil._get_object(svc)(self, config_dict))
Jun 14 19:18:04 raspberrypi weewx[11508]:     ****    File "/home/weewx/bin/user/lightning.py", line 37, in __init__
Jun 14 19:18:04 raspberrypi weewx[11508]:     ****      addr = int(svc_dict.get('address', 0x03))
Jun 14 19:18:04 raspberrypi weewx[11508]:     ****  ValueError: invalid literal for int() with base 10: '0x3'
Jun 14 19:18:04 raspberrypi weewx[11508]:     ****  Exiting.

[mwall]

On Sunday, June 14, 2015 at 1:19:52 PM UTC-4, WH3080 wrote:

Do I also need to amend the the squlite data base? That has not worked so far (I followed the instructions in the user guide / customization guide).

you must extend the schema if you want to store the data.

for testing purposes you can simply run weewx directly and look at the REC values - if everything is working, you should see entries for 'lightning_strikes' and 'avg_distance'.  once that works you can add those two columns to the schema.

 

Here is the log that shows weewx crashing with the new lightning script :-(

replace 0x6 with 6 and replace 0x03 with 3

m

[WH3080]

Hi Matt,

I edited weewx.conf and replaced the hex numbers. It still crashes...

Jun 14 19:45:50 raspberrypi weewx[11593]: engine: Initializing weewx version 3.1.0
Jun 14 19:45:50 raspberrypi weewx[11593]: engine: Using Python 2.7.3 (default, Mar 18                                            2014, 05:13:23) #012[GCC 4.6.3]
Jun 14 19:45:50 raspberrypi weewx[11593]: engine: pid file is /var/run/weewx.pid
Jun 14 19:45:51 raspberrypi weewx[11595]: engine: Using configuration file /home/weew                                           x/weewx.conf
Jun 14 19:45:51 raspberrypi weewx[11595]: engine: Initializing engine
Jun 14 19:45:51 raspberrypi weewx[11595]: engine: Loading station type Simulator (wee                                           wx.drivers.simulator)
Jun 14 19:45:51 raspberrypi weewx[11595]: engine: Loading service weewx.engine.StdTim                                           eSynch
Jun 14 19:45:51 raspberrypi weewx[11595]: engine: Finished loading service weewx.engi                                           ne.StdTimeSynch
Jun 14 19:45:51 raspberrypi weewx[11595]: engine: Loading service user.lightning.Ligh                                           tning
Jun 14 19:45:51 raspberrypi weewx[11595]: engine: Caught unrecoverable exception in e                                           ngine:
Jun 14 19:45:51 raspberrypi weewx[11595]:     ****  global name 'handle_interrupt' is                                            not defined
Jun 14 19:45:51 raspberrypi weewx[11595]:     ****  Traceback (most recent call last)                                           :
Jun 14 19:45:51 raspberrypi weewx[11595]:     ****    File "/home/weewx/bin/weewx/eng                                           ine.py", line 831, in main
Jun 14 19:45:51 raspberrypi weewx[11595]:     ****      engine = EngineClass(config_d                                           ict)
Jun 14 19:45:51 raspberrypi weewx[11595]:     ****    File "/home/weewx/bin/weewx/eng                                           ine.py", line 77, in __init__
Jun 14 19:45:51 raspberrypi weewx[11595]:     ****      self.loadServices(config_dict                                           )
Jun 14 19:45:51 raspberrypi weewx[11595]:     ****    File "/home/weewx/bin/weewx/eng                                           ine.py", line 141, in loadServices
Jun 14 19:45:51 raspberrypi weewx[11595]:     ****      self.service_obj.append(weeut                                           il.weeutil._get_object(svc)(self, config_dict))
Jun 14 19:45:51 raspberrypi weewx[11595]:     ****    File "/home/weewx/bin/user/ligh                                           tning.py", line 60, in __init__
Jun 14 19:45:51 raspberrypi weewx[11595]:     ****      GPIO.add_event_detect(pin, GP                                           IO.RISING, callback=handle_interrupt)
Jun 14 19:45:51 raspberrypi weewx[11595]:     ****  NameError: global name 'handle_in                                           terrupt' is not defined
Jun 14 19:45:51 raspberrypi weewx[11595]:     ****  Exiting.

[mwall]

On Sunday, June 14, 2015 at 1:48:23 PM UTC-4, WH3080 wrote:

Hi Matt,

I edited weewx.conf and replaced the hex numbers. It still crashes...

replace this:

        GPIO.add_event_detect(pin, GPIO.RISING, callback=handle_interrupt)

with this:

        GPIO.add_event_detect(pin, GPIO.RISING, callback=self.handle_interrupt)

[WH3080]

Jun 14 20:07:32 raspberrypi weewx[11728]: engine: Initializing weewx version 3.1.0
Jun 14 20:07:32 raspberrypi weewx[11728]: engine: Using Python 2.7.3 (default, Mar 18 2014, 05:13:23) #012[GCC 4.6.3]
Jun 14 20:07:32 raspberrypi weewx[11728]: engine: pid file is /var/run/weewx.pid
Jun 14 20:07:33 raspberrypi weewx[11730]: engine: Using configuration file /home/weewx/weewx.conf
Jun 14 20:07:33 raspberrypi weewx[11730]: engine: Initializing engine
Jun 14 20:07:33 raspberrypi weewx[11730]: engine: Loading station type Simulator (weewx.drivers.simulator)
Jun 14 20:07:33 raspberrypi weewx[11730]: engine: Loading service weewx.engine.StdTimeSynch
Jun 14 20:07:33 raspberrypi weewx[11730]: engine: Finished loading service weewx.engine.StdTimeSynch
Jun 14 20:07:33 raspberrypi weewx[11730]: engine: Loading service user.lightning.Lightning
Jun 14 20:07:33 raspberrypi weewx[11730]: engine: Finished loading service user.lightning.Lightning
Jun 14 20:07:33 raspberrypi weewx[11730]: engine: Loading service weewx.engine.StdConvert
Jun 14 20:07:33 raspberrypi weewx[11730]: engine: StdConvert target unit is 0x1
Jun 14 20:07:33 raspberrypi weewx[11730]: engine: Finished loading service weewx.engine.StdConvert
Jun 14 20:07:33 raspberrypi weewx[11730]: engine: Loading service weewx.engine.StdCalibrate
Jun 14 20:07:33 raspberrypi weewx[11730]: engine: Finished loading service weewx.engine.StdCalibrate
Jun 14 20:07:33 raspberrypi weewx[11730]: engine: Loading service weewx.engine.StdQC
Jun 14 20:07:33 raspberrypi weewx[11730]: engine: Finished loading service weewx.engine.StdQC
Jun 14 20:07:33 raspberrypi weewx[11730]: engine: Loading service weewx.wxservices.StdWXCalculate
Jun 14 20:07:33 raspberrypi weewx[11730]: engine: Finished loading service weewx.wxservices.StdWXCalculate
Jun 14 20:07:33 raspberrypi weewx[11730]: engine: Loading service weewx.engine.StdArchive
Jun 14 20:07:33 raspberrypi weewx[11730]: engine: Archive will use data binding wx_binding
Jun 14 20:07:33 raspberrypi weewx[11730]: engine: Record generation will be attempted in 'hardware'
Jun 14 20:07:33 raspberrypi weewx[11730]: engine: Using archive interval of 120 seconds
Jun 14 20:07:33 raspberrypi weewx[11730]: engine: Use LOOP data in hi/low calculations: 1
Jun 14 20:07:33 raspberrypi weewx[11730]: engine: Caught unrecoverable exception in engine:
Jun 14 20:07:33 raspberrypi weewx[11730]:     ****  name 'self' is not defined
Jun 14 20:07:33 raspberrypi weewx[11730]:     ****  Traceback (most recent call last):
Jun 14 20:07:33 raspberrypi weewx[11730]:     ****    File "/home/weewx/bin/weewx/engine.py", line 831, in main
Jun 14 20:07:33 raspberrypi weewx[11730]:     ****      engine = EngineClass(config_dict)
Jun 14 20:07:33 raspberrypi weewx[11730]:     ****    File "/home/weewx/bin/weewx/engine.py", line 77, in __init__
Jun 14 20:07:33 raspberrypi weewx[11730]:     ****      self.loadServices(config_dict)
Jun 14 20:07:33 raspberrypi weewx[11730]:     ****    File "/home/weewx/bin/weewx/engine.py", line 141, in loadServices
Jun 14 20:07:33 raspberrypi weewx[11730]:     ****      self.service_obj.append(weeutil.weeutil._get_object(svc)(self, config_dict))
Jun 14 20:07:33 raspberrypi weewx[11730]:     ****    File "/home/weewx/bin/weewx/engine.py", line 504, in __init__
Jun 14 20:07:33 raspberrypi weewx[11730]:     ****      self.setup_database(config_dict)
Jun 14 20:07:33 raspberrypi weewx[11730]:     ****    File "/home/weewx/bin/weewx/engine.py", line 602, in setup_database
Jun 14 20:07:33 raspberrypi weewx[11730]:     ****      dbmanager = self.engine.db_binder.get_manager(self.data_binding, initialize=True)
Jun 14 20:07:33 raspberrypi weewx[11730]:     ****    File "/home/weewx/bin/weewx/manager.py", line 832, in get_manager
Jun 14 20:07:33 raspberrypi weewx[11730]:     ****      default_binding_dict=self.default_binding_dict)
Jun 14 20:07:33 raspberrypi weewx[11730]:     ****    File "/home/weewx/bin/weewx/manager.py", line 901, in get_manager_dict
Jun 14 20:07:33 raspberrypi weewx[11730]:     ****      manager_dict['schema'] = weeutil.weeutil._get_object(schema_name)
Jun 14 20:07:33 raspberrypi weewx[11730]:     ****    File "/home/weewx/bin/weeutil/weeutil.py", line 894, in _get_object
Jun 14 20:07:33 raspberrypi weewx[11730]:     ****      mod = __import__(module)
Jun 14 20:07:33 raspberrypi weewx[11730]:     ****    File "/home/weewx/bin/user/distance.py", line 53, in <module>
Jun 14 20:07:33 raspberrypi weewx[11730]:     ****      GPIO.add_event_detect(pin, GPIO.RISING, callback=self.handle_interrupt)
Jun 14 20:07:33 raspberrypi weewx[11730]:     ****  NameError: name 'self' is not defined
Jun 14 20:07:33 raspberrypi weewx[11730]:     ****  Exiting.

[WH3080]

Will do an report back. Your entire script has been in the lightning.py file all the time located in the bin/user dierctory. Thanks!!! WH 3080

On Sunday, June 14, 2015 at 9:51:18 PM UTC+2, mwall wrote:

replace this:

    def handle_interrupt(channel):

with this:

    def handle_interrupt(channel):

be sure that you put all of this in a file called lightning.py, since that is the name used in the service list:

    data_services = user.lightning.Lightning

m

[mwall]

replace this:

    def handle_interrupt(channel):

with this:

    def handle_interrupt(self, channel):

be sure that you put all of this in a file called lightning.py, since that is the name used in the service list:

    data_services = user.lightning.Lightning

from the stack trace it looks like you are using a file called distance.py

m

[WH3080]

Hi Matt,

sorry, indeed the schemas line was wrong. It still included a (distance) modified version. After chaning it back to "schemas.wview.schema" your script appears to work. No more error messages. Below is the log and the output when running it directly. Since there is no lightning currenty in the vicinity I can't expect the two variables to show up there, right?

Thanks again for your time!!!

This is exciting :-)


Jun 14 22:14:16 raspberrypi weewx[12107]: engine: Initializing weewx version 3.1.0
Jun 14 22:14:16 raspberrypi weewx[12107]: engine: Using Python 2.7.3 (default, Mar 18 2014, 05:13:23) #012[GCC 4.6.3]
Jun 14 22:14:16 raspberrypi weewx[12107]: engine: pid file is /var/run/weewx.pid
Jun 14 22:14:17 raspberrypi weewx[12109]: engine: Using configuration file /home/weewx/weewx.conf
Jun 14 22:14:17 raspberrypi weewx[12109]: engine: Initializing engine
Jun 14 22:14:17 raspberrypi weewx[12109]: engine: Loading station type Simulator (weewx.drivers.simulator)
Jun 14 22:14:17 raspberrypi weewx[12109]: engine: Loading service weewx.engine.StdTimeSynch
Jun 14 22:14:17 raspberrypi weewx[12109]: engine: Finished loading service weewx.engine.StdTimeSynch
Jun 14 22:14:17 raspberrypi weewx[12109]: engine: Loading service user.lightning.Lightning
Jun 14 22:14:17 raspberrypi weewx[12109]: engine: Finished loading service user.lightning.Lightning
Jun 14 22:14:17 raspberrypi weewx[12109]: engine: Loading service weewx.engine.StdConvert
Jun 14 22:14:17 raspberrypi weewx[12109]: engine: StdConvert target unit is 0x1
Jun 14 22:14:17 raspberrypi weewx[12109]: engine: Finished loading service weewx.engine.StdConvert
Jun 14 22:14:17 raspberrypi weewx[12109]: engine: Loading service weewx.engine.StdCalibrate
Jun 14 22:14:17 raspberrypi weewx[12109]: engine: Finished loading service weewx.engine.StdCalibrate
Jun 14 22:14:17 raspberrypi weewx[12109]: engine: Loading service weewx.engine.StdQC
Jun 14 22:14:17 raspberrypi weewx[12109]: engine: Finished loading service weewx.engine.StdQC
Jun 14 22:14:17 raspberrypi weewx[12109]: engine: Loading service weewx.wxservices.StdWXCalculate
Jun 14 22:14:17 raspberrypi weewx[12109]: engine: Finished loading service weewx.wxservices.StdWXCalculate
Jun 14 22:14:17 raspberrypi weewx[12109]: engine: Loading service weewx.engine.StdArchive
Jun 14 22:14:17 raspberrypi weewx[12109]: engine: Archive will use data binding wx_binding
Jun 14 22:14:17 raspberrypi weewx[12109]: engine: Record generation will be attempted in 'hardware'
Jun 14 22:14:17 raspberrypi weewx[12109]: engine: Using archive interval of 120 seconds
Jun 14 22:14:17 raspberrypi weewx[12109]: engine: Use LOOP data in hi/low calculations: 1
Jun 14 22:14:18 raspberrypi weewx[12109]: engine: Using binding 'wx_binding' to database 'archive/weewx.sdb'
Jun 14 22:14:18 raspberrypi weewx[12109]: engine: Starting backfill of daily summaries
Jun 14 22:14:18 raspberrypi weewx[12109]: engine: Daily summaries up to date.
Jun 14 22:14:18 raspberrypi weewx[12109]: engine: Finished loading service weewx.engine.StdArchive
Jun 14 22:14:18 raspberrypi weewx[12109]: engine: Loading service weewx.restx.StdStationRegistry
Jun 14 22:14:18 raspberrypi weewx[12109]: restx: StationRegistry: Data will not be posted. Missing option 'station_url'
Jun 14 22:14:18 raspberrypi weewx[12109]: engine: Finished loading service weewx.restx.StdStationRegistry
Jun 14 22:14:18 raspberrypi weewx[12109]: engine: Loading service weewx.restx.StdWunderground
Jun 14 22:14:18 raspberrypi weewx[12109]: restx: Wunderground: Data will not be posted: Missing option 'station'
Jun 14 22:14:18 raspberrypi weewx[12109]: engine: Finished loading service weewx.restx.StdWunderground
Jun 14 22:14:18 raspberrypi weewx[12109]: engine: Loading service weewx.restx.StdPWSweather
Jun 14 22:14:18 raspberrypi weewx[12109]: restx: PWSWeather: Data will not be posted: Missing option 'station'
Jun 14 22:14:18 raspberrypi weewx[12109]: engine: Finished loading service weewx.restx.StdPWSweather
Jun 14 22:14:18 raspberrypi weewx[12109]: engine: Loading service weewx.restx.StdCWOP
Jun 14 22:14:18 raspberrypi weewx[12109]: restx: CWOP: Data will not be posted. Missing option: 'station'
Jun 14 22:14:18 raspberrypi weewx[12109]: engine: Finished loading service weewx.restx.StdCWOP
Jun 14 22:14:18 raspberrypi weewx[12109]: engine: Loading service weewx.restx.StdWOW
Jun 14 22:14:18 raspberrypi weewx[12109]: restx: WOW: Data will not be posted: Missing option 'station'
Jun 14 22:14:18 raspberrypi weewx[12109]: engine: Finished loading service weewx.restx.StdWOW
Jun 14 22:14:18 raspberrypi weewx[12109]: engine: Loading service weewx.restx.StdAWEKAS
Jun 14 22:14:18 raspberrypi weewx[12109]: restx: AWEKAS: Data will not be posted: Missing option 'username'
Jun 14 22:14:18 raspberrypi weewx[12109]: engine: Finished loading service weewx.restx.StdAWEKAS
Jun 14 22:14:18 raspberrypi weewx[12109]: engine: Loading service weewx.engine.StdPrint
Jun 14 22:14:18 raspberrypi weewx[12109]: engine: Finished loading service weewx.engine.StdPrint
Jun 14 22:14:18 raspberrypi weewx[12109]: engine: Loading service weewx.engine.StdReport
Jun 14 22:14:18 raspberrypi weewx[12109]: engine: Finished loading service weewx.engine.StdReport
Jun 14 22:14:18 raspberrypi weewx[12109]: engine: Starting up weewx version 3.1.0
Jun 14 22:14:18 raspberrypi weewx[12109]: engine: Clock error is -1.22 seconds (positive is fast)
Jun 14 22:14:18 raspberrypi weewx[12109]: engine: Starting main packet loop.

pi@raspberrypi /home/weewx/bin $ sudo ./weewxd /home/weewx/weewx.conf
LOOP:   2015-06-14 22:23:43 CEST (1434313423) {'rainRate': 0, 'heatindex': 32.657716545705256, 'barometer': 31.099999405044162, 'windchill': 32.657716545705256, 'dewpoint': 27.183218936641                  57, 'outTemp': 32.657716545705256, 'outHumidity': 79.99998215132483, 'inDewpoint': 31.079524576570254, 'UV': 0, 'radiation': 0, 'rain': 0, 'dateTime': 1434313423, 'windDir': 359.9998929079                  4895, 'pressure': 31.099999405044162, 'windSpeed': 2.9747791954193303e-06, 'inHumidity': 29.99997620177352, 'inTemp': 63.00001189911324, 'windGust': 3.5697350337926537e-06, 'altimeter': 31                  .30037848812055, 'usUnits': 1, 'windGustDir': 359.99989290794895}

[WH3080]

Hi Matt,

"avg_dist" is shwoing now :-) !!!

REC:    2015-06-14 22:28:00 CEST (1434313680) {'UV': 0.0, 'outHumidity': 79.99991075668785, 'lightning_strikes': 0, 'altimeter': 31.300376095339356, 'heatindex': 32.63606503340119, 'radiation': 0.0, 'inTemp': 63.0000594953963, 'inDewpoint': 31.079487506291215, 'barometer': 31.09999702522293, 'windchill': 32.63606503340119, 'dewpoint': 27.162095467527287, 'rain': 0.0, 'pressure': 31.09999702522293, 'rainRate': 0.0, 'usUnits': 1, 'interval': 2, 'dateTime': 1434313680.0, 'windDir': 359.99912184593086, 'outTemp': 32.63606503340119, 'windSpeed': 1.4873885356703198e-05, 'inHumidity': 29.999881009207407, 'windGust': 3.212758982140684e-05, 'avg_distance': None, 'windGustDir': 359.99903617230535}

Great!!!

Now I "need" a t-storm ...

WH3080

On Sunday, June 14, 2015 at 10:03:23 PM UTC+2, mwall wrote:

[WH3080]

Hi Matt,

"lightning_strikes" is showing now too.

You're a genious to create and troubleshoot all that remotely!

Thank you so much!

WH 3080

On Sunday, June 14, 2015 at 10:03:23 PM UTC+2, mwall wrote:

[Robin]

Hello WH3080 and Matt,

This looks like it could be fun! We get some really heavy storms here in our part of Greece.

I've been reading through the posts and trying to figure out if I am capable of making this work and the answer is possibly.

Any chance of making the working files available with a guide to help a simple guy like me get it going?

The sensor is so cheap, even with postage to Greece.

Thank you.

Robin

...

[mwall]

On Tuesday, June 16, 2015 at 4:35:45 AM UTC-4, Robin wrote:

Any chance of making the working files available with a guide to help a simple guy like me get it going?

robin,

the as3935 service is now packaged as a weewx service.  like other packaged services, you can install with a single command.  please give this a try:

https://github.com/weewx/weewx/wiki/as3935

i added an option: data_binding. if this is specified, then the service will save lightning strike data to a separate lightning database.  you can then use data from that database in any weewx report or plot, or you can query the data directly to slice and dice how every you want.

m

[Robin]

Thank your for the quick reply.

After a rush of blood, I ordered the MOD1016 annd then became worried that my better half might bury my remains under the patio for wasting money.

Oh happy day, now I can't wait for it to arrive.

Bring on the thunderstorms!

On Saturday, 20 September 2014 19:54:13 UTC+3, WH3080 wrote:

...

[Vince Skahan]

On Tuesday, June 16, 2015 at 11:21:46 AM UTC-7, Robin wrote:

Thank your for the quick reply.

After a rush of blood, I ordered the MOD1016 annd then became worried that my better half might bury my remains under the patio for wasting money.

we'll certainly search for the body in case there is hardware we can use nearby :-)

That's not that much money, I was surprised to find it for $25 US.   I've wasted more than that on cases.
 
Found a few nice links and discussions at http://coffeewithrobots.com/detecting-lightning-with-a-raspberry-pi/ and http://www.instructables.com/id/Lightning-Detector-for-Raspberry-Pi-WeatherPi-Weat/?ALLSTEPS  and http://www.wxforum.net/index.php?PHPSESSID=dafc49bdad843a04ea499b8a03874518&topic=22428.50 (check out the last photo on the last page there).

There are google map driven sites that are interesting - looks like a story day in Italy today http://www.lightningmaps.org/blitzortung/europe/index.php?lang=en - fun stuff !

[WH3080]

Hi Matt,

I tried the new script and this error:

Jun 18 15:30:12 raspberrypi weewx[2500]: as3935: detected disturber - masking
Jun 18 15:30:12 raspberrypi weewx[2500]: as3935: callback failed: global name 's                                                       ensor' is not defined
Jun 18 15:30:13 raspberrypi weewx[2500]: as3935: detected disturber - masking
Jun 18 15:30:13 raspberrypi weewx[2500]: as3935: callback failed: global name 's                                                       ensor' is not defined
Jun 18 15:30:13 raspberrypi weewx[2500]: as3935: detected disturber - masking
Jun 18 15:30:13 raspberrypi weewx[2500]: as3935: callback failed: global name 's                                                       ensor' is not defined
Jun 18 15:30:13 raspberrypi weewx[2500]: as3935: detected disturber - masking
Jun 18 15:30:13 raspberrypi weewx[2500]: as3935: callback failed: global name 's                                                       ensor' is not defined
Jun 18 15:30:13 raspberrypi weewx[2500]: as3935: detected disturber - masking
Jun 18 15:30:13 raspberrypi weewx[2500]: as3935: callback failed: global name 's                                                       ensor' is not defined
Jun 18 15:30:13 raspberrypi weewx[2500]: restx: Twitter: service version is 0.8
Jun 18 15:30:13 raspberrypi weewx[2500]: restx: Twitter: units will be converted                                                        to METRICWX
Jun 18 15:30:13 raspberrypi weewx[2500]: restx: Twitter: binding is archive
Jun 18 15:30:13 raspberrypi weewx[2500]: restx: Twitter: Data will be tweeted fo                                                       r Arnimplatz - Berlin Prenzlauer Berg
Jun 18 15:30:13 raspberrypi weewx[2500]: engine: Starting up weewx version 3.1.0
Jun 18 15:30:14 raspberrypi weewx[2500]: as3935: detected disturber - masking
Jun 18 15:30:14 raspberrypi weewx[2500]: as3935: callback failed: global name 's                                                       ensor' is not defined
Jun 18 15:30:14 raspberrypi weewx[2500]: as3935: detected disturber - masking
Jun 18 15:30:14 raspberrypi weewx[2500]: as3935: callback failed: global name 's                                                       ensor' is not defined
Jun 18 15:30:14 raspberrypi weewx[2500]: fousb: synchronising to the weather sta                                                       tion (quality=1)
Jun 18 15:30:14 raspberrypi weewx[2500]: as3935: detected disturber - masking
Jun 18 15:30:14 raspberrypi weewx[2500]: as3935: callback failed: global name 's                                                       ensor' is not defined
Jun 18 15:30:14 raspberrypi weewx[2500]: as3935: detected disturber - masking
Jun 18 15:30:14 raspberrypi weewx[2500]: as3935: callback failed: global name 's                                                       ensor' is not defined
Jun 18 15:30:15 raspberrypi weewx[2500]: as3935: detected disturber - masking
Jun 18 15:30:15 raspberrypi weewx[2500]: as3935: callback failed: global name 's                                                       ensor' is not defined
Jun 18 15:30:15 raspberrypi weewx[2500]: as3935: detected disturber - masking
Jun 18 15:30:15 raspberrypi weewx[2500]: as3935: callback failed: global name 's                                                       ensor' is not defined
Jun 18 15:30:15 raspberrypi weewx[2500]: as3935: detected disturber - masking
Jun 18 15:30:15 raspberrypi weewx[2500]: as3935: callback failed: global name 's                                                       ensor' is not defined
Jun 18 15:30:15 raspberrypi weewx[2500]: as3935: detected disturber - masking
Jun 18 15:30:15 raspberrypi weewx[2500]: as3935: callback failed: global name 's                                                       ensor' is not defined
Jun 18 15:30:16 raspberrypi weewx[2500]: as3935: detected disturber - masking
Jun 18 15:30:16 raspberrypi weewx[2500]: as3935: callback failed: global name 's                                                       ensor' is not defined
Jun 18 15:30:16 raspberrypi weewx[2500]: as3935: detected disturber - masking
Jun 18 15:30:16 raspberrypi weewx[2500]: as3935: callback failed: global name 's                                                       ensor' is not defined
Jun 18 15:30:16 raspberrypi weewx[2500]: as3935: detected disturber - masking
Jun 18 15:30:16 raspberrypi weewx[2500]: as3935: callback failed: global name 's                                                       ensor' is not defined
Jun 18 15:30:16 raspberrypi weewx[2500]: as3935: detected disturber - masking
Jun 18 15:30:16 raspberrypi weewx[2500]: as3935: callback failed: global name 's                                                       ensor' is not defined
Jun 18 15:30:17 raspberrypi weewx[2500]: as3935: detected disturber - masking
Jun 18 15:30:17 raspberrypi weewx[2500]: as3935: callback failed: global name 's                                                       ensor' is not defined
Jun 18 15:30:18 raspberrypi weewx[2500]: as3935: detected disturber - masking
Jun 18 15:30:18 raspberrypi weewx[2500]: as3935: callback failed: global name 's                                                       ensor' is not defined
Jun 18 15:30:18 raspberrypi weewx[2500]: as3935: detected disturber - masking
Jun 18 15:30:18 raspberrypi weewx[2500]: as3935: callback failed: global name 's                                                       ensor' is not defined

What do I need to change?

Best,

WH3080

[mwall]

On Thursday, June 18, 2015 at 9:34:24 AM UTC-4, WH3080 wrote:

Hi Matt,

I tried the new script and this error:

Jun 18 15:30:12 raspberrypi weewx[2500]: as3935: detected disturber - masking
Jun 18 15:30:12 raspberrypi weewx[2500]: as3935: callback failed: global name 's                                                       ensor' is not defined

change line 161 from this:

                sensor.set_mask_disturber(True)

to this:

                self.sensor.set_mask_disturber(True)

change line 164 from this:

                distance = sensor.get_distance()

to this:

                distance = self.sensor.get_distance()

m

[WH3080]

Thanks Matt! That and another tiny correction in line 72 ('schema': 'user.as2935.schema' to 'schema': 'user.as3935.schema') did it. Now it's up and running :-) I'll integrate it into tweets first and will start experimenting with graphic depiction soon. Best, Daniel (WH3080)

[WH3080]

Hi Matt,

AS3935 sends data to twitter now.

However, there is a datatype mismatch in syslog showing. I guess since there is no group for lightning strikes yet, it may have to be created (by me)?

Jun 18 16:49:18 raspberrypi weewx[2251]: as3935: strike at 1 km
Jun 18 16:49:18 raspberrypi weewx[2251]: manager: unable to add record 2015-06-18 16:49:18 CEST (1434638958) to database 'archive/lightning.sdb': datatype mismatch
Jun 18 16:49:30 raspberrypi weewx[2251]: fousb: unstable read: blocks differ for ptr 0x009e60
Jun 18 16:50:26 raspberrypi weewx[2251]: as3935: strike at 1 km
Jun 18 16:50:26 raspberrypi weewx[2251]: manager: unable to add record 2015-06-18 16:50:26 CEST (1434639026) to database 'archive/lightning.sdb': datatype mismatch
Jun 18 16:50:41 raspberrypi weewx[2251]: fousb: unstable read: blocks differ for ptr 0x009e60
Jun 18 16:50:47 raspberrypi weewx[2251]: as3935: strike at 1 km
Jun 18 16:50:47 raspberrypi weewx[2251]: manager: unable to add record 2015-06-18 16:50:47 CEST (1434639047) to database 'archive/lightning.sdb': datatype mismatch
Jun 18 16:50:57 raspberrypi weewx[2251]: as3935: strike at 1 km
Jun 18 16:50:57 raspberrypi weewx[2251]: manager: unable to add record 2015-06-18 16:50:57 CEST (1434639057) to database 'archive/lightning.sdb': datatype mismatch
Jun 18 16:51:35 raspberrypi weewx[2251]: as3935: strike at 1 km

Best,

Daniel

On Thursday, June 18, 2015 at 3:39:52 PM UTC+2, mwall wrote:

[mwall]

On Thursday, June 18, 2015 at 11:04:52 AM UTC-4, WH3080 wrote:

Hi Matt,

AS3935 sends data to twitter now.

However, there is a datatype mismatch in syslog showing. I guess since there is no group for lightning strikes yet, it may have to be created (by me)?

this is a database type issue. try changing this:

                strike_ts = time.time()
                distance = self.sensor.get_distance()

to this:

                strike_ts = int(time.time())
                distance = float(self.sensor.get_distance())

to get the right units for lightning counts and distances, put this in your user/extensions.py file:

weewx.units.USUnits['group_distance'] = 'mile'
weewx.units.MetricUnits['group_distance'] = 'kilometer'
weewx.units.MetricWXUnits['group_distance'] = 'kilometer'
weewx.units.obs_group_dict['lightning_strikes'] = 'group_count'
weewx.units.obs_group_dict['avg_distance'] = 'group_distance'

(you might not need the first three lines - check your weewx/units.py file to see whether the 'group_distance' already exists)

m

[WH3080]

Hi Matt,

I edited as3935.py accordingly. Lightning reporting on twitter and storing to the database works now.

Jun 18 18:26:09 raspberrypi weewx[2777]: engine: Starting main packet loop.
Jun 18 18:26:09 raspberrypi weewx[2777]: restx: EmonCMS: Published record 2015-06-18 18:26:00 CEST (1434644760)
Jun 18 18:26:09 raspberrypi weewx[2777]: restx: CWOP: Published record 2015-06-18 18:26:00 CEST (1434644760)
Jun 18 18:26:09 raspberrypi weewx[2777]: restx: WeatherCloud: Published record 2015-06-18 18:26:00 CEST (1434644760)
Jun 18 18:26:09 raspberrypi weewx[2777]: restx: Wunderground-PWS: Published record 2015-06-18 18:26:00 CEST (1434644760)
Jun 18 18:26:10 raspberrypi weewx[2777]: fousb: station status {'unknown': 0, 'lost_connection': 0, 'rain_overflow': 0} (0)
Jun 18 18:26:10 raspberrypi weewx[2777]: restx: Twitter: Published record 2015-06-18 18:26:00 CEST (1434644760)
Jun 18 18:26:23 raspberrypi weewx[2777]: as3935: strike at 1.0 km
Jun 18 18:26:23 raspberrypi weewx[2777]: manager: added record 2015-06-18 18:26:23 CEST (1434644783) to database 'archive/lightning.sdb'
Jun 18 18:26:37 raspberrypi weewx[2777]: restx: PWSWeather: Published record 2015-06-18 18:16:00 CEST (1434644160)
Jun 18 18:26:38 raspberrypi weewx[2777]: restx: PWSWeather: Published record 2015-06-18 18:21:00 CEST (1434644460)
Jun 18 18:26:38 raspberrypi weewx[2777]: restx: PWSWeather: Published record 2015-06-18 18:26:00 CEST (1434644760)
Jun 18 18:31:11 raspberrypi weewx[2777]: manager: added record 2015-06-18 18:31:12 CEST (1434645072) to database 'archive/cmon.sdb'
Jun 18 18:31:12 raspberrypi weewx[2777]: manager: added record 2015-06-18 18:31:12 CEST (1434645072) to daily summary in 'archive/cmon.sdb'
Jun 18 18:31:15 raspberrypi weewx[2777]: manager: added record 2015-06-18 18:30:00 CEST (1434645000) to database 'archive/weewx.sdb'
Jun 18 18:31:15 raspberrypi weewx[2777]: manager: added record 2015-06-18 18:30:00 CEST (1434645000) to daily summary in 'archive/weewx.sdb'
Jun 18 18:31:15 raspberrypi weewx[2777]: manager: added record 2015-06-18 18:30:00 CEST (1434645000) to database 'archive/weewxwd.sdb'
Jun 18 18:31:15 raspberrypi weewx[2777]: manager: added record 2015-06-18 18:30:00 CEST (1434645000) to daily summary in 'archive/weewxwd.sdb'
Jun 18 18:31:15 raspberrypi weewx[2777]: restx: EmonCMS: Published record 2015-06-18 18:30:00 CEST (1434645000)
Jun 18 18:31:15 raspberrypi weewx[2777]: restx: Wunderground-PWS: Published record 2015-06-18 18:30:00 CEST (1434645000)
Jun 18 18:31:16 raspberrypi weewx[2777]: restx: Twitter: Published record 2015-06-18 18:30:00 CEST (1434645000)

Adding these two lines to extensions.py, does not, so I removed them.

eewx.units.obs_group_dict['lightning_strikes'] = 'group_count'
weewx.units.obs_group_dict['avg_distance'] = 'group_distance'

 File "/home/weewx/bin/weewxd", line 14, in <module>
    import user.extensions       #@UnusedImport
  File "/home/weewx/bin/user/extensions.py", line 22, in <module>
    weewx.units.obs_group_dict['lightning_strikes'] = 'group_count'
NameError: name 'weewx' is not defined
 failed!

Thanks,

Daniel

[mwall]

On Thursday, June 18, 2015 at 12:38:50 PM UTC-4, WH3080 wrote:

I edited as3935.py accordingly. Lightning reporting on twitter and storing to the database works now.

excellent.  thank you for testing.

 

Adding these two lines to extensions.py, does not, so I removed them.
eewx.units.obs_group_dict['lightning_strikes'] = 'group_count'
weewx.units.obs_group_dict['avg_distance'] = 'group_distance'

i forgot to mention the import:

import weewx.units

[WH3080]

Hi Matt, testing is the least I can do, now that you're putting so much time into programming the driver :-) Once this setup is fully operational I plan to compare the results with this more sophisticated device (http://www.blitzortung.org/Documents/TOA_Blitzortung_RED.pdf) and also an indoor vs. outdoor version. Best, Daniel

[Erwin Heger]

Hi Daniel, hi Matt.

First: many thanks for this piece of work, since i own an AS3935 since two months now, and only got it to work writing the data into a simple textfile on a RPi.
Living in the south of Germany near to the Alps, we have lots of lightning events during June and July.
Thanks to your code i think, i will be able to integrate it into weewx.

I will give Feedback, as soon as i tried it.

With best regards,

Erwin

[WH3080]

Hi Matt,

I did some more testing.

1. The driver creates and writes to the lightning database and records the distance variable. I assume your approach was recording date and time of each strike and then have a a skin template do the calculation (i.e. strikes over time) in a graph. In other words: each distance reading is one strike and displaying the distance over time equals strikes over time.

2. Amending extensions with these lines still causes the system to fail. Tweitter and WeatherCloud "complain" about existing keys and groups, although none of them are present in my user.py file.

import weewx.units
weewx.units.obs_group_dict['lightning_strikes'] = 'group_count'
weewx.units.obs_group_dict['avg_distance'] = 'group_distance'

Here is the error message in syslog.

Jun 19 21:08:42 raspberrypi weewx[2252]: restx: WeatherCloud: service version is 0.7
Jun 19 21:08:42 raspberrypi weewx[2252]: restx: WeatherCloud: Data will be uploaded for             id=837ebd54b0e3f99c
Jun 19 21:08:45 raspberrypi weewx[2252]: restx: Twitter: service version is 0.8
Jun 19 21:08:45 raspberrypi weewx[2252]: restx: Twitter: units will be converted to MET            RICWX
Jun 19 21:08:45 raspberrypi weewx[2252]: restx: Twitter: binding is archive
Jun 19 21:08:45 raspberrypi weewx[2252]: restx: Twitter: Data will be tweeted for Arnim            platz - Berlin Prenzlauer Berg
Jun 19 21:08:45 raspberrypi weewx[2252]: engine: Starting up weewx version 3.1.0
Jun 19 21:08:46 raspberrypi weewx[2252]: fousb: synchronising to the weather station (q            uality=1)
Jun 19 21:08:49 raspberrypi weewx[2252]: as3935: noise level too high - adjusting
Jun 19 21:09:53 raspberrypi weewx[2252]: fousb: unstable read: blocks differ for ptr 0x            00b8e0
Jun 19 21:11:00 raspberrypi weewx[2252]: fousb: changing data format from 1080 to 3080
Jun 19 21:11:03 raspberrypi weewx[2252]: manager: added record 2015-06-19 21:11:00 CEST             (1434741060) to database 'archive/weewx.sdb'
Jun 19 21:11:03 raspberrypi weewx[2252]: manager: added record 2015-06-19 21:11:00 CEST             (1434741060) to daily summary in 'archive/weewx.sdb'
Jun 19 21:11:03 raspberrypi weewx[2252]: manager: added record 2015-06-19 21:11:00 CEST             (1434741060) to database 'archive/weewxwd.sdb'
Jun 19 21:11:03 raspberrypi weewx[2252]: manager: added record 2015-06-19 21:11:00 CEST             (1434741060) to daily summary in 'archive/weewxwd.sdb'
Jun 19 21:11:04 raspberrypi weewx[2252]: forecast: ZambrettiThread: Zambretti: generate            d 1 forecast record
Jun 19 21:11:04 raspberrypi weewx[2252]: engine: Starting main packet loop.
Jun 19 21:11:04 raspberrypi weewx[2252]: restx: Twitter: Unexpected exception of type <            type 'exceptions.KeyError'>
Jun 19 21:11:04 raspberrypi weewx[2252]: restx: Twitter: Thread exiting. Reason: 'group            _distance'
Jun 19 21:11:04 raspberrypi weewx[2252]: restx: WeatherCloud: Unexpected exception of t            ype <type 'exceptions.KeyError'>
Jun 19 21:11:04 raspberrypi weewx[2252]: restx: WeatherCloud: Thread exiting. Reason: '            group_distance'
Jun 19 21:11:04 raspberrypi weewx[2252]: restx: CWOP: Published record 2015-06-19 21:11            :00 CEST (1434741060)
Jun 19 21:11:04 raspberrypi weewx[2252]: forecast: ZambrettiThread: Zambretti: saved 1             forecast records
Jun 19 21:11:04 raspberrypi weewx[2252]: forecast: ZambrettiThread: Zambretti: deleted             forecasts prior to 1434136264
Jun 19 21:11:04 raspberrypi weewx[2252]: restx: PWSWeather: Published record 2015-06-19             21:11:00 CEST (1434741060)
Jun 19 21:11:04 raspberrypi weewx[2252]: restx: Wunderground-PWS: Published record 2015            -06-19 21:11:00 CEST (1434741060)
Jun 19 21:11:04 raspberrypi weewx[2252]: fousb: station status {'unknown': 0, 'lost_con            nection': 0, 'rain_overflow': 0} (0)

Thanks for your time Matt!

Best,

Daniel

[mwall]

On Friday, June 19, 2015 at 3:20:19 PM UTC-4, WH3080 wrote:

1. The driver creates and writes to the lightning database and records the distance variable. I assume your approach was recording date and time of each strike and then have a a skin template do the calculation (i.e. strikes over time) in a graph. In other words: each distance reading is one strike and displaying the distance over time equals strikes over time.

my intent is that the database stores the minimal amount of information required to capture all of the lightning data.  if we do that, then any program can use the data for analysis, presentation, whatever.

the schema is simply dateTime, usUnits, distance.  so each record is the time of a lightning strike and the distance to that strike.  usUnits is METRIC by default, since the sensor reports kilometers.

the weewx stats and plotting systems require a database with dateTime, usUnits, and arbitrary number of additional numeric fields.  so theoretically you can extract data from the lightning database and display it in your web pages, plots, and other reports, simply by using the 'dot code' that is explained in the weewx customization guide.  just specify the lightning database as the data_binding.

this is a different use of the lightning data than augmenting archive records.  there the service is doing some data aggregation - it reports the number of strikes in the last archive interval and the average distance for those strikes.  of course you can use those data in your reports and plots, but having a separate lightning database ensures that you have *all* the data, not just the per-interval summaries.

2. Amending extensions with these lines still causes the system to fail. Tweitter and WeatherCloud "complain" about existing keys and groups, although none of them are present in my user.py file.

import weewx.units
weewx.units.obs_group_dict['lightning_strikes'] = 'group_count'
weewx.units.obs_group_dict['avg_distance'] = 'group_distance'

you need to add the group_distance to your units.  in user/extensions.py do this:

import weewx.units

weewx.units.USUnits['group_distance'] = 'mile'
weewx.units.MetricUnits['group_distance'] = 'kilometer'
weewx.units.MetricWXUnits['group_distance'] = 'kilometer'

weewx.units.obs_group_dict['lightning_strikes'] = 'group_count'
weewx.units.obs_group_dict['avg_distance'] = 'group_distance'

making the unit system easier to extend is on the roadmap, but this should get things working for now.

i have updated the as3935 extension to 0.2 to include the changes mentioned earlier in this thread.

https://github.com/weewx/weewx/wiki/as3935

m

[WH3080]

Hi Matt,

many thanks for providing more details about your intent. I learn from you every time you post something :-)  My previous comments were not meant as a complaint, but merely a report: for some reason my system (only) works without editing extenisons.py.

After some more exprimenting and reading about the AS3935 chip I found a way to read the (unitless) lightning energy values. The result of the energy calculation is stored in the registers REG0x06[4:0], REG0x05[7:0], and REG0x04[7:0]. The manufacturer describes their content as Energy of the Single Lightning LSBYTE, Energy of the Single Lightning MSBYTE, Energy of the Single Lightning MMSBYTE, respectively. Their content is just a pure number and has no physical meaning. Nonetheless, I decided that it might be intersting to record and store them. They can be correlated with the distance and both plotted over time.

I don't know if I have done it correctly, but the modfied as3935.py service added an additional "energy" column, collects and stores values in it. I attach the modified files for anybody who wants to expriment with these registers or improve their readout. The modified scripts read REG0x04[7:0], i.e. Energy of the Single Lightning LSBYTE.

Best,

Daniel

[Steven Meltz]

Hello: I just received my AS3935 and am going to give it a go. A few newbie questions:

1. In the Wiki instructions, it states: "The default configuration will add the fields lightning_strikes and avg_distance to each archive record. To save these in the weewx database (so that they can be used in reports and plots), extend the database schema as explained in the weewx customization guide. You must add two columns, lightning_strikes and avg_distance."

Is this done by editing /bin/schemas/wview.py    ?

2. The data binding ("data_binding - Specify a data binding to save lightning data to a separate lightning database. For example,

[AS3935]
    data_binding = lightning_sqlite")is done in weewx.conf?


Thanks, Steve

[mwall]

On Sunday, July 5, 2015 at 12:18:34 AM UTC-4, Steven Meltz wrote:

Hello: I just received my AS3935 and am going to give it a go. A few newbie questions:

1. In the Wiki instructions, it states: "The default configuration will add the fields lightning_strikes and avg_distance to each archive record. To save these in the weewx database (so that they can be used in reports and plots), extend the database schema as explained in the weewx customization guide. You must add two columns, lightning_strikes and avg_distance."

Is this done by editing /bin/schemas/wview.py    ?

make changes in the user directory so that your changes are retained when you upgrade.

1) make a copy of the wview schema in the user directory

cp bin/schema/wview.py user/customschema.py

2) modify customschema.py

          ('inTempBatteryStatus',  'REAL')]

becomes:

          ('inTempBatteryStatus',  'REAL')
          ('lightning_strikes', 'REAL'),
          ('avg_distance', 'REAL')]

3) in weewx.conf, tell weewx to use the custom schema

[DataBindings]
    [[wx_binding]]
        schema = user.customschema.schema
 
note that the schema is used only when the database is created, i.e., the first time you run weewx.  if you want to add columns to an existing database, see the customization guide.

2. The data binding ("data_binding - Specify a data binding to save lightning data to a separate lightning database. For example,

[AS3935]
    data_binding = lightning_sqlite")is done in weewx.conf?

correct

m

[Steven Meltz]

Thanks Matt:

I will be doing the wiring later today, and hope to have it working by tomorrow.

Steve

[Steven Meltz]

Matt: I (finally) was able to get the extension installed, but immediately started getting errors.Attached is my log, I have some questions:

1. I don't have the AS3935 hooked to the Pi yet, so I assume that would throw off errors?

2. As per your instructions, I now have customschema.py (which is a copy of wview.py) under /user   
    I edited customschema.py by adding the lines for lightning_strikes and avg_distance. By doing that, will it add the columns of the same names to (a newly generated) weewx.sdb? If that is the case,
    do I then NOT add:     [AS3935]
                                          data_binding = lightning_sqlite)   and furthur references to binding?

Steve

[mwall]

On Sunday, July 5, 2015 at 10:29:07 PM UTC-4, Steven Meltz wrote:

1. I don't have the AS3935 hooked to the Pi yet, so I assume that would throw off errors?

the error describes the problem:

ImportError: No module named RPi_AS3935

you have not installed the RPi_AS3935 python module

 

2. As per your instructions, I now have customschema.py (which is a copy of wview.py) under /user   
    I edited customschema.py by adding the lines for lightning_strikes and avg_distance. By doing that, will it add the columns of the same names to (a newly generated) weewx.sdb? If that is the case,
    do I then NOT add:     [AS3935]
                                          data_binding = lightning_sqlite)   and furthur references to binding?

from the wiki:

"The service augments the standard weewx archive record and optionally saves per-strike data to a separate lightning strike database."

change the schema to save the two additional fields.  specify a data_binding to save data to a separate database.

m

[Steven Meltz]

I wired the breakout board, and installed the RPi_AS3935 module. This is the log (different errors than before):

Jul  6 20:19:09 raspi2 weewx[2867]: engine: Initializing weewx version 3.1.0

Jul  6 20:19:09 raspi2 weewx[2867]: engine: Using Python 2.7.3 (default, Mar 18 2014, 05:13:23) #012[GCC 4.6.3]

Jul  6 20:19:09 raspi2 weewx[2867]: engine: pid file is /var/run/weewx.pid

Jul  6 20:19:09 raspi2 weewx[2869]: engine: Using configuration file /home/weewx/weewx.conf

Jul  6 20:19:09 raspi2 weewx[2869]: engine: Initializing engine

Jul  6 20:19:09 raspi2 weewx[2869]: engine: Loading station type Ultimeter (weewx.drivers.ultimeter)

Jul  6 20:19:09 raspi2 weewx[2869]: ultimeter: driver version is 0.13

Jul  6 20:19:09 raspi2 weewx[2869]: ultimeter: using serial port /dev/ttyUSB0

Jul  6 20:19:09 raspi2 weewx[2869]: ultimeter: open serial port /dev/ttyUSB0

Jul  6 20:19:09 raspi2 weewx[2869]: engine: Loading service weewx.engine.StdTimeSynch

Jul  6 20:19:09 raspi2 weewx[2869]: engine: Finished loading service weewx.engine.StdTimeSynch

Jul  6 20:19:09 raspi2 weewx[2869]: engine: Loading service weewx.engine.StdConvert

Jul  6 20:19:09 raspi2 weewx[2869]: engine: StdConvert target unit is 0x1

Jul  6 20:19:09 raspi2 weewx[2869]: engine: Finished loading service weewx.engine.StdConvert

Jul  6 20:19:09 raspi2 weewx[2869]: engine: Loading service weewx.engine.StdCalibrate

Jul  6 20:19:09 raspi2 weewx[2869]: engine: Finished loading service weewx.engine.StdCalibrate

Jul  6 20:19:09 raspi2 weewx[2869]: engine: Loading service weewx.engine.StdQC

Jul  6 20:19:09 raspi2 weewx[2869]: engine: Finished loading service weewx.engine.StdQC

Jul  6 20:19:09 raspi2 weewx[2869]: engine: Loading service weewx.wxservices.StdWXCalculate

Jul  6 20:19:09 raspi2 weewx[2869]: engine: Finished loading service weewx.wxservices.StdWXCalculate

Jul  6 20:19:09 raspi2 weewx[2869]: engine: Loading service user.as3935.AS3935

Jul  6 20:19:09 raspi2 weewx[2869]: as3935: service version is 0.2

Jul  6 20:19:09 raspi2 weewx[2869]: ultimeter: close serial port /dev/ttyUSB0

Jul  6 20:19:10 raspi2 weewx[2869]: engine: Caught unrecoverable exception in engine:

Jul  6 20:19:10 raspi2 weewx[2869]:     ****  [Errno 5] Input/output error

Jul  6 20:19:10 raspi2 weewx[2869]:     ****  Traceback (most recent call last):

Jul  6 20:19:10 raspi2 weewx[2869]:     ****    File "/home/weewx/bin/weewx/engine.py", line 831, in main

Jul  6 20:19:10 raspi2 weewx[2869]:     ****      engine = EngineClass(config_dict)

Jul  6 20:19:10 raspi2 weewx[2869]:     ****    File "/home/weewx/bin/weewx/engine.py", line 77, in __init__

Jul  6 20:19:10 raspi2 weewx[2869]:     ****      self.loadServices(config_dict)

Jul  6 20:19:10 raspi2 weewx[2869]:     ****    File "/home/weewx/bin/weewx/engine.py", line 141, in loadServices

Jul  6 20:19:10 raspi2 weewx[2869]:     ****      self.service_obj.append(weeutil.weeutil._get_object(svc)(self, confi$

Jul  6 20:19:10 raspi2 weewx[2869]:     ****      self.sensor.set_indoors(indoors)

Jul  6 20:19:10 raspi2 weewx[2869]:     ****    File "/usr/local/lib/python2.7/dist-packages/RPi_AS3935/RPi_AS3935.py"$

Jul  6 20:19:10 raspi2 weewx[2869]:     ****      self.read_data()

Jul  6 20:19:10 raspi2 weewx[2869]:     ****    File "/usr/local/lib/python2.7/dist-packages/RPi_AS3935/RPi_AS3935.py"$

Jul  6 20:19:10 raspi2 weewx[2869]:     ****      self.registers = self.i2cbus.read_i2c_block_data(self.address, 0x00)

Jul  6 20:19:10 raspi2 weewx[2869]:     ****  IOError: [Errno 5] Input/output error

Jul  6 20:19:10 raspi2 weewx[2869]:     ****  Exiting.

Should I post my weewx.conf?

Thanks, Steve

[Robin]

Hi,

1. Stopped the Pi with halt
   
2. Removed all power
   
3. Plugged in the AS3935
   
4. Powered up the Pi
   
5. Weewx worked fine after restart
6. Downloaded and installed  weewx-as3935-0.2.tgz
   
7. Restarted weewx
8. ooops!

Jul 22 16:44:22 PWS weewx[2206]:     ****    File "/usr/share/weewx/weewx/engine.py", line 75, in __init__

Jul 22 16:44:22 PWS weewx[2206]:     ****      self.loadServices(config_dict)

Jul 22 16:44:22 PWS weewx[2206]:     ****    File "/usr/share/weewx/weewx/engine.py", line 136, in loadServices

Jul 22 16:44:22 PWS weewx[2206]:     ****      self.service_obj.append(weeutil.weeutil._get_object(svc)(self, config_dict))

Jul 22 16:44:22 PWS weewx[2206]:     ****    File "/usr/share/weewx/weeutil/weeutil.py", line 944, in _get_object

Jul 22 16:44:22 PWS weewx[2206]:     ****      mod = __import__(module)

Jul 22 16:44:22 PWS weewx[2206]:     ****    File "/usr/share/weewx/user/as3935.py", line 52, in <module>

Jul 22 16:44:22 PWS weewx[2206]:     ****      from RPi_AS3935 import RPi_AS3935

Jul 22 16:44:22 PWS weewx[2206]:     ****  ImportError: No module named RPi_AS3935

Jul 22 16:44:22 PWS weewx[2206]:     ****  Exiting.

What have I missed? 

[Steve M.]

Hi Robin: welcome to my world! I too had the same error. I then went here:  https://github.com/pcfens/RaspberryPi-AS3935   and downloaded the file and after much trial and error, got rid of the module not found error and replaced with the new one I posted.

So far, no one has responded to my inquires, but maybe between the two of us we can work it out.

Steve

[Robin]

Steve,

I GOT IT RUNNING!!!!!

This is what I did. Back to basics and start again from the begining:

1. followed instructions EXACTLY at http://www.raspberrypi-spy.co.uk/2014/11/enabling-the-i2c-interface-on-the-raspberry-pi/ to make sure i2c was enabled and smbus installed
2. followed http://skpang.co.uk/blog/archives/575 to download i2c tools and check i2c was working ok
3. wget https://github.com/pcfens/RaspberryPi-AS3935/blob/master/RPi_AS3935/RPi_AS3935.py
4. pip install RPi_AS3935
5. wget http://lancet.mit.edu/mwall/projects/weather/releases/weewx-as3935-0.2.tgz
6. wee_extension --install weewx-as3935-0.2.tgz
7. Stop weewx
8. Cross fingers
9. Start weewx

That's it

GOOD LUCK

Robin

[WH3080]

Dear Robin, Steve and all other lightning enthusiasts,

since I am the person who started the AS3935 lighting thread and asked Matt and Tom to help us integrate it into weewx, I am somewhat surprised about the harsh comments and demanding language regarding bugs that certainly still exist - like in every experimental system. Tom clearly states

After all, most if not all of us have daytime jobs and so do Matt and Tom. They and many others in these forums dedicate a substantial amount of their spare time to weewx and assisting newbies like myself.

First and foremost WE SHOULD BE GRATEFUL for what they do and not impatient, if something does not work right away or is troubled by bugs. These forums are not some customer service line for a commercial product.

Back to AS3935: Matt's weewx service and also Phil Fenstermacher's library (that Matt's service is based on) may contain previously undiscovered bugs. I have done extensive testing with two independent pi's now.

Here is what I found:

1. The AS3935 has probably several firmware bugs. This has been discovered by the folks of the lightningmaps.org  network. They hooked up the AS3935 to their "RED controler" and published large comparative data series demonstrating this issue. See respective discussions on wxforum.net and on youtube. In case you didn't know: the AS3935 can be used within the lightningmaps.org network and controller software. They have written their own drivers and a GUI to tweak various parameters of this very capable sensor. Setting it to outdoors, even when using it indoors works much better. Apparently the two were confused by AMS? Of course AMS "was not immediately available for comment" :-) This can be easily accomplished with Matt's weewx service and correct weewx.conf settings.

2. The AS3935 github library may have a bug and is currently missing the lightning energy calculation. A Japanese fellow has provided an updated and corrected AS3935 library version, which I have tweaked some more. It works very stable on my system. In case you want to look at it: http://www.ishikawa-lab.com/RasPi_lightning.html

3. Installing Matt's weewx service works if all requirements are met, i.e. sensor hooked up, I2C activated, AS3935 library correctly installed, correct weewx.conf and adequate power supply etc. Please don't complain about these things, which BTW are also mentioned on the github pages and by the AS3935 board suppliers. I2C activation is well described here: https://learn.adafruit.com/adafruits-raspberry-pi-lesson-4-gpio-setup/configuring-i2c

4. However, after running weewx with the AS3935 this event keeps crashing weewx:

Jul 21 20:34:13 raspi weewx[16186]: engine: Caught unrecoverable exception in engine:

Jul 21 20:34:13 raspi weewx[16186]:     ****  Conflicting edge detection already enabled for this GPIO channel

Jul 21 20:34:13 raspi weewx[16186]:     ****  Traceback (most recent call last):

Jul 21 20:34:13 raspi weewx[16186]:     ****    File "/home/weewx/bin/weewx/engine.py", line 831, in main

Jul 21 20:34:13 raspi weewx[16186]:     ****      engine = EngineClass(config_dict)

Jul 21 20:34:13 raspi weewx[16186]:     ****    File "/home/weewx/bin/weewx/engine.py", line 77, in __init__

Jul 21 20:34:13 raspi weewx[16186]:     ****      self.loadServices(config_dict)

Jul 21 20:34:13 raspi weewx[16186]:     ****    File "/home/weewx/bin/weewx/engine.py", line 141, in loadServices

Jul 21 20:34:13 raspi weewx[16186]:     ****      self.service_obj.append(weeutil.weeutil._get_object(svc)(self, config_dict))

Jul 21 20:34:13 raspi weewx[16186]:     ****    File "/home/weewx/bin/user/as3935.py", line 124, in __init__

Jul 21 20:34:13 raspi weewx[16186]:     ****      GPIO.add_event_detect(pin, GPIO.RISING, callback=self.handle_interrupt)

Jul 21 20:34:13 raspi weewx[16186]:     ****  RuntimeError: Conflicting edge detection already enabled for this GPIO channel

Jul 21 20:34:13 raspi weewx[16186]:     ****  Exiting.

It looks like when lightning strikes and the weewx service reads the GPIO channel this causes some kind of conflict ("Conflicting edge detection already enabled for this GPIO channel"). First I though this is related to other GPIO activity on my pi, but even on a pi without any other GPIO activity it keeps happening.

I am by no means a python programmer or computer scientist, although I am learning things and have written tiny pieces of code following instruction from MIT professors Grimson and Guttag: https://www.youtube.com/watch?v=k6U-i4gXkLM

Perhaps if Matt ore someone else who is python and pi savvy could look into this? With the improved Japanese library and some more adjustments to Matt's AS39335 weewx service we will eventually solve this problem.

Anyway, I am excited how far we got already!

Best,

WH3080

[Robin]

Dear WH3080,

I didn't think that any of my comments were harsh. HOWEVER if I have offended anybody or I have been too impatient then I apologise unreservedly. The help that I have received (and continue to receive) has aided my learning and has all been acknowledged by me.

You will notice from my previous comment that I now have the AS3935 working. The red text was meant to convey my excitement not frustration. If anything my frustration is wanting to be able to run with Linux when I am only capable of a Linux crawl. 

My only thought at this time, is now that I do have it working, I have probably ensured that this part of Greece will have no thunderstorms for a hundred years!!!

I will follow up on the links provided by you, I clearly have a lot of reading and learning to do.

Regards

Robin

[WH3080]

Hi Robin,

since the disturber suppression of the chip / board is not perfect you may be able to induce some (false) lightning readings with a modern lighter. This will - if falsely recognized as lightning - trigger the GPIO routine, which may crash WeeWx as seen and reported here in the forum. I believe if we collect more information and receive support by the active programmers, this can be eventually fixed.

Best,

WH3080

[Robin]

One question before I try to crash WeeWx.

Is it simply a case of restarting WeeWx?

Robin

[Steve M.]

WH3080:

I, too, would like to apologize if I seemed too demanding. That was never my intent; as a NOOB I was excited with trying something new. I have and am still learning from this group, and I thank everyone for their assistance. I have always had problems with trying to learn a foreign language, and I guess programming falls into that category.

That being said, I thank you for your very detailed post for Robin, and I will be investigating those links. I suppose it is possible that my AS3935 is working, as I do have the GPIO error. The error terminates Weewx immediately, so no files are generated. I goggled the full error message, and found a number of people who had the same message for different programs. As none of them related directly to Weewx, so I am not sure if the "fixes" would be applicable.

Steve

[mwall]

On Thursday, July 23, 2015 at 7:26:42 AM UTC-4, WH3080 wrote:

4. However, after running weewx with the AS3935 this event keeps crashing weewx:

Jul 21 20:34:13 raspi weewx[16186]: engine: Caught unrecoverable exception in engine:

Jul 21 20:34:13 raspi weewx[16186]:     ****  Conflicting edge detection already enabled for this GPIO channel

when does this happen?  does it happen every time you start weewx? only after you have already run weewx, stopped weewx, then tried to start again?

m

[Steven Meltz]

Hi Matthew:  In my case, it happens every time I start Weewx, even from a system reboot. My error message is exactly the same as WH3080's. After reading up on the chip itself, mention was made that it could be strongly interfered with by a monitor, so I shut the Pi's monitor off and ran it headless from another location: same result.

Steve

[WH3080]

Hi guys,

if I unplug the pi and boot the system from scratch it does run for a while (hours, sometimes days). Then all of a sudden this GPIO problem occurs and weewx crashes. I believe it is related to sensing the interrupt on the GPIO. I wonder if any other linux process may access this GPIO, but afaik it is a freely assignable one?!

If I run Phil Fenstermacher's demo.py or the Japanese fellows' demo program and weewx without Matt's driver, both run well. In other words running a sensor readout program and weewx independently does not cause a crash of either application.

Also, removing other applications i.e. svxlink (www.svxlink.org )(which accesses other GPIOs) has no impact. Thus, I believe it must be somehow related to the as3935 weewx service and it's reading the GPIO.

I wish I could provide more insight...

Thank you Matt for working on it again.

Best,

WH3080

[mwall]

On Friday, July 24, 2015 at 4:35:01 PM UTC-4, WH3080 wrote:

if I unplug the pi and boot the system from scratch it does run for a while (hours, sometimes days). Then all of a sudden this GPIO problem occurs and weewx crashes. I believe it is related to sensing the interrupt on the GPIO. I wonder if any other linux process may access this GPIO, but afaik it is a freely assignable one?!

this does not make sense.  the stack trace you posted can only happen when weewx starts up.

please post the stack trace from when weewx 'crashes' after running for awhile.

m 

[Robin]

Greetings to all,

I have had WeeWX and the AS3935 running for a couple of days, it has not crashed (yet). I have also detected nothing except noise.

If you want to see how things are going, my TEST PAGE which contains uptime and some system information.

Regards

Robin

On Saturday, 20 September 2014 19:54:13 UTC+3, WH3080 wrote:

Hi,

I purchased and installed the MOD1016 lightning sensor module from embedded adventures (http://www.embeddedadventures.com/datasheets/MOD-1016_hw_v4_doc_v2.pdf).

The module is based on the AS3935, a programmable fully integrated Lightning Sensor IC that detects the presence and approach of potentially hazardous lightning activity in the vicinity and provides an estimation on the distance to the head of the storm. The embedded lightning algorithm checks the incoming signal pattern to reject the potential man-made disturbers (http://media.digikey.com/pdf/Data%20Sheets/Austriamicrosystems%20PDFs/AS3935.pdf).

I hooked the board up to my Raspberry Pi B+ through I2C. My Raspberry is generally running headless, i.e. without a monitor or keyboard, except for maintenance. Phil Fenstermacher published a python library (https://github.com/pcfens/RaspberryPi-AS3935), which I used for the installation. The demo.py script is now running and actually detecting lighning (which I verified with www.lightningmaps.org). 

The installation files are located in /home/pi/RaspberryPi-AS3935/

The demo script (below) is printing the results to the screen. I would of course like to "reroute" this output into weewx and show it on exfoliation. I searched the internet for an adaptable python script to accomplish that goal, but failed. My own python knowledge is close to zero.

Could you please help me to integrate the sensor output into weewex with exfoliation?

Minimal goal:

Create an "automatic start script" that loads demo.py at the raspberry startup automatically (like weewx). Print the output into a file (txt or html) located in the the exfoliation folder containing all FTP upload data, so it's automatically uploaded with all the orher exfoliation files.

Maximum goal:

True integration into weewx and exfoliation. Use the distance coding (0 - 40 km) to create "perimeter" circles on a Google map within exfoliation, load a "red alam banner" to display within exfoliation and have speex exclaim the detected ligthning and distance on the homepage of the exfoliation skin.

I'm sorry to bother all of you with this probably very basic stuff, but lightning detection is really exciting :-)

Thanks,

WH3080

---

This is the current demo.py code from Phil Fenstermacher:

#!/usr/bin/env python
	from RPi_AS3935 import RPi_AS3935
	import RPi.GPIO as GPIO
	import time
	from datetime import datetime
	GPIO.setmode(GPIO.BCM)
	# Rev. 1 Raspberry Pis should leave bus set at 0, while rev. 2 Pis should set
	# bus equal to 1. The address should be changed to match the address of the
	# sensor. (Common implementations are in README.md)
	sensor = RPi_AS3935(address=0x00, bus=0)
	sensor.calibrate(tun_cap=0x0F)
	sensor.set_indoors(True)
	sensor.set_noise_floor(0)
	def handle_interrupt(channel):
	time.sleep(0.003)
	global sensor
	reason = sensor.get_interrupt()
	if reason == 0x01:
	print "Noise level too high - adjusting"
	sensor.raise_noise_floor()
	elif reason == 0x04:
	print "Disturber detected - masking"
	sensor.set_mask_disturber(True)
	elif reason == 0x08:
	now = datetime.now().strftime('%H:%M:%S - %Y/%m/%d')
	distance = sensor.get_distance()
	print "We sensed lightning!"
	print "It was " + str(

...

[Steve M.]

Hi Robin:  Congratulations..I hope your system stays stable, but you need some lightning to be sure it does! Ship it to me in Florida and I will let you know in a short time! Is your sensor connected with just a short (less than 1 meter) cable, or have you extended it out of range of interference from other equipment?

I did notice the following with my system: when Weewx starts, either from boot or just stop/start, a lightning.sdb file is created. I have attached that file as it may be useful.

I also would like to know if my directory structure is correct: under home/weewx/bin/user are:  as3935.py  and customschema.py ( a modified copy of wview.py as suggested by Matt in an earlier post).
                                                                                     : under root/usr/local/lib/python2.7/dist-packages/RPi_AS3935 are two folders: (1.) RPi_AS3935 which contains RPi_AS3935.py  and  (2) folder RPi_AS3935-0.1.1.egg-info.

If you, WH3080, Matt, or any other interested party wants to see my various files, I will post them.

Thanks to all.

[Robin]

AS3935 and WeeWX still running OK.

I tried to generate some 'artificial lightning' with a spark igniter but all I got was

Jul 26 17:42:17 PWS weewx[2221]: as3935: noise level too high - adjusting 

So it looks like it is doing something at least.

Steve, in answer to your question, the cable is currently less than 1 metre long, so it sits in a comparatively noisy location (for now).

I guess all I can do now is wait......................... 

On Thursday, 23 July 2015 16:02:07 UTC+3, WH3080 wrote:

[Steve M.]

Possible success??

I decided to just start completely from scratch..deleted everything and installed Weewx 3.2.0. After installing all additional files and extensions, I started up and no longer (at least for now) have the GPIO error. On initial startup I had the same line as Robin with regards to "noise level too high - adjusting". At this time there is only one .sdb file in /archive; perhaps there has to be an actual strike before the lightning_sdb file is created?? I am running in Simulator mode, and if I startup so I can see the LOOPS, there are no entries for lightning_strikes or avg_distance.

I have debug = 1, and will see what happens.

Again, thanks to all for their help.

Steve

[WH3080]

Hi Matt and 500+ other AS3935 thread interestees,

yes, you're right. I cited Steve's log and he reported the "immediate crash version", which I saw on my system as well. It does happen right away at boot or restart. However, as  I reported earlier, a comparable error involving the GPIO message has happened to my system after it was running stable for a while.

To make sure I report the most reliable troubleshooting data I completely setup my system again. New Raspbian with kernel update 4.0.9, new WeeWX 3.2.1. with all new WeeWx extensions and uploaders, Ishikawa lab modified AS3935 library (http://www.ishikawa-lab.com/RasPi_lightning.html) and unmodified WeeWX service from Matt as well as the same Embedded Adventures AS3935 board hardware revision v6. This Pi is dedicated to WeeWX and has "no other duties" to avoid overloading the processor. I have integrated the lightning data into Twitter messages. So far my system has been reporting every 5 minutes and not crashed yet. But, we had no thunderstorms either :-) I will report back what happens during thunderstorms and when lightning strikes.

BTW, for European WeeWX enthusiasts this page maybe of interest: www.estofex.org (European Storm Forecast Experiment). Interestingly, they report lightning likelyhoods also with a 40 km perimeter. Their data can also be legally embedded.

Best,

WH3080

[Steve M.]

Hi WH3080 and all others:

It looks like we took the same steps, with the exception of the Ishikawa modification. A few questions; when you started up, did weewx generate a lightning.sdb file, and do you see the two lightning fields in your Loops? Second, do you think there may be any advantage to the Ishikwawa mod, and have you tried the calibration.py file from the same site?

I just ask for future reference, as I don't want to do anything to my setup at this time unless it crashes (again).

Steve

[Robin]

Steve,

I added lightning_strikes and avg_distance to my schema and they are now part of weewx.sdb.

I have a lot of zeros for lightning_strikes and null for all the avg_distance records added with each archive record since I started the AS3935.

One question I do have is; how/where do I set up the units for the average distance (km)? Clearly there are no units for the number of strikes so should this be set to none?

I am not going to wish for a storm, as while they can be beautiful, they can also be very destructive.

I thought you might be interested in a photograph I took of a storm last August.

Regards

Robin

[WH3080]

Hi Robin and other lightning enthusiasts,

I am currently not doing any database logging. I wanted to keep it simple for now.

However, here is some evidence that the sensor using the setup described above and settings reported earlier by me works with Matt's as3935.py WeeWX service.

I embedded "lightning strikes" (Blitz(e) and "avg_distance" (in km) into my tweets: https://twitter.com/wx3080. The thunderstorm approached at 17:51. It was 24 km away, came closer to 15.5 km 5 min later, 13 km in another 5 min etc. The strikes roughly match the data from www.blids.de (the Siemens enigneered professional lightning detection system) (see http://wetterstation.altervista.org/wordpress/blitze/) and www.lightningmaps.org (see http://wetterstation.altervista.org/wordpress/blitzortung/) or in realtime here: http://www.lightningmaps.org/realtime?lang=en

Best,

WH3080

[WH3080]

Correction: the first strike was picked up at 17:31 at 34 km, the 24 km at 17:51 and so on ...See: https://twitter.com/wx3080 and http://wetterstation.altervista.org Best, WH3080

[WH3080]

Hi Matt.

my system crashed again early this morning. It has been inactive for 8 hours now. Please find attached the full log. It looks like it attempted to reboot itself and in this process the GPIO error message shows up. This confirms your assumption that this problem ist related to the boot / restart process. However, in this scenario I did not boot or restart the system myself.

What other advise could you give me / us from the syslog? As I wrote earlier, this was a complete reinstall dediacted to WeeWX only.

If you need any additional config files etc. let me know.

Thanks,

WH3080

[mwall]

On Tuesday, July 28, 2015 at 10:10:04 AM UTC-4, WH3080 wrote:

Hi Matt.

my system crashed again early this morning. It has been inactive for 8 hours now. Please find attached the full log. It looks like it attempted to reboot itself and in this process the GPIO error message shows up. This confirms your assumption that this problem ist related to the boot / restart process. However, in this scenario I did not boot or restart the system myself.

What other advise could you give me / us from the syslog? As I wrote earlier, this was a complete reinstall dediacted to WeeWX only.

the last 5% always takes 90% of the work...

try the attached 0.3rc1.  it detaches any event handler before trying to attach one.  it also tries to clean itself up when weewx shuts down.

m

 

[WH3080]

Hi,

no luck yet...

Jul 28 16:58:15 raspberrypi weewx[2944]: as3935: service version is 0.3rc1
Jul 28 16:58:15 raspberrypi weewx[2944]: engine: Caught unrecoverable exception in engine:
Jul 28 16:58:15 raspberrypi weewx[2944]:     ****  'module' object has no attribute 'event_remove_detect'
Jul 28 16:58:15 raspberrypi weewx[2944]:     ****  Traceback (most recent call last):
Jul 28 16:58:15 raspberrypi weewx[2944]:     ****    File "/home/weewx/bin/weewx/engine.py", line 836, in main
Jul 28 16:58:15 raspberrypi weewx[2944]:     ****      engine = EngineClass(config_dict)
Jul 28 16:58:15 raspberrypi weewx[2944]:     ****    File "/home/weewx/bin/weewx/engine.py", line 75, in __init__
Jul 28 16:58:15 raspberrypi weewx[2944]:     ****      self.loadServices(config_dict)
Jul 28 16:58:15 raspberrypi weewx[2944]:     ****    File "/home/weewx/bin/weewx/engine.py", line 136, in loadServices
Jul 28 16:58:15 raspberrypi weewx[2944]:     ****      self.service_obj.append(weeutil.weeutil._get_object(svc)(self, config_dict))
Jul 28 16:58:15 raspberrypi weewx[2944]:     ****    File "/home/weewx/bin/user/as3935.py", line 124, in __init__
Jul 28 16:58:15 raspberrypi weewx[2944]:     ****      GPIO.event_remove_detect(self.pin)
Jul 28 16:58:15 raspberrypi weewx[2944]:     ****  AttributeError: 'module' object has no attribute 'event_remove_detect'
Jul 28 16:58:15 raspberrypi weewx[2944]:     ****  Exiting.

[mwall]

On Tuesday, July 28, 2015 at 11:00:01 AM UTC-4, WH3080 wrote:

Hi,

no luck yet...

sorry, i got the syntax backward.  try 0.3rc2 instead.

 

[Steve M.]

Matt et al. 

So far my system has not crashed, but I have a question on weewx.conf:

The line (taken from the notes in the .py file) that says calibration = 6; does that refer to the value of the tuning capacitor? If so, I would assume I would change it to the value assigned to my particular sensor by Imbedded Adventures which is 3 in my case. Also, I remember reading somewhere that the sensor may work better by setting it for Outdoors even when it is indoors. Would this be done by setting Indoors = False or do some adjustments have to be made in AS_3935.py?

Steve

[WH3080]

Thanks Matt!

[WH3080]

Hi Steve,

The line (taken from the notes in the .py file) that says calibration = 6; does that refer to the value of the tuning capacitor?

Yes!
 

If so, I would assume I would change it to the value assigned to my particular sensor by Imbedded Adventures which is 3 in my case.

Correct.
 

  Would this be done by setting Indoors = False or do some adjustments have to be made in AS_3935.py?

Not in the service file, but weewx.conf.

Best,

WH3080

[Ian]

The AS3935 is a challenging sensor to get working and has many quirks; the upside is that you get digital lightning results in less than an inch square of PCB space.  We've iterated around many prototypes and design stages to get the right PCB track and component combinations for the best results.  Frankly we were ready to give up on it at one point when we just couldn't get the design to work reliably (and it turned out to be the PCB manufacturer's tolerances were not good enough). 

v8 of our humble breakout is coming out soon, it contains fixes for a fault in the chip that silences interrupts at 5V in some circumstances, so this won't have any relevance for 3.3V Pi users.

We are super excited to see the fantastic work around Weewx and would be delighted to take your requests for other sensor types or even a complete remote weather sensor setup - email me at iharris at embededadventures dot com if you have ideas.

We are genuinely thankful for all the work on this forum. As such we are giving Weewx users a bonus discount on our website - use the coupon code weewx at checkout to get 15% off all the products in your order.  We don't do this kind of thing very often, as a small company, but we're trying to be appreciative in the best way we can.

Kind regards,

Ian.

Embedded Adventures

[WH3080]

Hi Matt,

I just reviewed my syslog of the past 24 hours and did not find any more error messages related to the updated as3935.py WeeWx service. I think you can release it. I will report back should any new problems arise.

Meanwhile I am already playing with a modification to incorporate the energy measurements .-) Stay tuned.

WH3080

(http://wetterstation.altervista.org)

On Tuesday, 28 July 2015 17:34:33 UTC+2, mwall wrote:

[Robin]

UPDATE

I still have not seen any lightning and my system is still running and stable.

I don't know if it is relevant but I have just noticed that my MOD-1016 hardware is Version 6.

I am going to stick with weewx-as3935-0.2 until something happens. Perhaps it will add something to the knowledge base.

How/where do I set the value of the Tuning Capacitor and Indoors/Outdoors? I can see nothing in weewx.conf.

[WH3080]

Hi Robin,

lightning is essential for testing, because the interrupt required for the readout (and also potentially responsible for the trouble) is only triggered by lightning (or unmasked disturbers). Hardware V6 indicates you use the latest EA AS3935 board. No action required here.

You may want to check the anti-static bag that your sensor was delivered in from EA. There should be a sticker indicating the tuning capacitor value. Please also see: http://www.embeddedadventures.com/datasheets/MOD-1016_hw_v6_doc_v3.pdf. Matt originally programmed it for 6, because my board needs a tune-cap value of six.

Please download Notepad++ (https://notepad-plus-plus.org/) and open Matt's as3935.py service file. The "magic" is hidden in there, i.e. Matt has put all the configurantion information into the comment section (top portion of the file). Some folks may require changes on the bus settings. All this is explained here: https://github.com/pcfens/RaspberryPi-AS3935, here: https://learn.adafruit.com/adafruits-raspberry-pi-lesson-4-gpio-setup/configuring-i2c or and here: https://learn.adafruit.com/using-the-bmp085-with-raspberry-pi/configuring-the-pi-for-i2c

These settings actually need to be set in weewx.conf. More help is available on the WeeWX Github Wiki pages: https://github.com/weewx/weewx/wiki/as3935

I case you  experience any difficulties, find below the respective portion of the file for your reference.

Best,

WH3080

# $Id: as3935.py 1345 2015-07-28 14:54:02Z mwall $
# Copyright 2015 Matthew Wall

"""
A service for weewx that reads the AS3935 lightning sensor range.  This service
will add two fields to each archive record:

  lightning_strikes - number of lightning strikes in the pass archive interval
  avg_distance - average distance of the lightning strikes

To track these and use them in reports and plots, extend the schema as
described in the weewx customization guide.

The service can also save data to a separate 'lightning' database.  To enable
this feature, specify a data_binding in the AS3935 section of weewx.conf.

Configuration:

Rev. 1 Raspberry Pis should leave bus set at 0, while rev. 2 Pis should

set bus equal to 1. The address should be changed to match the address of
the sensor.  Common implementations are in README.md.

[AS3935]
    address = 3
    bus = 1
    noise_floor = 0
    calibration = 6
    indoors = True
    pin = 17
    data_binding = lightning_binding

[DataBindings]
    [[lightning_binding]]
        database = lightning_sqlite

[Databases]
    [[lightning_sqlite]]
        root = %(WEEWX_ROOT)s
        database_name = archive/lightning.sdb
        driver = weedb.sqlite

[Engine]
    [[Services]]
        data_services = ..., user.as3935.AS3935

[Robin]

WH3080,

Thanks for the very full reply.

I take it that calibration is the "Tune" value, in my case 4?

I will use nano to make the change.

Regards

Robin

[WH3080]

Yes Robin, that's the way to do it. Best, WH3080

[Robin]

Greetings to all,

The MOD-1016 data sheet quotes:

I2C requires the use of pull-up resistors. The board comes with the pull-up resistors enabled. If you are connecting to an existing I2C buss that already has pull-up resistors, or you are using internal pull-ups in your microcontroller, you can disable the pull-up resistors by unsoldering the resistors R1 and R2 (the two 10K resistors nearest the MISO connection).

I'm running a Raspberry Pi Model B (512 MB), do I need to unsolder resistors R1 and R2?

Regards

Robin

[Steven Meltz]

Robin
I too faced this delemma,  but ended up (with the Imbedded Adventures board ) NOT unsoldering the resistors. When I get back home next week,  I can check how the board functioned during several thunderstorms.
Steve

[Robin]

I'm having real problems detecting lightning with the MOD-1016

I guess that would explain why! 

[WH3080]

Hi Robin and Steve,

you do NOT need to modify the Embedded Adventures AS3935 board in any way if you use the board as described in this thread, i.e. hooked up to the I2C bus of the Raspberry Pi. This board is configured to use the I2C bus (unlike the one made my Playing with Fusion) when shipping from the factory. Please see photograph attached. My System has been running stable since I started using Matt's updated driver.

It pushes weather information with lightning data every 5 minutes to Twitter and the website: 

https://twitter.com/wx3080

and

http://j.mp/berlinwetter

See earlier posts in this thread to see a thunderstorm approaching and departing.

Best,

WH3080

[WH3080]

Hi Robin,

this map shows that that there was no lightning activity (detected) on your island. Assuming that blitzortung.org has a fairly extensive global coverage, your sensor did not miss anything.

Other  providers of free European storm and lightning data include estofex.org and http://ilmatieteenlaitos.fi/

Best,

WH3080

[WH3080]

Sorry I missed to include EUCLID as another source of European lightning data: http://www.euclid.org

On Sunday, 9 August 2015 07:21:00 UTC+2, Robin wrote:

[Steve M.]

I have a question re demo.py. After running Weewx for a week unattended, I found seemingly random entries in weewx.sdb: by random I mean they did not appear to coincide with rain storms. Of course, lightning can occur without rain, so perhaps that is what happened.

Anyway, now that I am back home, I thought I would run the sensor without Weewx and see what results I get. For this, I assume that I would run demo.py from the RPi_AS3935 library and this leads to my question. Do I change tun_cap=0x0F to tun_cap=0x03 for my particular board?

Thanks,  Steve

[WH3080]

Hi Steve,

are you running demo.py (which is an independent demo application of Phil Fenstermacher) or the WeeWx service that Matthew Wall wrote and updated to version 3 recently?

Demo.py does no write to any database. Matt's WeeWx service may write to the database if it's configured that way. Please see previous detailed posts in this thread on how to do that and also how to configure the tuning capacitor.

AS3935 detects lightning through electromagnetic waves. It can pick up waves of cloud to cloud and cloud to ground strikes. AS3935 does not detect rain at all.

The strikes in your database maybe unmasked disturbers, if you cannot independently verify them through sources, i.e. blitzortung.org mentioned in this thread. In that case you may need to tweak the chip settings.

The AS3935 chip was tested and tuned in Finland and Florida for obvious reasons. If set up and tuned appropriately it is reliable according to the manufacturer: http://ams.com/eng/Press-Center/Release-Archive/Release-Archive-2012/AS3935.

Living in Florida you should become our most reliable tester :-)

Best,

WH3080

[Steve M.]

Hi  WH3080

I am running demo.py as a experiment. I know that it does not write to a database. I just want to see if there are any indications of activity without looking thru weewx.sdb (I have not yet made any text or graphical indicators of strikes or distance in Weewx).

Do you have any suggestions on possible "tweaks" ?

Thanks again,  Steve

[WH3080]

Hi Steve,

demo.py is a command line script. I reports immediately any strikes and distances as well as masked disturbers or increased noise levels. You can run it for days if you like and review the screen output. Please see GitHub instructions. Alternatively you could use the Japanese script that reports everything online and also puts this information into a .csv file. Tweaking chip settings is described on various websites I have cited in my posts in this thread, most recently for a response to Robin. A simple starting point would be changing the indoor / outdoor setting.

Best,

WH3080

[Steve M.]

Hi again..I am now having thunderstorm activity in the area.

So far I have gotten no output running the demo.py except for the "waiting for lightning....." comment. 

My present settings in demo.py are:
 

     sensor = RPi_AS3935(address=0x03, bus=1)

     sensor.set_indoors(False)
     sensor.set_noise_floor(2) It was 0, but does increasing it increase or decrease sensitivity??
     sensor.calibrate(tun_cap=0x03)

Presently, I am not sure the sensor is working.

Steve

[Steve M.]

With regards to previous post:  After changing tun_cap from 0x03 to 0x02, demo.py generated 7 lightning detections which corresponded to actual events. Tune_cap=0x03 was on the bag for the sensor, but I changed it up and down incrementally until it started working. I am changing the settings withing weewx.conf to the same, and will let that run. Now I have to code so the events are either shown graphically or as text.

Steve

[WH3080]

Hi Steve, patience and attention to detail do pay off :-) WH3080

[Steve M.]

Hello;

I intend on switching my sensor over to my RasPi v2 which has a faster processor (and I have had some reliability problems with the older Pi). The new RasPi has been running my actual station for quite a while, so my weewx.sdb file on that machine is large and full of data. I don't want to risk data loss (yes, I do back up), so I think the easiest method would be to just create a second database just for the sensor. The following are the relevant sections of weewx.conf:

[AS3935]
    address = 3
    bus = 1
    noise_floor = 0

    calibration = 2
    indoors = False

    pin = 17
    data_binding = lightning_binding

[DataBindings]
    [[lightning_binding]]
        database = lightning_sqlite

[Databases]
    [[lightning_sqlite]]

        root = /home/weewx/archive
        database_name = lightning.sdb

        driver = weedb.sqlite

[Engine]
    [[Services]]

        data_services = user.as3935.AS3935

When I view the data under lightning.sdb, there are only columns for dateTime, usUnits, and distance; there are no columns for interval or lightning_strikes. There is no data under any of the columns.

Do I need a separate schema entry under [[lightning_binding]] something like this?

 schema = [('dateTime',             'INTEGER NOT NULL UNIQUE PRIMARY KEY),
           ('usUnits',              'INTEGER NOT NULL'),
           ('interval',             'INTEGER NOT NULL'),
           ('lightning_strikes',    'REAL'),
           ('avg_distance',         'REAL'),]
         

Thanks,  Steve

[Robin]

I'm now getting confused. Yesterday we had a weak storm about 30km away and I recorded nothing.

Today I have 2 strikes recorded but nothing reported elsewhere and certainly no thunder heard.

Have I got this set up right?

From weewx.conf:

# Options for extension 'as3935'

[AS3935]

    bus = 1

    address = 3

    calibration = 4

    noise_floor = 0

    indoors = False

    pin = 17

 

MOD-1016 Package:

I'm running extension:

as3935-0.4rc1

Wired exactly as in WH3080's photo.

Any thoughts, or do I just need to be more patient and wait for a BIG storm? 

 

[Steve M.]

Hi Robin

Your setup looks correct, however I found that the tune # on the bag was different than the one that works for me.
I am using as3935 v 0.2. I am going to compare them later to see if there are any significant differences, but a quick check found one:  In my version under class AS3935(StdService): is a line which reads    pin = int(svc_dict.get('pin', 17))
                                                                                                                                                                                                  In your version it reads:                                                                     self.pin = int(svc_dict.get('pin', 17))

I have no idea if this coding difference is significant, however this is how I (finally) found out my sensor was working and had a number of real readings. I shut down Weewx and ran demo.py. I waited until I could see that there was a storm on Blitztung.org in my vicinity, and I turned on an AM radio to an unused frequency. If the radio had a good static burst and it appeared from Blitztung that there was a hit within 50KM, I would increment the tune_cap value in demo.py by one interval at a time starting at 1, and when my value was 2, viola..there were now readings. The value on my bag is 3. You may find that calibration = 4 may not be the best for you. The sensors were calibrated in a lab, and this does not always translate to the "real" world. There can be differences due to lead length, inter-lead inductance, and the phase of the moon!

Now I have to figure out why I can't get a separate lightning.sdb file that contains data.

Steve

[Steve M.]

Hi again: I just did a file compare on the two as3935.py files and found that the one you are using has significant differences further down the code with respect to GPIO handling, records, saving date,etc. Not sure why the version on the Wiki (the one I used 0 is not the updated one.

Again, not being a programmer, I am going to use the newer version (0.3rc2) which MAY take care of my lightning.sdb problem, but I am going to change the line    self.pin = int(svc_dict.get('pin', 17))   to  pin = int(svc_dict.get('pin', 17)) which is from my version.

Slogging right along!!

Steve