Question 1

What is xSERVA?

Accepted Answer

xSERVA is a unified building automation platform from VYROX that brings BACnet, KNX, MQTT, and Modbus devices into a single system for monitoring, control, energy management, and AI-driven insight, instead of running separate siloed tools for each subsystem.

Question 2

What is the difference between a BAS, a BMS, an EMS, and xSERVA?

Accepted Answer

A Building Automation System (BAS) typically refers to the control layer that automates HVAC, lighting, and access. A Building Management System (BMS) is the broader monitoring and management layer sitting over that control layer. An Energy Management System (EMS) focuses specifically on consumption, demand, and efficiency. xSERVA unifies all three functions, automation, management, and energy optimization, plus AI-driven intelligence, on one data model instead of requiring separate BAS, BMS, and EMS products that each need their own integration work.

Question 3

Who is xSERVA built for?

Accepted Answer

xSERVA is built for the full lifecycle of a building automation project: property developers and architects specifying systems at design stage, system integrators deploying and commissioning installs, building owners and operators running sites day to day, enterprise and corporate teams standardizing across a portfolio, and government and institutional customers meeting compliance and reporting obligations.

Question 4

Is xSERVA a hardware product or software?

Accepted Answer

xSERVA is software. It runs on top of existing or newly installed BACnet, KNX, MQTT, and Modbus field devices and controllers rather than replacing that hardware, unifying the data those devices already produce into one platform.

Question 5

How is xSERVA different from a traditional single-protocol BMS?

Accepted Answer

A traditional BMS is typically built around one protocol, most often BACnet, and treats anything outside that protocol as a separate system requiring its own screen, login, and reporting. xSERVA is architected from the ground up to treat BACnet, KNX, MQTT, and Modbus as equal first-class citizens on one core engine, so a lighting scene, a chiller setpoint, and a sensor reading all live in the same data model instead of three disconnected ones.

Question 6

What size or type of building is xSERVA suited for?

Accepted Answer

xSERVA is built for sites of any size, from a single building to a large multi-site portfolio, on the same underlying architecture. Whether a specific building type is a good fit depends on the mix of systems and protocols in play, which our team can assess during scoping.

Question 7

Can xSERVA manage multiple buildings or sites from one console?

Accepted Answer

Yes. xSERVA supports multi-site and portfolio management natively, so a single-building deployment and a much larger portfolio run on the same core engine, with per-site detail and portfolio-wide views available from one console.

Question 8

Do I need to replace my existing BMS to adopt xSERVA?

Accepted Answer

Not necessarily. xSERVA is commonly deployed alongside or on top of existing BACnet, KNX, MQTT, or Modbus infrastructure, connecting to what is already installed rather than requiring a full rip-and-replace. Our team assesses your existing system during scoping to confirm the right path.

Question 9

Can xSERVA mix BACnet, KNX, MQTT, and Modbus on the same site?

Accepted Answer

Yes. Mixed-protocol support is the core premise of xSERVA. A single deployment can bring in BACnet controllers, KNX lighting and blinds, MQTT sensor telemetry, and Modbus meters or generators, and present them all through one unified data model, dashboard, and rule engine.

Question 10

Does xSERVA support legacy or older field devices?

Accepted Answer

xSERVA is designed to work with existing BACnet, KNX, MQTT, and Modbus devices already installed on a site, not just new hardware. Compatibility with a specific legacy controller or device generation depends on the device speaking a supported protocol correctly, which our team verifies during project scoping.

Question 11

Do I need extra gateway hardware to connect different protocols?

Accepted Answer

It depends on the site. Some protocols connect directly over IP or existing wiring, while others may need a protocol gateway or interface device to bridge into xSERVA. Our team assesses the existing network and device inventory during scoping and specifies any gateway hardware required as part of the deployment plan.

Question 12

Does xSERVA support protocols beyond BACnet, KNX, MQTT, and Modbus?

Accepted Answer

xSERVA natively supports BACnet (IP and MS/TP), KNX, MQTT, and Modbus (TCP and RTU). These four cover the large majority of building automation, lighting, IoT sensor, and metering scenarios we encounter; we do not claim support for additional protocols beyond this set today.

Question 13

What happens if a device uses a protocol xSERVA doesn't natively support?

Accepted Answer

For a device outside BACnet, KNX, MQTT, and Modbus, the typical path is a gateway or bridge that translates that device's native protocol into one of our four supported protocols, most often Modbus or MQTT. Our team reviews the device datasheet during scoping and specifies whether a gateway is needed and which one fits.

Question 14

How deep is xSERVA's support within each protocol, not just at the connection level?

Accepted Answer

xSERVA reads and writes at the level each protocol actually operates at, not just a surface-level connection: BACnet at the object and property level, KNX at the group-address and datapoint-type level, MQTT at the topic and payload level, and Modbus at the register level. That depth is what lets the platform expose meaningful points and controls rather than a generic pass-through.

Question 15

What happens if a connected device goes offline?

Accepted Answer

xSERVA monitors the health of connected devices and points, and a device that stops reporting is flagged as offline or stale rather than silently showing a frozen last value. Depending on configuration, an offline device can also trigger an alarm so the issue gets attention rather than going unnoticed.

Question 16

How does xSERVA handle conflicting commands between protocols or systems?

Accepted Answer

Because BACnet, KNX, MQTT, and Modbus points are unified into one data model and rule engine rather than four separate systems, xSERVA's automation logic and access control govern which commands are allowed and in what priority, reducing the risk of two systems fighting over the same piece of equipment the way disconnected point solutions can.

Question 17

How does predictive maintenance work in xSERVA?

Accepted Answer

xSERVA applies machine learning models to live equipment data, runtime hours, vibration, temperature, and performance trends, to flag equipment that is drifting toward failure before it actually fails, so maintenance teams can act on a schedule rather than reacting to a breakdown.

Question 18

What does anomaly detection actually catch?

Accepted Answer

Anomaly detection compares live readings against learned normal operating patterns for each point and asset, surfacing things like an AHU drawing unusual power, a sensor reporting an implausible value, or a zone drifting outside its expected temperature band, so issues get flagged before they become complaints or failures.

Question 19

Can I ask xSERVA questions in plain language?

Accepted Answer

Yes. xSERVA supports natural-language querying of live building conditions, so an operator can ask something like "which zones are over setpoint right now" and get a direct answer instead of building a custom report or dashboard first.

Question 20

Does the AI replace the need for a facilities team?

Accepted Answer

No. xSERVA's AI is designed to make a facilities team more effective, by surfacing what needs attention and predicting problems earlier, not to operate a building unattended. Decisions and physical maintenance work still sit with your team.

Question 21

How much historical data does the AI need before it becomes useful?

Accepted Answer

Anomaly detection and predictive models improve as they observe more of a building's normal operating patterns, so accuracy builds up over an initial onboarding period after go-live rather than being instant on day one. Basic monitoring, dashboards, and manual alarms are available from day one regardless, with AI-driven insight sharpening as live data accumulates.

Question 22

Can non-technical staff use the natural-language query feature?

Accepted Answer

Yes, that is the point of it. Natural-language querying is designed so an operator without a technical or data-analysis background can ask a plain question about current building conditions and get a direct answer, without needing to build a report or understand the underlying data structure first.

Question 23

What happens when the AI flags a false positive?

Accepted Answer

Operators can review and dismiss a flagged anomaly or alarm directly in xSERVA, and that feedback informs the model's understanding of what counts as normal for that point going forward, so the system is designed to get more accurate for a given site over time rather than repeating the same false positive indefinitely.

Question 24

Does the AI make automated changes to equipment on its own?

Accepted Answer

AI-driven insight is focused on detection and prediction, flagging what needs attention, rather than silently taking control actions without human involvement. Any automated control logic is configured explicitly by your team through xSERVA's rule engine, so what the system is allowed to do automatically stays within limits you set.

Question 25

How much can xSERVA save on energy costs?

Accepted Answer

Savings depend heavily on the building's existing equipment, occupancy pattern, tariff structure, and how much optimization headroom exists before xSERVA is deployed. Any percentage or figure shown on marketing materials is an illustrative example, not a guarantee, and we will replace illustrative figures with verified customer case studies as they become available.

Question 26

Can xSERVA produce ESG or sustainability reporting?

Accepted Answer

xSERVA continuously tracks consumption, demand, and load data across connected systems, which is the underlying data most ESG and sustainability reporting frameworks require. Report formatting needs vary by organization and framework, and our team works with customers directly to align exports with their specific ESG reporting requirements.

Question 27

Does xSERVA align with Green Building Index or Green Mark requirements?

Accepted Answer

xSERVA is built to align with the kind of continuous energy monitoring, metering granularity, and reporting that certification frameworks like the Green Building Index (GBI) and Green Mark look for. We do not claim that installing xSERVA automatically confers a specific certification; certification is assessed and awarded by the relevant certifying body based on the whole building, not the software alone.

Question 28

Can xSERVA manage energy across multiple buildings at once?

Accepted Answer

Yes. xSERVA's multi-site management supports portfolio-wide energy reporting alongside per-site detail, so an enterprise or corporate team can compare consumption and identify outliers across a growing real-estate portfolio from one console.

Question 29

What is a typical payback period for energy savings from xSERVA?

Accepted Answer

Payback period depends on the building's existing equipment efficiency, tariff structure, and optimization headroom, so there is no single figure we quote as a guarantee. Any timeline shown in marketing materials is an illustrative example only; our team can work through a scoped estimate for your site once we understand your consumption profile.

Question 30

Does xSERVA work with the utility meters already installed on site?

Accepted Answer

xSERVA is designed to connect to existing Modbus-based utility and sub-meters already installed on a site rather than requiring new metering hardware in every case. Where a meter cannot be read directly, our team scopes what additional metering, if any, is needed during project planning.

Question 31

Can xSERVA detect equipment degrading before it actually fails or wastes energy?

Accepted Answer

Yes, this is part of what predictive maintenance and anomaly detection are built for: catching gradual efficiency drift, such as a chiller drawing more power for the same cooling output, before it becomes an outright failure or a quietly inflated energy bill.

Question 32

Does energy optimization require occupants to change their behavior?

Accepted Answer

No. Most of xSERVA's energy optimization works at the system level, scheduling, setpoint tuning, and demand management, without requiring occupants to do anything differently. Some customers choose to pair this with occupant-facing dashboards or nudges, but that is optional, not a requirement for savings.

Question 33

How does xSERVA approach OT cybersecurity?

Accepted Answer

xSERVA treats building operational technology (OT) as a distinct security domain from standard IT, applying network segmentation, encrypted transport where the underlying protocol supports it, and role-based access control, rather than assuming building-network traffic is inherently trusted.

Question 34

Is xSERVA compliant with PDPA?

Accepted Answer

xSERVA is designed with data minimization, access control, and encrypted storage and transport in line with Malaysia's Personal Data Protection Act (PDPA) principles for the operational data it handles. See the Security & Compliance page for the full detail on how this is implemented.

Question 35

How does access control work in xSERVA?

Accepted Answer

Access is role-based: users see and act on only the sites, zones, and functions their role grants, and every control action taken through the platform is logged with a user, timestamp, and target, giving operators and auditors a clear trail of who did what.

Question 36

What happens if a device or connection is compromised?

Accepted Answer

Network segmentation limits how far a compromised device or connection can reach within the wider system, and anomaly detection can flag unusual traffic or command patterns for review, reducing both the blast radius and the time to notice something is wrong.

Question 37

Is data encrypted in transit and at rest?

Accepted Answer

Yes. Every connection between field devices, the core engine, and user-facing dashboards runs over encrypted transport where the underlying protocol supports it, using mechanisms such as BACnet/SC, KNX Secure, and encrypted Modbus tunneling, and data at rest is encrypted as well. See the Security & Compliance page for the full breakdown by protocol.

Question 38

What is xSERVA's incident response process if something goes wrong?

Accepted Answer

Every control action and system event is logged with a user, timestamp, and target, giving a clear audit trail to work from if an incident needs investigating. The specific incident response process and escalation path for your deployment is scoped and agreed with your team as part of onboarding, since it depends on your organization's existing security procedures.

Question 39

Can xSERVA integrate with our existing SOC or SIEM tooling?

Accepted Answer

xSERVA's audit logging and anomaly detection produce the kind of event data a SOC or SIEM workflow would consume. Whether a direct integration into your specific SIEM platform is available depends on your setup; message our team to discuss your security tooling requirements.

Question 40

Who can see or change security and access settings?

Accepted Answer

Access and security configuration is restricted through the same role-based access control that governs everything else on the platform, so only users with the appropriate administrative role can view or change permissions, keeping that control out of reach of general operators.

Question 41

Is xSERVA on-premise, cloud-hosted, or both?

Accepted Answer

xSERVA supports both models. Some customers, particularly government and institutional sites with strict data-residency requirements, run xSERVA on-premise, while others prefer a cloud-hosted deployment for lower operational overhead. Our team scopes the right model for your site during planning.

Question 42

How long does a typical xSERVA installation take?

Accepted Answer

Timeline depends on site size, the number and mix of protocols involved, and whether devices are already installed or need to be added. There is no fixed universal timeline; message our team with your site details so we can give you a scoped estimate.

Question 43

Can I migrate from an existing BMS to xSERVA?

Accepted Answer

Yes. xSERVA is commonly deployed onto sites that already have a BACnet, KNX, MQTT, or Modbus-based BMS in place. Migration typically means connecting xSERVA to the existing field devices and controllers rather than ripping out working hardware, with a scoped cutover plan for the control and reporting layer.

Question 44

Does deployment require downtime for the building?

Accepted Answer

Deployment is planned to minimize disruption to building operations, and commissioning work is typically staged so critical systems keep running throughout. The specific approach depends on the site and is confirmed with your team as part of project planning.

Question 45

Does xSERVA require new network infrastructure or hardware to be installed at the site?

Accepted Answer

Not necessarily. xSERVA is designed to run over existing site networking and connect to field devices already in place wherever they meet protocol and connectivity requirements. Some sites need additional gateways, a dedicated network segment, or edge hardware depending on the existing infrastructure's condition and the deployment model chosen; our team assesses this during scoping and flags any hardware needs up front rather than after contract.

Question 46

Do existing sensors and wiring need to be replaced to use xSERVA?

Accepted Answer

Not as a rule. xSERVA is built to connect to existing BACnet, KNX, MQTT, and Modbus field devices and wiring already installed on a site. Whether any specific sensor, controller, or cabling needs replacement depends on its condition and protocol compliance, which our team assesses during scoping.

Question 47

What is the difference between on-premise, cloud, hybrid, and edge deployment?

Accepted Answer

All four run on the same core engine. On-premise keeps the platform inside your own network, cloud-hosted reduces operational overhead and can offer automatic updates, hybrid splits responsibilities between the two, and edge keeps time-critical processing local to the site while still reporting up to a central view. Our team scopes the right model for your data-residency and connectivity needs.

Question 48

Who is involved in commissioning on our side?

Accepted Answer

Commissioning typically involves your facilities or IT team for network and access coordination, alongside whichever system integrator or contractor is handling the physical device installation, working with our team to verify points, alarms, and controls before go-live.

Question 49

Is there a public xSERVA API available today?

Accepted Answer

Not yet. xSERVA is architected on an open integration layer designed for REST and webhook-style connectivity, but a public, documented API is on our roadmap rather than something generally available today. Message our team on WhatsApp to discuss integration timelines for your project.

Question 50

Will there be an SDK for developers?

Accepted Answer

An SDK is on our roadmap alongside the public API, intended to give integrators a faster path to building on top of xSERVA. It has not shipped yet, and we will update our Developers page and notify our integrator community when it does.

Question 51

Can xSERVA integrate with ETS-configured KNX projects?

Accepted Answer

Yes. xSERVA's KNX integration is engineered against the published KNX specification and works with group addressing and datapoint types configured through ETS, so an existing ETS project can be brought into xSERVA rather than reconfigured from scratch.

Question 52

How do system integrators work with xSERVA today, without a public API?

Accepted Answer

System integrators currently work with xSERVA through direct engagement with our team: scoping the protocols and device counts on a project, confirming network and hardware requirements, and coordinating commissioning alongside the rest of the building program, rather than through self-service API access.

Question 53

What languages or frameworks will the future SDK support?

Accepted Answer

The SDK is on our roadmap alongside the public API and has not shipped yet, so specific language or framework support has not been finalized or announced. Message our team on WhatsApp if you want to be notified as SDK details firm up, or check the Developers page for updates.

Question 54

Will there be a sandbox or staging environment for integration testing?

Accepted Answer

A sandbox or staging environment for integrators is not available today, since it depends on the public API and SDK, which are roadmap items rather than shipped features. This is something we expect to address as those roadmap items mature; message our team to discuss your integration testing needs in the meantime.

Question 55

How will breaking changes be communicated once the API ships?

Accepted Answer

We have not published a formal API versioning or deprecation policy yet, since the public API itself has not shipped. Our intent is to communicate breaking changes clearly to the integrator community through the Developers page and direct notice; specifics will be confirmed alongside the API launch.

Question 56

Can integrators build custom dashboards or reports today?

Accepted Answer

Within a project, our team can work with integrators and customers to tailor dashboards, reports, and alarm configurations to a site's needs as part of the deployment itself. This is scoped project work today rather than something built independently against a public API, since that API has not shipped yet.

Question 57

Is xSERVA available on mobile?

Accepted Answer

Yes. xSERVA is built to work across web, iOS, and Android, so operators can monitor alarms, review dashboards, and act on flagged issues from a phone or tablet, not only from a desktop console.

Question 58

Can I receive alarm notifications on my phone?

Accepted Answer

Yes. Prioritized, de-duplicated alarms can be routed to the mobile app so the right person is notified as soon as an issue is raised, rather than someone needing to be watching a desktop dashboard.

Question 59

Does the mobile app work without an internet connection?

Accepted Answer

The mobile app is designed for connected use, since it reflects live building data. Offline mode capability and its exact scope depend on the deployment and device configuration; message our team if guaranteed offline access is a requirement for your site.

Question 60

Can I control equipment directly from the mobile app?

Accepted Answer

Yes, within the permissions your role grants. Role-based access control applies on mobile the same way it does on desktop, so a user only sees and can act on the sites, zones, and functions they are authorized for.

Question 61

Can I switch between multiple sites or buildings within the mobile app?

Accepted Answer

Yes, for users whose role grants access to more than one site. The app is built to support portfolio-style operators, so a facilities manager overseeing several buildings can move between them from within the same app rather than needing a separate login or install per site.

Question 62

What exactly can I control remotely versus just view?

Accepted Answer

What you can view versus control on mobile is governed by the same role-based permissions as desktop, so it varies by user. Typical remote actions include acknowledging alarms, adjusting setpoints, and toggling equipment your role is authorized for, while broader configuration changes are usually reserved for admin roles.

Question 63

How are alarm push notifications prioritized so I'm not overwhelmed?

Accepted Answer

Alarms routed to the mobile app are prioritized and de-duplicated before they reach a user, so a single underlying issue does not generate a flood of repeat notifications, and the goal is that the right person is notified of what actually needs attention rather than every raw event.

Question 64

Is the mobile app available for both iOS and Android?

Accepted Answer

Yes. xSERVA is built to work across web, iOS, and Android, so the same monitoring and control capability is available regardless of which platform your team uses.

Frequently asked questions

General & Product