Reference · built on requestOperator by FibricEnergy & demand

Fuel Reserve

Reads tank level sensors, generator run hours, NWS alerts, and open purchase orders, and proposes a fuel delivery when reserve runs short.

Request accessPricing ↗

About

A standby generator is only as ready as the fuel in its tank, and the tank is checked less often than the weather changes. Tank-level sensors report over LoRaWAN or Modbus TCP, run hours tick up in the controller, and the purchase order for the next delivery lives in NetSuite.

Fuel Reserve reads each tank's level and the sensor's own battery and last-seen time, the generator's run hours and fuel rate as the controller reports them, active NWS alerts for the site, and open purchase orders to your fuel vendor. It keeps a running estimate of hours of fuel on hand against the reserve you require, and proposes a delivery, drafted as a NetSuite purchase order, when the estimate falls short or a storm alert would draw it down. You approve the purchase order, and the receipt keeps the level, the estimate, and the order.

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

  • Tank-level uplinks from the LoRaWAN network server, delivered as JSON by webhook or MQTT, with gateway metadata and timestamps
  • Sensor health from the same uplinks: battery level, signal quality, and last-seen freshness per device
  • Tank level, run hours, and fuel rate registers from the generator controller over Modbus TCP, where the tank is wired to it
  • Active NWS watches and warnings for the site's zone, as the trigger for a larger reserve
  • Open purchase orders to the fuel vendor from a NetSuite saved search, with expected dates and quantities
  • The reserve you require in hours or gallons per site, and each tank's capacity and usable volume

Proposed actions

  • Target capability: propose a fuel delivery as a purchaseOrder through NetSuite REST web services, with the vendor, quantity, and requested date filled in
  • Target capability: propose expediting an open purchase order when a storm alert shortens the time the reserve will last
  • Target capability: propose a sensor check when a tank stops reporting or its battery level falls, so a silent tank is not read as full
  • Target capability: propose a level reconciliation when the delivery ticket and the sensor's rise after delivery disagree
  • Target capability: propose a review when run hours rise with no matching drop in level, which points to a stuck sensor or a bypassed tank

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

What you can build

  • Order diesel before the storm draws it down

    Read tank levels over LoRaWAN, run hours from the controller over Modbus TCP, and the NWS warning for the site, and get a proposed NetSuite purchase order sized to restore the reserve before the alert window.

    With LoRaWAN Network, Modbus TCP, Weather & Severe Alerts, NetSuite

  • Find the tank that stopped talking

    When a tank's uplinks stop or its battery falls, the operator proposes a sensor check in MaintainX rather than reading the last level as current.

    With LoRaWAN Network, MaintainX

  • Check the delivery against the sensor

    After a delivery posts against the purchase order, the level rise from the sensor is compared with the ticket, and a mismatch becomes a proposed reconciliation.

    With LoRaWAN Network, NetSuite

Requirements

  • A LoRaWAN connector with tank-level devices decoded by the network server, or a Modbus TCP connector reaching a controller that reads the tank
  • A NetSuite connector with a saved search for open purchase orders to the fuel vendor and a role allowed to create purchase orders
  • The NWS weather signal with each site's location
  • Tank capacity, usable volume, the reserve you require, and the generator's fuel rate, written down per site
Authentication
Reads the LoRaWAN network server with the API key your connector holds, reads the controller through the Modbus connector's register allow-list, reads NWS with no key, and drafts purchase orders under the NetSuite token-based authentication role you scope.

Limits

  • Hours of fuel on hand is an estimate from level, capacity, and the fuel rate you supply. Load, temperature, and tank shape move it.
  • A LoRaWAN uplink that stops arriving is treated as unknown, not full. The proposal then asks for a sensor check before a delivery.
  • NetSuite REST does not expose every purchase order sublist. Fields the record service withholds are left for your team to complete.
  • It drafts the purchase order. It does not approve it, send it to the vendor, receive the delivery, or pay the invoice.

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 Fuel Reserve ↗

Questions and answers

What does a person approve before fuel is ordered?
The purchase order draft: the site and tank, the level and hours-on-hand estimate behind it, the alert if one triggered it, the vendor, quantity, and requested date. You can change the quantity or date, approve it into NetSuite, or dismiss it. The vendor sees nothing until your own approval flow sends it.
What record is left after a delivery?
A receipt per proposal: the sensor readings and their timestamps, the run hours and fuel rate used, the estimate, the NetSuite purchase order id if approved, who approved it, and the level after delivery. Sensor-check and reconciliation proposals keep the same record.
Does it ever order fuel without asking?
Never. Every purchase order is a draft that needs an approval, and the operator creates it in NetSuite only after that approval. It never marks an order approved, changes the vendor, or receives the delivery.
Ask about Fuel Reserve

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