Reference · built on requestOperator by FibricFacilities & comfort

Occupancy Lighting

Compares lighting state with measured occupancy by area and proposes schedule and scene changes for empty floors.

Request accessPricing ↗

About

Lighting schedules are set at fit-out and rarely revisited. A floor that empties at six still runs its daytime scene until the schedule says otherwise, and a wing a team vacated last quarter is lit every evening for nobody. Occupancy Lighting reads the current scene and dim level of each DALI group from your lighting gateway and sets it beside what the building measures: occupancy sensors reporting over DALI-2, BACnet/IP, or LoRaWAN, zone counts from camera vision, and badge counts from access control.

Where an area has been lit and empty for the period you set, it proposes a scene change, a schedule edit, or a shorter hold time for that group. You approve each one. It never dims a light on its own.

This is a reference listing. It documents what Fibric would read from Occupancy Lighting and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Scene state and dim level per DALI group and zone, read through your DALI gateway, along with lamp and driver failure reports
  • Occupancy and vacancy events from DALI-2 occupancy sensors (IEC 62386-303), which report a change to occupied, vacant, movement, or no movement
  • Zone occupancy state and COV change events on subscribed objects over BACnet/IP, timestamped at the change
  • Motion and presence uplinks from LoRaWAN occupancy sensors, with battery level and last-seen freshness per device
  • People counts and zone entry and exit transitions from camera vision, computed on-site from configured RTSP feeds
  • Credential use by door and time from access control, as a count of who is on a floor and when it emptied
  • The lighting schedule in force for each group, so a lit area is judged against what the schedule intended

Proposed actions

  • Target capability: propose recalling a lower scene or dim level for a DALI group lit with no occupancy for the period you set
  • Target capability: propose a schedule edit for a group whose measured occupancy ends earlier than its lighting schedule, week after week
  • Target capability: propose returning a group to its schedule after a manual override has outlived the occupancy it was set for
  • Target capability: propose a shorter or longer hold time for an area where sensors report vacancy well before or after the lights change
  • Target capability: propose a review list of areas lit every evening with no badge or sensor activity, for someone to decide on

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Dim an empty floor after hours

    DALI-2 occupancy sensors report vacancy on a floor whose evening scene is still lit. The operator proposes recalling the night scene for those groups through the DALI gateway, and you approve it from the notice.

    With DALI Lighting, Microsoft Teams

  • Fix a schedule that outlives the tenants

    BACnet/IP occupancy objects on a wing show it empty from five o'clock every weekday while its lighting schedule runs to eight. The operator proposes a schedule edit for those groups, with the readings attached.

    With BACnet / IP, DALI Lighting

  • Use badge counts where there are no sensors

    On floors with no occupancy sensors, access control shows the last badge-in of the day. The operator proposes a review list of groups still lit long after it, and you decide which schedules to change.

    With Access Control, DALI Lighting

  • Count a lobby with camera vision

    Camera vision reports zone counts for a lobby and a corridor. When both read zero for the period you set, the operator proposes the corridor's unoccupied scene and leaves the lobby on its schedule.

    With Camera Vision (RTSP), DALI Lighting

Requirements

  • A DALI Lighting connector addressing a DALI-to-IP gateway, with the groups and zones the operator may propose changes for on its allow-list
  • At least one occupancy source: DALI-2 occupancy sensors, BACnet/IP occupancy objects, LoRaWAN motion sensors, or camera vision zones
  • An Access Control connector if badge counts are to stand in for sensors on floors that have none
  • A map from each lighting group to the area and the sensors that cover it
Authentication
Reads scene and sensor state through the credentials your lighting, building, sensor, and access connectors already hold, and sends proposed scene and schedule changes through the DALI gateway connector's allow-listed groups; it holds no credentials of its own.

Limits

  • It reads occupancy as the sensors report it. A sensor that cannot see a desk pod reports vacancy, and the operator will propose dimming it.
  • Scene and dim changes go only to allow-listed groups, within the bounds set at the gateway. Emergency and egress lighting is out of scope.
  • Camera vision reports counts per configured zone and needs an edge node on-site; it does not identify people.
  • Badge counts show who entered a floor, not who has left it. They are a floor-level signal, not a room-level one.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Occupancy Lighting ↗

Questions and answers

What does a person approve?
Every scene recall, dim level, schedule edit, and hold-time change. The proposal names the group, the area, the sensors or badge data that showed it empty, and the change. You approve it as written, edit the target, or dismiss it.
What record does it leave?
A receipt for each proposal, kept whether it was approved or dismissed: the occupancy evidence, the scene or schedule before and after, who approved it, when it was sent to the gateway, and how to return the group to its previous state.
Does it ever change a light on its own?
No. It reads lighting and occupancy state and writes nothing until a person approves a proposal. An approved change is sent to the gateway once, to allow-listed groups only, and never to emergency lighting.
Ask about Occupancy Lighting

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy