Custom devices and interfaces for building automation systems

Which building and facility projects require custom electronics?

A sensor unit that collects ambient temperature, humidity, CO₂ or presence information; a board that reads the dry contacts of the existing equipment and transmits them to the central system; A local control and display module for the customer's device can be developed. Combining meter and energy data and monitoring different floors or facilities in a single software are also separate project scopes. In each application, the meaning of data points, update time, and erroneous data behavior are documented.

On the lighting and HVAC side, auxiliary input/output, set value or status interfaces to the existing controller can be evaluated. In access applications, the scope of identity reading, event recording and authority transfer is determined. Tasks related to life safety, fire, emergency, and building security are not made the default responsibility of a general purpose board; It is further addressed with the relevant teams and product requirements. The responsibility of the function to be developed and the main system are clearly separated.

• Environment-specific sensor and local display modules
• Metering, status monitoring and auxiliary I/O boards
• Defined interfaces for illumination, HVAC and access

How to determine the gateway scope of Modbus and BMS?

An RS485 port does not establish that the required data can be read directly. Protocol, connection settings, address map, data types, units and writable fields must be verified. For Modbus RTU or TCP, we define polling frequency, timeouts, retries and behaviour when a device does not respond. How the gateway reports errors to the connected system is as much a part of integration as the data it translates.

In a BMS project using BACnet, the scope of development is evaluated by examining the documentation of the target devices, desired objects, features, services and network structure. Just because the protocol name is the same does not guarantee interoperability. If BTL certification is required, the tests and processes required are planned separately; No current BACnet certification is claimed. The data point list and acceptance scenarios to be prepared with the customer's integrator are the basic inputs of the technical proposal.

• Modbus register map, data scale and error model
• Documentation and service review for BACnet requirements
• Interoperability tests with target BMS

Modbus and communication interfaces for field devices →

Wired sensor, Wi-Fi or BLE connection?

While the cable route can be designed in a new facility, cabling workmanship and usage interruption in the existing building may be decisive. In wired connection, line length, topology, termination and electrical noise are examined. The use of Wi-Fi is considered with the network access policy of the business, and the use of BLE is considered with the gateway placement and data renewal expectation. Floors, reinforced concrete structure, metal electrical control panel and heavy use are part of the actual coverage assessment.

For battery-powered sensors, service access matters alongside measurement frequency and wireless transmission. Mechanical design considers wall placement, airflow and the influence of internal electronics on the sensor. User steps are defined for installation, network registration and replacement. Instead of assuming fixed battery life or coverage, we refine the design using prototype power measurements and representative site surveys.

• Field cabling and wireless coverage assessment
• Sensor location, housing and mounting design
• Planning installation, replacement and maintenance steps

How do local functionality and central software work together?

For a setpoint change or remote command, sending, accepting, and executing are separate events. In the embedded software, the initial state, local/remote authority priority and the behavior when there is no communication are defined. Details such as not re-running an old command on reconnection are resolved according to project requirements. The measurement's last update time and device status are kept visible in the center.

If a server or web dashboard is developed, we establish relationships between facilities, floors, devices and data points. User roles, alarm acknowledgement, maintenance records and historical trends follow the workflow. Where the BMS remains the primary software, the auxiliary application's boundaries and data ownership are defined. Network access, device authentication and updates are planned with the operator's IT team; direct internet exposure of field connections is not the default design.

• Local/remote authorization and disconnect behavior
• Site, device and data point model
• Access and update workflows aligned with IT policy

Developing custom energy monitoring for plant and machine data →

How can a facility integration be tested before going on site?

For example, a gateway collecting data from different meters and environmental sensors in an existing building starts with equipment documentation and a data-point list. A laboratory prototype operates with representative devices while units, scaling and signedness are checked. The same value is compared on the device display, in gateway records and in central software. Missing or incorrect responses must not appear as valid measurements.

Power outage, network failure, device replacement and restart scenarios are tried on the pilot floor. Cable, electrical control panel installation, antenna, service connection and installation time are evaluated together. The acceptance list also includes visible results in the integrator's target software. The findings are associated with hardware and software revisions. For projects requiring certification or third-party interoperability testing, the relevant preparation, installation and cost scope are determined separately.

• Data verification on real equipment and target BMS
• Interruption, error, device replacement and reinstallation tests
• Installation and usage evaluation on the pilot floor or facility

How is the delivery made to the integrator and product owner?

Before sharing the technical details of your project, we will sign NDA upon your request. The customer's building operation, device idea and special integration information are handled within the scope of development. We do not carry customer works into our own product catalogue. The task of the unit to be developed, target equipment, software responsibilities and acceptance steps are clarified at the beginning, and changes are recorded and managed throughout the project.

The source code, electronic schematic and PCB files of the project, mechanical CAD data and technical documents within the scope are delivered at the end of the project. The data point map, configuration description, connection drawings, compilation/programming steps, and test records are defined in the delivery list. Third-party library and component licenses are retained. Our rapid PCB production and electronic component assembly service is offered only for the prototype and verification needs of customer projects developed by VOMRO.

• NDA and responsibilities defined at the outset
• Source code, PCB/CAD and connection documentation
• List of data points available to the integration team