Industries / Building devices
Building devices your customers can trust on their network
For makers of HVAC controllers, access and safety devices, lighting and energy systems and smart building equipment. Each device gets a verified identity, signed updates and settings managed per portfolio, building and room. Facility teams run the fleet in a console with your brand.
A fleet console in the device maker's brand: devices online, an update rolling out in waves and a live heartbeat.
- Outbound-only connections facility IT can approve
- Updates in waves, with rollback
- Settings per portfolio, building and room
- Signed webhooks to facility systems
How your devices connect
Two ways in, one fleet. Devices that can run the agent do; everything else connects through the bridge.
- HVAC and air quality controllers
- Access control and intercoms
- Fire and safety devices
- Lighting and shading controllers
- Energy and occupancy sensors
- Elevator and parking systems
SVH Device Agent
Controllers and panels on embedded Linux run the SVH Device Agent beside your application.
Hardware-rooted identity, an offline queue, signed updates and a sandbox for your application.
SVH Device Bridge
Sensors and devices on a building network that cannot run the agent connect through the SVH Device Bridge, over MQTT today or a custom adapter scoped with you.
No firmware change. The bridge carries their data to the Fleet Server over mutual TLS.
What your customer sees
A console in your brand, on their premises or in your cloud.
- Every device by portfolio, building, floor and room
- Firmware version and update history per device
- Faults and remote commands, with an audit trail
- Settings inherited from the portfolio down to one room
What their systems receive
Signed webhooks and documented REST APIs, so device data lands where they already work.
- Building management and CAFM
- Device events and measurements as signed webhooks
- Service and ticketing
- Faults and service events, with the device identity attached
- Your own apps
- Documented REST APIs for the whole fleet
What it solves for building devices
Three problems every device maker in this industry runs into, and how the platform handles them.
Facility IT says no to new devices
Devices connect outbound only, over mutual TLS, to a Fleet Server the customer can host on premises. The SBOM and security documentation come with every release.
One building is never like the next
Settings live in layers: your defaults, the model, the building, the room. A portfolio-wide change takes one edit.
Updating devices in occupied buildings
Rollouts go in waves, at the hours you set, pause on failures and roll back on their own.
Questions building device makers ask
Can the customer host it in the building?
Yes. An on-premises Fleet Server runs the building or portfolio fleet without internet, with updates and licenses delivered as signed bundles.
Our devices speak a building protocol. Can they connect?
Through the SVH Device Bridge. It speaks MQTT today; other protocols are built as an adapter, scoped with you on the first call.
Who can see which building?
Roles and permissions per installation, with LDAP or OIDC single sign-on, so a facility team sees its own buildings and nothing else.
Making something else? The Connected devices page covers every device the platform runs.
Can SVH connect your building devices?
Answer six short questions. Within two business days we reply with the path for your device. Then we book a demo with your engineers.