Lightning data (strike detectors)

[mgrouch]

Add under environment section for lightning strike detectors.

Example would be SparkFun Lightning Detector - AS3935
https://www.sparkfun.com/products/15441

Proposed parameters:

1. EventType: Lightning/Disturber/Noise
2. Distance (estimated): km (float value)
3. Distance (estimated) to front: km (float value)
4. Energy level (Just some value for scale): int
5. Count of strikes in last time window of N minutes: int
6. Size of window in min for 5. (Default is 15)

[mgrouch]

Proposal

    "lightning": {
      "title": "lightning",
      "type": "object",
      "description": "Thunderstorms and lightnings related data.",
      "properties": {
        "eventType": {
          "enum": [
            "lightning",
            "disturber",
            "noiseDetected",
            "noiseGone"
          ]
        },
        "distance": {
          "description": "Distance to strike",
          "$ref": "../definitions.json#/definitions/numberValue",
          "units": "m"
        },
        "distanceToFront": {
          "description": "Distance to front",
          "$ref": "../definitions.json#/definitions/numberValue",
          "units": "m"
        },
        "energyScale": {
          "description": "Energy for scale (not measured in particular units)",
          "type": "number"
        },
        "totalDetected": {
          "description": "Total count detected recently",
          "type": "number",
          "default": 0
        },
        "detectionPeriod": {
          "description": "Time period in minutes for total recently detected counter",
          "type": "number"
        }
      }
    },

[tkurki]

Having previously been involved with the specification work I find that writing first some real world software and approaching the specification only after you have some real world applications is a much better approach than adding something first to the specification, to find out lateer that you did not quite get everything right.

Another problem is that JSON schema and the data model is a little bit more complicated than people assume. Instead of starting from the schema it is much more fruitful to start from writing some deltas and example full data. The specification tests contain many examples, and imho we should have test/example data for anything new we add to the schema.

Previously additions with no test data have turned out to be not what the author meant. For example why are some of your proposed fields simple numbers and others are numberValues. Have you validated some full data against this schema so that you know what the data specified by this addition looks like?

Just looking at your proposal I have no idea how the enum values would be used. Can you give example delta messages for a sequence of events how the data from a lightning detector in a typical case would look? What do disturber and noiseGone mean and how should they be used?

There are also other sources for lighting data than lightning detectors. I can imagine services like https://www.lightningmaps.org/ and volunteer lightning detection networks can provide near real time lightning data over an internet connection. Official and commercial weather services probably can do the same.

Some background information https://www.nssl.noaa.gov/education/svrwx101/lightning/detection/

Imho we should look beyond lightning detectors and extend the schema to cover lightning data from different potential sources.

[mgrouch]

I actually looked though the code https://github.com/sparkfun/SparkFun_AS3935_Lightning_Detector Before adding spec proposal Also looked at https://www.lightningmaps.org/

…

Sent from my iPhone

On Apr 17, 2021, at 2:36 PM, Teppo Kurki ***@***.***> wrote:  Having previously been involved with the specification work I find that writing first some real world software and approaching the specification only after you have some real world applications is a much better approach than adding something first to the specification, to find out lateer that you did not quite get everything right. Another problem is that JSON schema and the data model is a little bit more complicated than people assume. Instead of starting from the schema it is much more fruitful to start from writing some deltas and example full data. The specification tests contain many examples, and imho we should have test/example data for anything new we add to the schema. Previously additions with no test data have turned out to be not what the author meant. For example why are some of your proposed fields simple numbers and others are numberValues. Have you validated some full data against this schema so that you know what the data specified by this addition looks like? Just looking at your proposal I have no idea how the enum values would be used. Can you give example delta messages for a sequence of events how the data from a lightning detector in a typical case would look? What do disturber and noiseGone mean and how should they be used? There are also other sources for lighting data than lightning detectors. I can imagine services like https://www.lightningmaps.org/ and volunteer lightning detection networks can provide near real time lightning data over an internet connection. Official and commercial weather services probably can do the same. Some background information https://www.nssl.noaa.gov/education/svrwx101/lightning/detection/ Imho we should look beyond lightning detectors and extend the schema to cover lightning data from different potential sources. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[mgrouch]

Sorry wrong link for code. Here https://github.com/sparkfun/SparkFun_AS3935_Lightning_Detector_Arduino_Library

…

Sent from my iPhone

On Apr 17, 2021, at 2:46 PM, Mikhail Grushinskiy ***@***.***> wrote: I actually looked though the code https://github.com/sparkfun/SparkFun_AS3935_Lightning_Detector Before adding spec proposal Also looked at https://www.lightningmaps.org/ Sent from my iPhone >> On Apr 17, 2021, at 2:36 PM, Teppo Kurki ***@***.***> wrote: >> >  > Having previously been involved with the specification work I find that writing first some real world software and approaching the specification only after you have some real world applications is a much better approach than adding something first to the specification, to find out lateer that you did not quite get everything right. > > Another problem is that JSON schema and the data model is a little bit more complicated than people assume. Instead of starting from the schema it is much more fruitful to start from writing some deltas and example full data. The specification tests contain many examples, and imho we should have test/example data for anything new we add to the schema. > > Previously additions with no test data have turned out to be not what the author meant. For example why are some of your proposed fields simple numbers and others are numberValues. Have you validated some full data against this schema so that you know what the data specified by this addition looks like? > > Just looking at your proposal I have no idea how the enum values would be used. Can you give example delta messages for a sequence of events how the data from a lightning detector in a typical case would look? What do disturber and noiseGone mean and how should they be used? > > There are also other sources for lighting data than lightning detectors. I can imagine services like https://www.lightningmaps.org/ and volunteer lightning detection networks can provide near real time lightning data over an internet connection. Official and commercial weather services probably can do the same. > > Some background information https://www.nssl.noaa.gov/education/svrwx101/lightning/detection/ > > Imho we should look beyond lightning detectors and extend the schema to cover lightning data from different potential sources. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub, or unsubscribe.

[mgrouch]

I’ve wrote a program for raspberry pi to send notifications on lightning strikes.

The software is using as3935 sensor

https://www.digikey.com/en/products/detail/dfrobot/SEN0290/10279741

The code is posted here:

https://github.com/bareboat-necessities/rust-modules/tree/main/lightning-detect