Skip to content

Restarts and the clock

Direct Connect Bridge. Mirrors the Modbus Bridge page Restarts and the clock section for section.

What a bridge restart does to running force commands and open windows, and which clock every schedule runs on.

Bridge restart

Step What happens
Graceful shutdown The scheduler worker is told to stop. If the bridge holds a force it started (in memory), it sends a Release, to FWH_MODBUS_HOST or else the first gateway's host. Exit HA actions do not run and History gets no exit row.
Crash or power loss Nothing is released. The force stays on the aGate.
Start-up: interrupted dispatches A force a schedule (or the Battery Control widget) started is recorded until it is released. At start-up, if the Modbus client (this bridge) is on, rows still marked active are handled by the interrupted-dispatch policy (default notify: alert, do not touch the battery).
Start-up: paused runs A run that was paused when the bridge stopped is closed as stopped.
First ticks The engine's in-memory state is empty. A schedule that already fired in the current occurrence does not fire again (that is stored). One that has not fired is evaluated afresh; its hold starts from zero.
Catch-up Not in this bridge. Windows that opened and closed while the bridge was down are not run late, and leave no missed row.

The interrupted-dispatch policy (Settings, dispatch_interrupt_policy) decides what start-up does with a force a restart cut short:

Policy Window ended Window still open
none recorded, nothing else recorded, nothing else
notify (default) alert your notification devices; the battery is not touched the same
release if the battery is still forced: Release if still forced: re-arm the bridge's timer to release at the window end
resume as release as release; and if no longer forced: force again for the rest of the window

See also After a bridge restart mid-dispatch.

With the default policy a force can outlive a restart

The aGate does not end a force by itself; the bridge's own timer does, and that timer is in memory. With notify, a force that was running when the bridge restarted keeps running until something releases it. The schedule's window end still sends a Release if the bridge is back up before the window closes (the first tick marks the window open, so its closing edge is seen). If the window closed while the bridge was down, no Release comes from the scheduler. Release from Control, or choose release.

Start-up and shutdown handle only the first gateway

The start-up reconcile reads the active dispatches for one host: FWH_MODBUS_HOST, or else the first gateway's. The shutdown release goes to the same host. On a site with several gateways a force on another gateway is neither reconciled nor released. Issue

192.

Not in this bridge: releasing a stale force on gateway start-up. release_stale() exists in the code but nothing calls it.

So a restart during an open window usually means no second write for a schedule that had already fired, and a fresh attempt for one that had not.

The clock

Settings → Setup → Where is this site? The site timezone schedules run on

Schedules run on each gateway's own clock: the scheduler asks the aGate for its time (time_location), works out the UTC offset (rounded to 15 minutes), and evaluates that gateway's schedules in that wall-clock time. The offset is cached for 10 minutes per gateway. If the gateway cannot be read, the bridge falls back to the container's clock for that tick.

  • An unreadable gateway is not treated as UTC: the container's clock is used.

  • A gateway clock that is impossible (an offset outside UTC−12 to UTC+14) is ignored; the base offset it reports is used instead, or the container's clock.

  • Where is this site? in Setup sets the site timezone. It sets the clock of mock gateways, and clears the cached offsets; a real gateway's clock comes from the aGate.

The pages and previews use the container's clock

Only the tick uses the site clock. Next:, ● active, the Timeline (its "now" line and today's windows) and Test against live use the bridge container's clock, and History shows times in the bridge host's zone. When the container's zone differs from the site's, these are off by the difference. Issue #161. See docs/TIMEZONES.md.

Not in this bridge: time.* sensors (time.hour, time.dow, time.utc_offset_h, time.tz_ok) and a recorded-timezone check at start-up.

Several gateways, several clocks

Each gateway's schedules run on that gateway's clock. An unbound schedule runs on the default gateway's clock (#182). The Modbus Bridge uses one clock for all gateways.

Daylight saving

The tick works in a fixed UTC offset per gateway, re-read at most every 10 minutes. Around a daylight-saving change:

  • for up to 10 minutes after the change the old offset can still be in use, so windows can open up to an hour early or late in that time;
  • when clocks go forward, a window inside the missing hour may not open that day; when they go back, the repeated hour is seen twice, but the occurrence key is the date, so a Daily-type schedule that already fired does not fire again (Every N minutes and cron slots may).

This is from the code; it has not been observed on a gateway. Keep schedules out of the change hour, or check History afterwards.