Reference · built on requestOperator by FibricFacilities & comfort

Restroom Service

Counts restroom traffic and dispenser levels and proposes a service visit when a threshold is reached.

Request accessPricing ↗

About

Restrooms are cleaned on a clock. The one by the conference centre is serviced as often as the one on a quiet floor, and both are checked whether or not anyone went in. Restroom Service replaces the clock with a count. It reads entries from people-counting sensors at each door, over LoRaWAN or from an MQTT broker, and fill or empty reports from dispenser sensors and counting touch buttons where you have them.

When a restroom passes the visit count or a dispenser reports empty, it proposes a service task in your work-management system for the attendant on shift and a short notice to their channel. A supervisor approves the task. It does not send anyone anywhere on its own.

This is a reference listing. It documents what Fibric would read from Restroom Service 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

  • Bi-directional entry and exit counts from door sensors such as the Milesight VS133, which supports up to 4 detection lines, over LoRaWAN
  • Counter and event uplinks on subscribed MQTT topics, with per-topic freshness so a silent counter is noticed
  • Dispenser fill-level or empty reports from any sensor that publishes them over LoRaWAN or MQTT, as the device reports them
  • touchCount events from Disruptive Technologies counting touch sensors placed as service-request buttons, sent at each heartbeat
  • Open and completed restroom tasks in Jira Service Management, ServiceNow, or Corrigo, so a restroom already assigned is not assigned twice
  • Device battery and last-seen freshness per sensor, so a dead sensor is reported instead of read as no traffic

Proposed actions

  • Target capability: propose a service task for a restroom once entries since the last completed task pass the count you set
  • Target capability: propose an immediate task when a dispenser reports empty or a request button is pressed, ahead of the count
  • Target capability: propose a notice to the attendant's channel with the restroom, the count, and the reason, linked to the task
  • Target capability: propose a change to a restroom's count threshold when tasks are completed with little to do, or complaints arrive before them
  • Target capability: propose a sensor check when a counter stops reporting or a dispenser sensor reads full through a busy day

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

What you can build

  • Service the busy restroom first

    Milesight counters over LoRaWAN show one restroom far above its neighbour's traffic. The operator proposes a Jira Service Management task when it passes the threshold and a Teams notice to the attendant, and leaves the quiet one on its count.

    With Milesight Development Platform, LoRaWAN Network, Jira Service Management, Microsoft Teams

  • Answer a request button

    A Disruptive Technologies counting touch sensor by the door acts as a request button. A press raises an immediate Corrigo work order for the attendant on shift, with the restroom and time, once a supervisor approves it.

    With Disruptive Technologies, Corrigo Enterprise

  • Catch the empty dispenser before the complaint

    A dispenser sensor publishes an empty state on an MQTT topic. The operator proposes a ServiceNow task ahead of the count and a Slack notice, and notes the restroom's last service time beside it.

    With MQTT Broker, ServiceNow, Slack

Requirements

  • A people counter at each restroom entrance reporting over the LoRaWAN Network or MQTT Broker connector, or through the Milesight platform
  • A work-management connector such as Jira Service Management, ServiceNow, or Corrigo, with a queue or work zone for restroom service
  • A messaging connector for attendant notices, and a per-restroom count threshold to start from
  • Dispenser sensors or request buttons are optional; without them the operator works from counts alone
Authentication
Reads sensor uplinks through your LoRaWAN network server key or MQTT broker credentials, reads device events through each sensor vendor connector, and files tasks and notices through the accounts your work-management and messaging connectors hold.

Limits

  • A door counter counts people, not what they used. Two restrooms with the same count may need different work.
  • Dispenser levels are read only from sensors that report them. Dispensers without sensors are serviced on the count.
  • It proposes tasks and notices. It does not assign shifts, page an attendant directly, or close a task; the attendant does.
  • Counters at a shared vestibule count the corridor too. Placement is a site decision the operator cannot correct for.

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 Restroom Service ↗

Questions and answers

What does a person approve?
Each service task, notice, threshold change, and sensor check. The proposal shows the restroom, the count since the last service, any dispenser or button event, and the task text. A supervisor approves, edits, or dismisses it; routine tasks can be approved from the notice.
What record is left?
A receipt per proposal: the counts and events behind it, the task id in your work-management system, the notice sent, who approved it, and when the task was completed. Dismissed proposals stay on file with the reason.
What does it never do on its own?
It never files a task, sends a notice, changes a threshold, or marks a restroom serviced without an approval. It reads counters and dispenser reports, keeps the tally per restroom, and waits.
Ask about Restroom Service

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