Showcase
Beam is the platform we build in-house for Helvar sites. BeamUI commissions them from a browser, BeamWatch watches every router around the clock, and BeamEdge is the small box on site that runs it all and hands the building management system clean lighting data.
A site unit for Helvar lighting control
A compact Linux unit, the same hardware class as our Remote Commissioning Unit, that sits on the lighting network and runs BeamWatch. It monitors every router around the clock, keeps the history on site, serves the BMS over BACnet/IP and MQTT, and gives our engineers a secure link for support. It works fully offline.
Reads
BeamEdge
Serves
BeamUI is how we commission Helvar systems: group, name, configure and identify devices from a browser on a laptop, tablet or phone, instead of from one desktop on a cable. It works with your own Helvar Designer installation, so the design file stays the source of truth.
Walk the site with a phone, identify a fitting, name it and drop it into its group on the spot. The engineer on the ladder and the one at the desk see the same live view.
Routers, subnets, devices, groups and scenes in one page, with levels and faults as they are now, not as they were drawn.
Every change is written, read back and logged, so you know what the site holds rather than what someone meant to send.
Open a Helvar design file without a router attached and prepare the job before anyone is on site.
BeamUI is available to commissioners with a licensed Helvar Designer. Remote commissioning is provided by Luxtron.
BeamWatch is the always-on part of Beam. It reads the routers through Helvar’s published integration protocol, only ever asks questions and never sends a command, so it can run on a live building from day one.
Every router, subnet and device, with a status timeline. Lamp failures, missing devices and comms faults show up as events with a time stamp, not as a surprise during a walkround.
Hours and levels per device and group, and an energy figure per area. Helvar routers do not report measured power per fitting, so we label the energy figure as an estimate and show how it is worked out.
Every fault is kept, so you can see which driver types and which floors fail most, and how long fittings run between failures.
Lights on overnight, areas lit out of hours, rooms that are never used, devices that keep dropping off the bus. The things that waste energy or hint at a wiring fault.
A short report every week for the facility team, with an optional plain-language summary written by AI from the same data.
History is stored on the unit itself, more than a year of it by default, in plain files you can open. Nothing needs the cloud.
Most BMS integrations stop at a hand-typed points list. Beam builds the lighting points from the commissioning data itself, so names and rooms in the BMS match the site.
Group levels, last scene, device status, subnet status and estimated energy, published as BACnet objects and MQTT topics. Read-only, so the BMS can watch the lighting without being able to break it.
Scene recall, group levels and off from the BMS, through an allow-list you approve point by point, with a login and an audit log of every command.
For SCADA systems and older BMS front ends that only speak Modbus.
Planned: AI proposes object names and tags from the room and device data, or maps an existing BMS points list onto the site. A person checks the table before anything goes live.
AI in Beam drafts, it does not decide. Every change it suggests is shown as a plan with a before and after, and only runs once a person approves the whole plan. Each step is checked against the router afterwards and logged.
Next, in BeamUI: turns a brief in plain language into grouping, naming and scene changes, shows the result as a before and after, then applies it in one approved step.
Next: reads the diagnostics and suggests the likely cause and the next check: one missing driver, a whole line down, an address clash, a power supply near its limit.
Planned: a handover pack with the device schedule, scenes per room and a written sequence of operations, where every sentence points back to the setting it describes.
Planned: “why is meeting room 4 on at night?” answered from the schedules and the event history, with control limited to the areas and actions a role is allowed.
NowRunning today
NextIn build
LaterPlanned
Monitoring never writes to the lighting. Control is a separate, opt-in step with an allow-list.
AI proposes plans. Nothing changes on site until someone signs off the whole plan.
Everything runs on site. The optional AI features are the only thing that calls out, and they can use a local model instead.
Where the hardware cannot measure something, like per-fitting power, we say it is an estimate.
Running a Helvar site, or planning one? Ask us about BeamEdge for monitoring and BMS integration.