Divjyot ONE
The platform

What Divjyot ONE does

Each part below works on the same records, under the same access rules, in one application. The pictures are simple diagrams; book a demo to see the real screens. Prefer to click around? Take the product tour.

Inventory and floor plans

Know what's where, to the rack unit

Environments, sites, rooms, rows and racks, and every device in them, built on a model catalogue that knows each model's height, ports and power.

  • Floor plans drawn from the real layout, with hot and cold aisles, and tiles labelled the way your hall is (C12 or 03-12).
  • Remote power panels at the ends of rows, on the plan and in 3D, moved by dragging them.
  • Rack elevations: what sits in each unit, front and back, with space and power used.
  • Install, move and remove with a full history of who did what.
  • Search across the estate by name, serial number, asset tag or rack.
A floor plan: rows of racks on a tile grid between hot and cold aisles, with A and B power panels at the ends of rows
Racks

Every rack, with its live conditions

A rack's page shows its elevation, its power against budget, and the latest temperature, humidity and airflow from its sensors, with charts against their alert limits.

A rack elevation: devices by rack unit, beside its space used, power allocated, inlet temperature, A and B power feeds and history
3D digital twin

Walk the room without going there

Each room in 3D, at real positions, from the same records as the floor plan. Colour the racks by space, allocated or measured power, temperature, humidity or airflow.

  • Pop a rack out of its row to see its devices, ports and cables.
  • Drag a device to another rack, then confirm the move.
  • Racks that need a look are listed beside the view, with their alerts.
A data hall in 3D: two rows of racks coloured by space used, one rack lifted out of its row with its details beside it
Cabling and trace

Follow a cable from end to end

  • Ports for every model and device, and cables between them, checked for compatibility (connector, cable type, power direction).
  • A trace from any port through patch panels to the far end.
  • A problem report for each room: paths that stop at a panel, speed mismatches, and devices fed from a single power source or network path.
  • A cable register with each cable's path, and printable labels for both ends.

In the 3D view too

A rack popped out of its row shows its devices' ports and the cables between them, so the patching can be checked before anyone opens the door.

Moves, adds and removals

Move a server, and its cables follow

When a device moves to another rack, from the move dialog, a drag in 3D, the Rack builder, Field ops or a MAC request, its new place is recorded and its cables are taken care of.

  • Cables to the old rack's switch, patch panel and PDUs are re-patched to free ports of the same kind in the new rack, a PDU on the same power side.
  • Cables to other racks stay as they are; any with no free port to match are disconnected and listed for the technician.
  • The dialog shows what will happen to each cable before anything is saved.
  • Every device keeps a location history: where it was and where it went, who moved it, how and why.
  • A log of every add, move and removal for each site and hall, with filters and CSV.
A server moving from rack A03 to rack A04: its cables to the old rack's switch and PDUs re-patched in the new rack, and a cable to another rack kept
Virtualisation

VMs on the hosts and racks they really run on

Clusters, hosts and VMs read from your virtualisation platforms, each host matched to the server it runs on, so a VM's rack, power feeds and business services are a click away.

  • VMware vCenter, Nutanix AHV, Proxmox VE, OpenStack and Kubernetes are read through their APIs with a read-only account. Microsoft Hyper-V sends its inventory over HTTPS from a PowerShell script you schedule. Nothing on the platforms is changed.
  • Hosts matched to devices by serial number, then name, then management address, then MAC address. Anything uncertain waits for a person to decide.
  • A history for each VM: first seen, moved to another host, powered on or off, no longer listed.
  • Each cluster's vCPUs per core and memory against the hosts that can run VMs now, and whether it would survive losing a host.
  • Power per VM and by tenant, and where new VMs can go with the largest host held back.

Each platform is tested against a simulated version built from its published API. We check it with yours when you start.

A cluster's hosts and their VMs, read from the virtualisation platform and matched to the servers in a rack, with what a power failure would take down
Service management

A service desk that knows the hardware

Incidents, requests, changes and problems, each linked to the devices, racks and business services involved.

  • SLA clocks, approvals and escalations.
  • A request catalogue with forms, and a knowledge base.
  • Move, add and change control; maintenance schedules and a calendar.
  • A Work Board for the team, with in-app and email notifications.
A service desk board: tickets by state with priorities and SLA clocks, an incident linked to its rack, devices and business services
Automation and runbooks

Rules and runbooks, set up without code

Automation rules act when something happens. Runbooks take the desk through a procedure, step by step.

  • When a ticket is raised, changed or replied to; an alert opens, turns critical, escalates or clears; or a device is registered, changed, moved or archived.
  • If its type, priority, site, rack, severity, kind of equipment or the words in its title match, then notify people, raise an incident, set impact and urgency, assign it, add a work note or start a runbook.
  • Try it checks a rule on a real record and changes nothing. Every run is in the record's history.
  • Runbooks of up to 30 steps: tasks, approvals given by someone other than the person who started it, and actions Divjyot ONE does when the run reaches them.
An automation rule: when an alert becomes critical, if the site is unstaffed, then raise an incident, notify and start a runbook; the runbook beside it with one step done, one waiting for approval and one an action it does itself
Monitoring and alerts

Readings from your sensors, alerts that make sense

  • Collect from your sensors, meters and building management systems with our reference collector, Telegraf or the ingest API; each source has its own token.
  • Equipment polled over SNMP, Modbus and Redfish with templates for common models, and building management systems over BACnet. New templates read Legrand PDUs through their JSON-RPC API and coolant distribution units through Redfish; both are tested against simulated devices so far.
  • Map sensors to racks, and see temperature, humidity and airflow on the dashboard and in 3D.
  • Alert rules with a breach duration and a clear margin, so flapping readings don't flood you.
  • Early warnings from trends, alerts when a source goes silent, and incidents raised for you.
  • Unusual readings: sensors reading unusually for themselves at that time of day, even inside every alert limit.
A temperature trend rising toward its limit, with an early warning that raises an incident on the rack
Edge sites and collectors

Every site on one map, worst first

Sites on a map, coloured by how each is doing, with unstaffed sites ringed. Below it, one line per site says why.

  • The reasons: critical alerts, UPSs on battery, inlet air, silent collectors, power against the facility limit, cooling zones at risk, open incidents, and, for unstaffed sites, when someone was last there.
  • Each site marked staffed, staff on call or unstaffed.
  • Every collector in one list: sending, late or silent, the site it serves, its version and machine, and what failed in its last round.
  • BACnet/IP read by the reference collector itself, directly or through a BACnet router, with the points to read sent from Divjyot ONE each round. Tested against a simulated BACnet device; we check it with your building management system when you start.
A map of sites coloured by how each is doing, unstaffed sites ringed, beside a list of sites worst first with the reason for each, and a count of collectors sending, late and silent
Power and capacity

Know your limits before you reach them

  • The power chain per site, from utility and generators through switchgear and UPS to panels and breakers, with A and B sides.
  • Loads in normal running and with either side lost, against derated limits.
  • Facility meters and measured PUE.
  • Capacity alerts on breakers, rack budgets, cooling and ports; deployment plans with projections; a rack power calculator.
  • Failure impact: what a UPS, panel, breaker, rack PDU or rack failing would take down, through to hosts, VMs, Kubernetes pods and business services.
  • Each device's, host's and VM's power path, feed by feed, up to the source.
A power chain: utility and generator to switchgear, A and B UPSs and row-end panels, each rack fed from both sides
Capacity

Space, power and cooling against what's planned

Each site's IT power and heat load against its limits, including the deployments you've planned, so you can say yes to the next project with the numbers in front of you.

  • Placement: where a batch of equipment can go, judged on space, the rack's budget, its breakers and power nodes with a side lost, cooling and free ports. Spread it out or fill the fullest racks first, then save it as a deployment plan.
  • Change simulation: whether a deployment fits a rack before anything is unboxed.
  • A cluster's room to grow: how many more hosts like its own its racks can take.
Capacity: space, power and cooling used against their limits, with planned work shown before it arrives
Cooling

Cooling zones that know their redundancy

The cooling units in each part of a room, and the plant that serves each site, against the load of the racks they cool.

  • CRAHs, CRACs, in-row coolers, rear-door heat exchangers and coolant distribution units in zones; chillers and dry coolers as a site's plant.
  • Each zone built for N, N+1, N+2 or 2N: what's in service, what its redundancy keeps spare, and what's left for its racks, measured where they report.
  • Alerts when a zone is no longer redundant, near its limit, or over what its units in service carry.
  • Forecasts, the change simulation and placement count the zones you've set up.
  • Each unit's make, model, refrigerant, warranty and service interval, with services due in the priorities list.
A cooling zone covering three rows of racks with four cooling units, one in maintenance; its capacity shows the load above what's usable with one unit kept spare, so the zone is no longer redundant
Forecasts and priorities

See what runs out, and what to do first

  • Forecasts of when racks, rows, rooms and sites will run out of power, space, cooling or network ports, from the daily snapshots: the trend, any weekly pattern, and a likely range.
  • Failure risk: equipment ranked by signs that tend to come before a failure, such as age, an ended warranty, failed parts, recent incidents and unusual readings, with every reason shown. It's a ranking by stated rules, not a trained model.
  • Decision support: what needs attention first, in four groups from act now to keep an eye on, each item with why it's there and where to look.
A capacity forecast: a room's power rising over the last months and forecast ahead with a widening likely range, reaching 80 % and then full in about eleven months
Field operations

The floor team's phone is a scanner

  • Scan with handheld readers, the phone's camera (barcodes and QR codes) or NFC.
  • Keep working without a signal: work done offline is sent once, exactly once, when it returns, and conflicts are the technician's to decide.
  • Confirm locations, installs and moves; receive expected deliveries at the dock.
  • Rack audits, with incidents from what they find; printable asset labels.
Field ops on a phone: scanning an asset label, working offline with actions queued to send once the signal is back
Vendors, purchasing and spares

From purchase order to installed device

  • Purchase orders approved by someone other than the requester; equipment on them becomes expected deliveries.
  • Invoices matched line by line against the order and what arrived.
  • Contracts, warranties and software licences, with renewal reminders 90 and 30 days ahead.
  • Cost per device, hidden from roles without cost access; spare parts as stock per site and bin.
  • The IT estate: cloud resources and software licences, with their costs and the devices they're linked to. Cloud resources can be read from AWS, Azure and Google Cloud.
From purchase order to installed device: an approved order, the delivery received, the server in its rack, and the invoice matched with its warranty
Reports and dashboards

Answers for the people who ask

  • Hardware lifecycle, asset utilisation, space and power with a floor heat map, service performance, and spend.
  • As pages, CSV and PDF, or by scheduled email, each built under the reader's own access.
  • Personal and shared dashboards that show only what each viewer may see.
A space and power report with a bar chart and a floor heat map, available as PDF, CSV or a weekly email
Integrations

Works with what you already have

Bring your data in once, and keep the other tools your teams use in step.

Imports

From spreadsheets and other DCIM and CMDB tools, with a preview of every row before anything changes, and undo.

Discovery

Collectors in your network read SNMP and LLDP and send what they find to an inbox, matched to your records for you to accept. Partner connectors can send to it too.

Virtualisation

VMware vCenter, Microsoft Hyper-V, Nutanix AHV, Proxmox VE, OpenStack and Kubernetes, read-only, into one inventory of clusters, hosts and VMs.

Cloud resources

Instances and databases read from AWS, Microsoft Azure and Google Cloud into the IT estate. They're read-only and tested against simulated services; what each reads, and how.

Service tools and chat

ServiceNow, Jira and Salesforce connections, signed webhooks, Microsoft Teams and Slack channels, and read-only API tokens.

Finance

Exports of purchase orders, invoices and assets as CSV and JSON, and in formats for Tally, SAP, Microsoft Dynamics 365 and Oracle.

Single sign-on

Your identity provider over OpenID Connect: Microsoft Entra ID, Okta, Google and others. Roles come from its groups.

Access and audit

Roles per environment, a colocation mode that keeps tenants apart, an access review you can download, and a full audit trail.

Partner connectors

A connector SDK lets a partner add a system without changing Divjyot ONE: a small web service with a manifest, a test and a read.

See it for your sites

Book a demo, or ask us how your current spreadsheets and tools would come across.

Book a demo Compare the plans