Undocumented weather/ endpoints report the Storm Hedge event and why it fired

[cd34]

Undocumented weather/ endpoints report the Storm Hedge event and why it fired

The gateway exposes its Storm Hedge events under hes-gateway/terminal/weather/.
These endpoints key on equipNo, not the gatewayId every other endpoint in this
library takes — which is why they are easy to miss entirely. I spent a while
concluding the reason for a hedge simply wasn't available before finding them
referenced in the franklinwh-cloud fork (#34).

What they return

getStormList?equipNo=<gw>&pageNum=1&pageSize=10&lang=en_US — current and past events:

{"id": 100354, "eventType": "Red Flag", "onset": "2026-08-05 12:00:00",
 "ends": "2026-08-05 19:00:00", "severity": "Severe", "backupStatus": 1,
 "curUtcTime": "2026-08-05 10:36:10", "timeZone": -7.0}

getProgressingStormList?equipNo=<gw> — which event is live right now, ids only:

{"id": 100354, "onset": "2026-08-05 12:00:00", "severity": "Severe", "durationTime": 420}

getStormSetting?equipNo=<gw> — the feature toggle, the pre-charge lead time, and
every trigger type with a per-event flag:

{"enableStorm": 1, "advanceBackupTime": 180, "noticeEnable": 0,
 "stormEventVOList": [{"id": 1, "name": "Ashfall", "openFlag": true},
                      {"id": 2, "name": "Avalanche", "openFlag": true}, ...]}

There is also getCurrentBriefWeather?equipNo=<gw> returning conditions, temperature
and a short forecast.

Why this is worth exposing

A Storm Hedge holds the battery at 100% and stops it discharging. Without these
endpoints the visible effect is a battery that has apparently stopped working, and
the API otherwise gives no reason — touAlertMessage and offGridReason are null
throughout.

advanceBackupTime matters as much as the event: mine is 180 minutes, so the pack was
already full and held three hours before the event window opened. Any "is a hedge
active?" check based on the event window alone answers no during exactly the period
that prompts the question.

Two gotchas

• Use both list endpoints. The progressing list is authoritative about what is
  live but omits eventType and ends; the full list carries those but also every
  past event. Match by id rather than inferring from timestamps, for the
  advanceBackupTime reason above.
• Timestamps are gateway-local wall time with no offset, with the zone supplied
  separately as timeZone: -7.0. A host running UTC that compares them against
  datetime.now() reports an event active hours early — that bit me during
  development.

Would a get_storm_list() / get_storm_setting() pair be welcome, or would you
rather this stayed out of the lean core? Happy to send a PR either way.