HazeVane
Operator & installation manual

Product overview

HazeVane is a self-contained outdoor show-control appliance. It measures local wind direction and speed, models which installed hazers are upwind of one desired coverage area, and transmits the appropriate DMX scenes over ANSI E1.31 sACN.

The appliance continues operating without a cloud service, internet connection, wireless connection, or external computer. A lighting console is optional: local automatic control works independently, while a dedicated sACN command input can provide remote enable, arm, blackout, and bounded fixture tests.

The embedded interface is one infinite canvas: site boundary, stage, FOH, coverage, hazers, live wind, predicted plumes, and control status remain visible together while contextual inspectors and settings overlays handle detail.

Safety and operating boundaries

• Restrict physical access and control-LAN access to trusted operators.
• Coordinate theatrical haze with venue management, fire detection, alarms, and authorities having jurisdiction.
• Use dedicated output universes. HazeVane does not merge with another source on its hazer output addresses.
• Confirm fixture DMX values against the real fixture manual and hardware.
• Treat predicted plume coverage as a deterministic control heuristic, not computational fluid dynamics or a coverage guarantee.
• Wind dominates the model. Nozzle orientation, obstructions, thermal lift, and local turbulence are not modeled in version 1.

Supported hardware platform

Wi-Fi and Bluetooth silicon may exist on the module but must never be initialized or used. The controller’s normal power and communications use wired PoE Ethernet.

Physical installation

Controller and sensor

1. Mount the controller and field interface in an enclosure appropriate to weather, impact, condensation, and thermal load.
2. Keep the reference sensor cable at or below 5 m between WindSonic and controller interface.
3. Orient the WindSonic north marker to the documented site reference or measure a heading offset.
4. Terminate shield/chassis, field supply, RS-422 pairs, protection, and isolation according to the approved production design.
5. Route data separately from heater current and noisy load wiring.

Heated WindSonic

HazeVane never sources, switches, monitors, or diagnoses heater power. The heated model uses separate installer-provided 10–30 VDC or nominal 24 VAC wiring. Gill recommends a 24 VDC supply capable of the specified startup surge; verify against the current manufacturer manual.

Wired network access

Connect PoE Ethernet to the trusted control network. HazeVane starts with DHCP by default and advertises its hostname over mDNS when supported.

Hostname, DHCP, static address, subnet mask, and gateway form one isolated network draft. They change only when Save & apply network settings is selected—the sole manual save action in the interface. Static IPv4 changes may make the device temporarily unreachable. Version 1 still requires an approved physical DHCP recovery gesture and unreachable-static rollback policy before hardware release.

WindSonic commissioning and health

Commission the sensor before connecting it as the production wind source:

Interface  E2 — full-duplex RS-422
Serial     B3/F1 — 9600 baud, 8N1
Output     P3 — continuous, 4 measurements/second
Message    M16 — NMEA IIMWV with Gill status
Units      U1 — meters/second
Terminator L1 — CRLF

Accepted M16/M5 and corresponding WIMWV messages must have correct XOR checksum, relative bearing, finite direction/speed, supported units, and valid status. Direction is meteorological wind-from bearing. A configured site heading offset is added once, then wrapped to 0–359.999°.

Site and coverage configuration

The infinite canvas stores all geometry in SI units, while the interface can display and accept feet/mph or meters/m/s. X increases east/right and y increases north/up. Fresh configuration defaults to Imperial display.

Canvas objects and gestures

• Site: one centered rectangle; drag any corner to resize symmetrically about the fixed origin.
• Stage and FOH: optional reference rectangles; drag the body to move, any corner to resize, or the front-edge handle to rotate.
• FOH assistance: live front-edge distance, center-axis soft snap, and opposed-front-edge rotation snap. Guides can always be pulled through.
• Coverage: one simple, non-self-intersecting polygon with 3–64 directly movable vertices and edge insertion.
• Hazers: up to ten movable and rotatable fixtures, always inside the site boundary.
• View: pan infinitely, zoom around the cursor, and fit the site inside the unobscured canvas—even with an inspector open.
• Context menu: right-click near a hazer, coverage vertex/edge, reference, coverage interior, or site for appropriate actions.

Do not compensate a mounting offset in both geometry and sensor heading. Keep the WindSonic representative of conditions across the plotted site. Stage and FOH are references only; they do not directly change automatic selection.

Hazers, patching, and scenes

Configure up to ten hazers. Each has a name, enabled state, canvas position, launch heading, directional influence, plume dimensions, selection timing/weight, universe, start address, 1–32-slot footprint, minimum score, and three equal-length DMX scene arrays. New fixtures use sequential names such as Hazer 1 and Hazer 2.

Universe/address ranges cannot exceed slot 512. Output across a maximum of four universes is rendered generically; the controller is not tied to one fixture personality.

Automatic selection behavior

For wind bearing θ, the downwind unit vector is (-sin θ, -cos θ). HazeVane projects a bounded plume from each enabled hazer, scores its contribution to the polygon, qualifies it against the hazer minimum, and applies the selected policy.

Fresh configuration defaults to Best N = 3 and a maximum-active ceiling of 10, automatically bounded by the configured fixture count. Angular hysteresis, score hysteresis, qualification/release delay, minimum on/off time, travel horizon, and maximum active count prevent chatter and unbounded transitions. Canvas inspectors expose plume geometry, score, state, timers, and rejection reasons. Blackout always outranks automatic selection.

sACN output

HazeVane emits standards-formed E1.31 data at a configurable 10–40 packets/second per active universe, with independent sequence numbers, stable CID/source name, priority, multicast mapping, and optional unicast destinations.

• Use dedicated output universes and addresses.
• Choose multicast, unicast, or simultaneous multicast-plus-unicast.
• Up to four unicast IPv4 destinations are supported.
• Configuration apply and shutdown send stream termination.
• Silence or fault does not mean “hold last look”; safe scenes remain explicit output while network is available.

Lighting-console command input

A separate fixed-footprint sACN receiver accepts operator commands without merging console data into hazer output streams.

Defaults: universe 63,999; address 1; minimum priority 100; 2,500 ms timeout; 10,000 ms test duration. A nonzero expected CID locks to one source. Highest-priority arbitration is deterministic; conflicting equal-priority sources fail safe.

Normal operation

1. Confirm Controller online, wind Valid, All changes saved, expected network mode, and safe fixture state.
2. Read the fixed-width wind indicator carefully: degrees and compass text are wind-from; the arrow and Flow toward label point downwind.
3. Confirm canvas geometry and predicted plume motion agree with the physical site.
4. Arm locally, or enable the commissioned console command stream and raise Arm.
5. Observe selected hazers, scores, reasons, state transitions, and actual atmospheric travel.
6. Use blackout immediately for any unexpected behavior. Blackout has highest control priority.
7. Disarm before manual fixture work, network changes, or sensor maintenance.

Fault and fail-safe behavior

Configuration workflow

There is no general Apply, Save, or draft-management workflow. Every non-network canvas, inspector, and settings edit validates, persists, and applies automatically after a short debounce:

1. Make one bounded change and watch the lower-left status move through saving to All changes saved.
2. If a field is invalid, correct its specific inline message; partial configuration never applies.
3. Verify local arm/blackout intent, accepted wind history, parser diagnostics, and unchanged console takeover remain continuous.
4. Export human-readable JSON after an accepted change to create a commissioning record.
5. For hostname/IP changes only, edit the isolated network group and select Save & apply network settings.

Dragging and typing coalesce into one write after activity stops. Configuration JSON is bounded to 24 KiB. Unknown, missing, duplicate, invalid UTF-8, malformed, out-of-range, and cross-field-invalid values are rejected. Persistence uses two CRC-protected slots with generation fallback and transactional schema migration.

Firmware update

The System page accepts an ESP-IDF application image through wired HTTP. The controller validates image metadata and streams to the inactive A/B OTA partition using fixed-size buffers. A successful update reboots into the pending image; the new firmware must confirm itself or rollback remains available.

Diagnostics and local API

The UI exposes wind parser counts, sample age/state, control reasons, network counters, sACN packet counts, console receiver state/source/priority, and source conflicts/timeouts. The versioned API lives under /api/v1.

Mutations require X-HazeVane-Request: 1. There is no authentication; do not route the local API outside the trusted control LAN.

Maintenance and records

• Export the approved configuration after every accepted change.
• Record firmware version, controller MAC/CID, IP, sensor serial/profile, heading reference, fixture patch, and console patch.
• Inspect enclosure seals, PoE, Ethernet, sensor cable, shield termination, protection components, and heater wiring before each deployment.
• Re-test every safe scene and blackout path after fixture firmware/personality changes.
• Repeat packet capture, link-loss, brownout, restart, and soak tests after firmware or hardware changes.

Software limits and defaults

Release status and acceptance gates

The v0.6.2 software baseline runs the same bounded wind, geometry, selection, DMX, sACN output, and command-input core on the host simulator and ESP32-S3 firmware. It includes the infinite canvas, direct site/stage/FOH/coverage/hazer editing, alignment assistance, contextual right-click actions, persistent units, transparent autosave, two-slot persistence, A/B OTA, tests, and grandMA3/GDTF profiles.

Still required before field release

• Production RS-422 isolation/grounding/surge/ESD/termination decision and validation
• Heated/non-heated sensor installation, enclosure, connector, PoE, heater, and thermal acceptance
• Real fixture safe/standby/active DMX confirmation
• Packet capture against production receivers and console acceptance
• Link-loss, brownout, power-interruption, OTA-interruption, watchdog, and long-duration soak tests
• Secure release signing, key protection, and recovery policy
• Physical DHCP recovery gesture and unreachable-static rollback
• Specified diagnostic event ring and persistent boot/fault history