Lightning detection sensor?

[jlg89]

Is your feature request related to a problem? Please describe:
It's frustrating to not be able to use lightning detection to trigger automations in HomeKit

Describe the solution you'd like:
The ability to configure a contact sensor that triggers when lightning has been detected. Configuration parameters might include the maximum lightning distance that triggers the sensor, and how long to keep the contact sensor closed after an in-range strike is detected. So the contact sensor could be configured to, for example, trigger when lightning has been detected within 10 miles in the past 15 minutes.

[chasenicholl]

Great idea. I'll include this in my next minor version update.

[DMBlakeley]

As reference, I did something similar in my homebridge-awair2 plug-in adding limit switches for VOC and PM2.5 using occupancy sensors.

[chasenicholl]

@jlg89 I have noted this feature request. I am going to close this issue. We'll try and work this idea into an upcoming feature release. Thanks for the feedback!

[jlg89]

I want to add some context to this feature request, because I know that the frequency of thunderstorms is widely variable. Where I live, we have thunderstorms up to 30% of the time, mostly in summer months, and all our outdoor activities are ultimately governed by lightning. If a strike has been detected within 6-7 miles (typically) within the last 15 minutes (typically), everything from public swimming pools to airport fueling crews comes to a halt. It's a Really Big Deal(tm). So, being able to trigger automations based on the proximity & timing of the last lightning strike would be an immensely useful feature for those in thunderstorm-heavy areas.

[chasenicholl]

Hey @jlg89

I started working on this in a release branch. https://github.com/chasenicholl/homebridge-weatherflow-tempest/tree/release-4.2.0

I will publish a beta on npm. Could you help me test this feature?

[jlg89]

Be glad to. Sorry for the delayed response, I was finishing some classwork.

[jlg89]

Looking at the config for 4.2.0, I have a couple comments/questions.

The lightning sensor is currently under "contact_properties" which I assume you'll update to something more informative at some point. I'd say either "lightning_properties" or "strike_properties" or something like that.

"trigger_distance" is understandable, using e.g. "6" would make the contact activate only when lightning is detected up to 6km away.

I have a question about the "trigger_time" value. The description seems to indicate that it is like "trigger_distance" in that multiple strikes must be detected within the set time interval in order to activate the contact. Is this correct? The behavior I'm after would be for the contact to remain active for the "trigger_time" duration after each strike that is detected within the "trigger_distance" range. So:

(lightning detected at distance > trigger_distance) = nothing happens
(lightning detected at distance ≤ trigger_distance) = contact goes active for trigger_time
(lightning detected at distance ≤ trigger_distance, contact already active) = reset active timer to trigger_time

This could also be accomplished by simply keeping the contact active for a few seconds (maybe refresh interval minus 1s?), and using the contact to trigger a timed switch in another plugin like homebridge-dummy, or an automation.

[chasenicholl]

Great observation. I am going to remove the trigger time and instead have it trigger for a few seconds and then reset itself.

[jlg89]

So a usage scenario would be:

Most outdoor public swimming pools in Texas require everyone to stay out of the pool if lightning has been detected within a 10-mile radius with the past 30 minutes. Same rule for indoor pools, but with a 3-mile radius.

Let's say you want to know when lightning has struck within 10 miles of your weather station within the past 30 minutes.

In homebridge-weatherflow-tempest, configure the lightning sensor with a trigger_distance of 16 (16km=10mi).
(Question: how does the "units" setting affect this, if at all?)

In the homebridge-dummy plugin, configure a "Resettable Timed Switch" with a 30-minute timer:

    "accessories": [
        {
          "accessory": "DummySwitch",
          "name": "Lightning Alert",
          "time": 1800000,  <== number of milliseconds in 30 minutes
          "resettable": true
        }   
    ]

Create a HomeKit automation that turns on the "Lightning Alert" dummy switch whenever the lightning sensor turns on.

Create other automations or shortcuts based on the state of that Lightning Alert switch. One idea would be to set one or more smart lights to turn red as long as the Lightning Alert switch is on. Red lights mean stay out of the pool!

[DMBlakeley]

I have realized a similar scenario directly in HomeKit making use of a Shortcut. In my case, I wanted to know if I left either of my garage doors open for more than 30 minutes. I used Controller for home to make the OR scenario which started the timer when either of the garage doors opens. At end of the timer, a check is performed on the garage door state and if still open I get a notification.

Bringing up as going the Shortcut route may provide more flexibility than hardcoding in the plugin.

[jlg89]

If you close & reopen the garage door while the timer is running, does it reset the timer? That would be important for this application. I went this route since I'm already running homebridge and using homebridge-dummy for other things, and I know that the "Resettable Timed Switch" does exactly what's needed...but a Shortcut-based solution would be more elegant and flexible.

[DMBlakeley]

I am using Controller for HomeKit app in combination with the HomeKit automation and Shortcut. Controller for Home allows the OR function of the 2 garage doors (which you would not need) as well as providing the notification message if either garage door is open at the end of the 30 minutes. Needed to use Controller for HomeKit for the notification message as this functionality is not native to Shortcuts.

I believe each time the garage door open that the timer is reset but may need to do some tests to find out.

I purchased Controller for HomeKit app ages ago when it first came out and was pretty reasonable. Now it is a bit more expensive.

[jlg89]

Just installed 4.2.4b2, and the lightning sensor is going on and off randomly.

{
            "name": "Lightning Detected",
            "sensor_type": "Contact Sensor",
            "contact_properties": {
                "trigger_distance": 16
            }
        }

[jlg89]

Oddly, the random triggers stopped after a couple of hours, and have remained quiet. But we've had thunderstorms today, and lightning has been detected within the set radius, but the plugin hasn't triggered. I don't see anything particularly amiss in the logs -- let me know what debug setting to use, if you want those. When I start the plugin, this is the typical log:

[14/12/2024, 09:17:04] [WeatherFlowTempest] Launched child bridge with PID 149276
[14/12/2024, 09:17:04] The plugin "homebridge-weatherflow-tempest" requires Node.js version of ^18.20.4 || ^20.15.1 which does not satisfy the current Node.js version of v22.12.0. You may need to upgrade your installation of Node.js - see https://homebridge.io/w/JTKEF
[14/12/2024, 09:17:05] Registering platform 'homebridge-weatherflow-tempest.WeatherFlowTempest'
[14/12/2024, 09:17:05] [WeatherFlowTempest] Loaded homebridge-weatherflow-tempest v4.2.4-beta.2.0 child bridge successfully
[14/12/2024, 09:17:05] Loaded 5 cached accessories from cachedAccessories.0EFE4724592E.
[14/12/2024, 09:17:05] [WeatherFlowTempest] Finished initializing platform: WeatherFlowTempest
[14/12/2024, 09:17:05] [WeatherFlowTempest] Loading accessory from cache: Temperature
[14/12/2024, 09:17:05] [WeatherFlowTempest] Loading accessory from cache: Relative Humidity
[14/12/2024, 09:17:05] [WeatherFlowTempest] Loading accessory from cache: Light Level
[14/12/2024, 09:17:05] [WeatherFlowTempest] Loading accessory from cache: Wind Speed
[14/12/2024, 09:17:05] [WeatherFlowTempest] Loading accessory from cache: Lightning Detected
[14/12/2024, 09:17:05] [WeatherFlowTempest] Executed didFinishLaunching callback
[14/12/2024, 09:17:05] [WeatherFlowTempest] Initializing by Socket
[14/12/2024, 09:17:05] [WeatherFlowTempest] Using Tempest Local API.
[14/12/2024, 09:17:05] [WeatherFlowTempest] TempestSocket initialized.
[14/12/2024, 09:17:05] [WeatherFlowTempest] Waiting for first local broadcast. This could take up to 60 seconds...
[14/12/2024, 09:17:05] Homebridge v1.8.5 (HAP v0.12.3) (WeatherFlowTempest) is running on port 44257.
[14/12/2024, 09:17:05] 

NOTICE TO USERS AND PLUGIN DEVELOPERS
> Homebridge 2.0 is on the way and brings some breaking changes to existing plugins.
> Please visit the following link to learn more about the changes and how to prepare:
> https://github.com/homebridge/homebridge/wiki/Updating-To-Homebridge-v2.0

[14/12/2024, 09:17:06] [WeatherFlowTempest] Initial local broadcast recieved.
[14/12/2024, 09:17:06] [WeatherFlowTempest] Restoring existing accessory from cache: Temperature
[14/12/2024, 09:17:06] [WeatherFlowTempest] Restoring existing accessory from cache: Relative Humidity
[14/12/2024, 09:17:06] [WeatherFlowTempest] Restoring existing accessory from cache: Light Level
[14/12/2024, 09:17:06] [WeatherFlowTempest] Restoring existing accessory from cache: Wind Speed
[14/12/2024, 09:17:06] [WeatherFlowTempest] device.sensor_type not defined
[14/12/2024, 09:17:06] [WeatherFlowTempest] Restoring existing accessory from cache: Lightning Detected
[14/12/2024, 09:17:06] [WeatherFlowTempest] discoverDevices completed
[14/12/2024, 09:17:06] [WeatherFlowTempest] removeDevices completed

[chasenicholl]

I think I know what’s going on. I designed the contact sensor loop to “re-engage” after 5 seconds. In other words, if lightening detected in the last 5 seconds, within the range specified, open contact sensor for 5 seconds. After those 5 seconds close sensor.

so if there was a storm I’m realizing this will give an on/off effect. I should update the logic to remain open after 5 seconds if there is still valid strikes.

[jlg89]

There wasn't a storm when it was randomly going on/off, it was doing that on its own somehow, and only for a couple of hours -- but then when there was a storm, it didn't do anything at all. Maybe something with the way the plugin interprets the "time since last strike" value?

I think it's correct behavior to close after 5 seconds, and only reopen if another strike is detected after the 5 seconds have elapsed. That allows the user to determine how to handle multiple strikes. In my case, I want each strike to reset the 30-minute counter on the dummy alert switch. If multiple strikes occur within one 5s period, I'm not too concerned about that, IOW no need to reset the 5s timer when additional strikes are detected.

[jlg89]

I'm curious how the Tempest reports lightning strikes. When you look at the app or the web page for the device (e.g. the one I'm working with is https://tempestwx.com/station/129765/grid), it shows how long ago lightning was last detected, and the distance, and a counter for the number of strikes in the last three hours. But the app only sends me a notification right when lightning strikes -- so there must be a particular boolean that goes true when a strike is detected, but I wonder how long that boolean stays true?

[chasenicholl]

The API reports the latest singular event like so.

"lightning_strike_last_epoch": 1495652340
"lightning_strike_last_distance": 22
"lightning_strike_count_last_3hr": 0

I assume the iOS app and website have a separate database or cache that records each one of these instances so they can provide the historical graph.

Anywho back to your observation of funny-ness at plugin start, and then no behavior during an actual storm. I'll have to look into this more myself. Next week I'll have more time to play around, hopefully we can get this feature out the door before the new year. Thanks!

[jlg89]

Turns out it isn't just at plugin start. Every now and then, it just triggers on/off. It happened one time yesterday evening, and today it's suddenly been doing it multiple times per minute for the past 2 hours. It will probably (hopefully) stop soon. According to the app, the last lightning detected was 2 days ago. Maybe there's some glitch in the comparison of the last_epoch value to current time, or in converting between epoch value and human readable timestamp?

[jlg89]

I wonder, in platformAccessory.ts, line 650, if you moved the (current_epoch_now - lightning_strike_last_epoch) calculation outside the "if" statement? It shouldn't matter, but maybe worth a try. Plus if you set another variable there it would be easier to log that value to sanity check the output.

 const current_epoch_now = Math.floor(Date.now() / 1000);
 const strike_delta = (current_epoch_now - lightning_strike_last_epoch);
      if (lightning_strike_last_epoch > 0
        && lightning_strike_last_distance > 0
        && lightning_strike_last_distance <= trigger_distance
        && strike_delta <= 5) {
        return 1; // trigger CONTACT_NOT_DETECTED.
      }

[jlg89]

Just an update, we've had several thunderstorm days over the past week. Oddly enough, there doesn't seem to be any connection between this contact sensor and actual lightning strikes. On some days, the sensor will switch on and off randomly, hundreds of times per day, even when there's no lightning. During thunderstorms, it might not trigger at all.

I'm hoping you'll spot some obvious issue in the code, but if you don't, then just add whatever logging data would be most useful, and I'll run it in debug mode and give you the output.