How Captia Connect speaks OpenWebNet
Connect behaves as a client of a gateway, never as a device on the bus. That distinction has to be settled first, because it shapes everything else. The physical bus of the installation is a two wire twisted pair with no polarity, powered at around 27 V DC by the line power supply, with free topology in star, tree or daisy chain. Connect does not attach there. It connects over Ethernet to the gateway that already translates that bus into TCP, opens a session and reads. No new participant appears on the bus, so neither the addressing nor the traffic budget the installation had before anyone arrived changes at all.
Session: port, opening and the two modes that exist
The session is opened against the TCP port of the gateway, which across virtually the whole installed base defaults to 20000. The first thing to arrive is not data but an acknowledgement: the gateway emits *#*1## and then waits for the client to declare what it came for. This is the design decision that determines the behaviour of the integration more than any other, because OpenWebNet will not let you do both things over the same socket:
*99*0##opens a command session. It is used to ask for statuses and dimensions, and the gateway answers each question. It is a round trip conversation.*99*1##opens a monitor session. The gateway stops answering and starts pushing: every frame travelling on the bus is mirrored to the client without the client asking for anything.
Connect keeps both sessions open in parallel against the same gateway, and that arrangement is what makes the integration work. The monitor session captures the real life of the installation, including what a person does by pressing a wall switch, which would never show up if you only ever asked. The command session is reserved for two specific jobs: the initial status sweep and the periodic reading of the quantities the bus does not announce on its own.
Authentication sits in between. Depending on the gateway firmware, it answers the session declaration with a numeric nonce between asterisks, and the client returns the OPEN password transformed by the classic algorithm, or negotiates an HMAC with *98*1## or *98*2## on equipment that supports it. Two field points are worth knowing: the factory password is often still in place and is usually five digits, and many gateways also hold a list of authorised IP ranges that must be widened to include the Connect node, because otherwise the connection is refused with no useful message and half an afternoon goes into looking in the wrong place.
Frame structure: WHO, WHAT, WHERE and DIMENSION
OpenWebNet has no register map and no browsable address space. It has a plain text grammar delimited by asterisks and closed with a double hash, and the whole integration comes down to reading it properly. Connect works with four frame shapes:
*WHO*WHAT*WHERE##, the action or state change frame. When Connect receives it on the monitor session, it means something has happened.*#WHO*WHERE##, the status request, with which Connect builds the initial picture.*#WHO*WHERE*DIMENSION##, the request for a specific quantity. This is the shape that returns numbers: power, accumulated energy, measured temperature, setpoint.*#WHO*WHERE*DIMENSION*VAL##, the reply carrying the value. Acknowledgements are*#*1##for accepted and*#*0##for refused, and a refusal here almost always means the WHERE does not exist in that installation rather than the frame being malformed.
WHO is the functional family and is the criterion Connect uses to decide what matters in a given installation. WHERE is the physical address, and here lies the quirk that surprises anyone coming from a plant protocol: it is not a flat number, it is an area and point notation. A 12 is not item twelve, it is light point 2 in area 1. There is also a general area, groups written with #, and the local bus extension #4#N for whatever hangs behind an expansion interface, which is precisely where the secondary distribution boards of a large building usually sit.
| WHO | What it covers | What Connect asks of it | What it becomes in the history |
|---|---|---|---|
| 1 Lighting | Light points, dimmers and lighting circuits by area | State by event on the monitor session, plus an initial sweep of status requests | State series marking on and off, the basis for running hours and real usage profile |
| 2 Automation | Blinds, curtains and facade actuators | Up, down and stop events | State series that explains thermal load steps once crossed with climate data |
| 4 Temperature control | Climate zones, temperature probes and setpoints | Measured temperature and setpoint per zone, read periodically as a dimension | Numeric series of temperature and setpoint in degrees Celsius, with the zone as context |
| 18 Energy management | Line meters and load management actuators | Instantaneous active power and accumulated totalisers per meter | Power series in watts and an accumulated energy counter per circuit |
| 25 Dry contacts and inputs | Volt free contacts and auxiliary system inputs | Close and open events | Binary series usable as presence, occupancy or the status of an external device |
Cadence: monitor by event, ask rarely and ask deliberately
One operating rule orders the whole deployment: whatever the bus announces is never polled, and whatever must be polled is polled slowly. The SCS bus is neither deterministic nor wide. It is a shared medium with contention based arbitration and a frame throughput per second you can count on two hands. A client that polls the whole installation every second does not get better data: it gets a saturated bus and, above all, it gets building users noticing a delay between pressing a switch and seeing the light. That is the real failure mode and it is the kind that generates a maintenance call the same day.
So Connect splits the work. Discrete states from lighting, automation and contacts arrive by event and cost nothing, because the frame is already travelling on the bus whether anybody asked for it or not. Analogue quantities, temperature and power, do have to be requested, and there Connect works in periods measured in minutes rather than seconds, staggering requests across zones and meters instead of firing them in one block. On gateways that support it the preferred route is not to ask at all: it is to instruct the energy unit to emit instantaneous consumption periodically for a time window, after which the quantity arrives on its own and the bus stops receiving questions.
What sits between the gateway and the platform
The Connect node lives in the installation, in Docker containers, and persists locally on a time series database. The OpenWebNet session is outbound from the node towards the gateway and stays inside the building network. Outwards, the node opens no inbound ports: the link to the platform is established by Tailscale as a secure outbound connection. This matters more here than on a plant protocol, because OpenWebNet travels in the clear and its authentication is weak by design: exposing a MyHome gateway to the internet through a port forward is a bad idea that is still seen in the field, and integrating through Connect makes it unnecessary. The gateway only has to be reachable from one IP address, that of the node.
Local persistence also covers a case very specific to this protocol: when the monitor session drops, and it does drop, because many gateways close idle sessions and restart after a power cut, Connect reconnects and runs the initial status sweep again. Without that sweep, the reconnection would leave a silent gap in which the installation changed state and nobody noticed.
Which equipment speaks OpenWebNet in a real installation
OpenWebNet does not turn up on the machine. It turns up in the building around the machine, and on an industrial project it usually enters through one of four places.
The first is the web gateway or installation server, the only device Connect actually talks to. It is the DIN rail box with an Ethernet socket that the installer fitted for remote control or for the building app, and its job is to translate between the two wire bus and TCP. Everything else is seen through it. The opening conversation of a project always starts with the same question: which gateway is fitted, what firmware does it run, and who knows the OPEN password.
The second is lighting actuators and dimmers in common areas, offices, warehouses with managed lighting and car parks. They are the natural source of running hours per circuit and of real usage profiles, which is exactly the data missing when somebody tries to justify a lighting refurbishment from catalogue estimates.
The third is temperature control: zone probes, climate units driven from the central unit and per area setpoints. The value here is not the bare temperature but the pair of measured temperature against setpoint, because a sustained gap between the two is what reveals a zone that never reaches target or an oversized unit that cycles.
The fourth is the meters of the energy management system, which provide active power and accumulated totals per line. They need to be placed correctly: they measure internal building circuits, not the boundary with the distribution network. Boundary metering is a different thing and is read over a different route, normally IEC 870-5-102 against the fiscal meter.
Outside all of this sits everything that is process. A controller, a drive or a power analyser does not speak OpenWebNet and never will: those are read over Modbus or over OPC UA. The engineering project that makes both worlds coexist in a single acquisition layer is interoperability between industrial and building systems, and the data capture on the facility side is sensor and facility connectivity.
From OpenWebNet frame to time series
This is where the real work of the integration sits, and it runs deeper than in OPC UA for a simple reason: the frame carries almost nothing. No declared type, no unit, no reading quality and, above all, no timestamp. A frame *1*1*12## means light point 2 in area 1 has been switched on, and that is all. Everything else is supplied by Connect.
The timestamp comes from the edge, and that has to be stated plainly
The gateway does not stamp frames. Connect stamps each sample at the instant it is received on the node, which sits in the building itself one network hop from the gateway, so the difference from the real instant of the event is the latency of the bus and the local link. That is a good approximation for consumption, climate and facility usage, which is what this data is for. It is not a time base for reconstructing the sequence of events in an electrical incident, and this page says so because the alternative is somebody discovering it during an investigation. When the history needs events stamped at source with fine resolution, the right protocol is a different one.
Value encoding: what has to be decoded
Quantities arrive packed in bespoke conventions that have to be unpacked during normalisation. Temperature comes as a four digit string whose first digit carries the sign and whose remainder is tenths of a degree, so 0250 is 25.0 degrees Celsius and not two hundred and fifty of anything. Dimmer levels arrive as stepped WHAT values that have to be translated into a percentage. Energy totalisers are monotonic accumulators that reset when a meter is replaced or reprogrammed, so the useful series is not the accumulator itself but the difference between consecutive readings, with detection of the negative step that gives a reset away. None of this is solved by the protocol. It is solved by the normalisation layer, and it is half the value of the integration.
Signal identity is the deliverable
A WHERE such as 12 or 7A#0 is perfectly readable for the installation and perfectly useless to anybody querying the history six months later. Each address is tied to its real location, floor, wing, room or board, and given a stable name and unit. This step needs either the installer drawings or a physical walk of the building switching circuits and watching which frame appears, and it is usually the most time consuming task on a project of this kind. It is also what makes building data comparable with production data, which is the entire reason for integrating it.
| What the frame delivers | What is missing and who supplies it | What it is good for later |
|---|---|---|
| Discrete state WHAT, for example a light point switched on or off | Semantics and unit are fixed by the mapping; the value is stored as a binary state series | Running hours per circuit and real usage profile against the nominal schedule |
| Temperature dimension encoded in tenths with a sign digit | Connect decodes it to degrees Celsius and ties it to the climate zone | Sustained gap between measurement and setpoint, which is what exposes a poorly served zone |
| Active power dimension from a line meter | Connect fixes the unit in watts and ties the meter to its circuit and board | Load curve per circuit, the basis for splitting consumption between process and services |
| Accumulated energy totaliser | Connect keeps the accumulator and derives the increment between readings, detecting counter resets | Consumption per period, comparable across circuits and across months |
| Frame with no timestamp | Connect stamps the sample on the node, inside the building, as it arrives | A series usable for consumption, climate and usage, not for reconstructing electrical event order |
| WHERE address in area and point notation | Tied to floor, room or board with a stable name and unit | Makes the signal queryable by people without the installer drawings in front of them |
The generic path of this work, whatever the source protocol, is developed in the data acquisition system guide, and the neutral definition of the device that translates the bus is in the glossary entry for an industrial gateway.
When OpenWebNet is not the right route
This is the section no manufacturer publishes and the one that prevents badly framed projects. OpenWebNet solves one specific scope very well and is a poor choice outside it. There are six situations where the answer has to be no.
It is not a plant protocol and must not be used as one. The bus is not deterministic, guarantees no delivery time and has no concept of data quality whatsoever. Any signal taking part in an interlock, a safety stop or a control loop is read from the system that governs it, over OPC UA or over Modbus. A signal being wired to the building bus does not make it a process signal.
It is not for boundary metering or anything with regulatory weight. The meters of the energy management system are internal apportionment metering, useful for knowing which circuit consumes what. Measurement that gets billed or presented to a third party is read from the fiscal meter over IEC 870-5-102. Confusing the two produces reconciliations that never close and arguments settled far too late.
It is not for sub second resolution or sequence of events. With no source timestamp and a shared bus in the way, asking OpenWebNet for a fine chronology is asking for something it does not have. If that is the requirement, the signal has to be taken from the device that does stamp it.
It is not for sensors retrofitted afterwards. Adding a wireless temperature, air quality or vibration sensor to a building does not go through the SCS bus: it goes through MQTT, which is pub/sub and requires neither cabling nor touching the existing installation. Extending the bus to take on new sensors is expensive and adds nothing over that route.
It is not viable if the gateway only exposes manufacturer cloud services. This case is growing: on part of the more recent installed base local access is disabled or limited, and all the information leaves through a manufacturer API. At that point this stops being a bus protocol problem and becomes an IT integration problem, solved over REST API or webhooks. Checking this before committing to a scope avoids the worst surprise this protocol has to offer.
It is not the route for commanding the building from the platform. The protocol accepts command frames, but the integration is framed as acquisition. Writing to lighting or climate from a data layer means disputing control of the installation with the central unit, with two systems able to issue contradictory orders to the same actuator and no arbitration between them. Connect acquires; building control stays where it was.
And one limit that belongs to the brief rather than the protocol: OpenWebNet supplies no context. The frame says a light point switched on, it does not say that the light point is the loading bay lighting or which shift uses it. Without that assignment work the result is a history of addresses nobody consults. It is the same question that orders any integration and the one that defines what is asked of an industrial data acquisition system when it is done properly.
Coexistence with the rest of the installation
In an industrial building nobody has a single protocol: they have the building bus the electrical contractor fitted, the controllers the process integrator fitted and the meter the distribution company fitted. Connect acquires in parallel over all those routes and lifts them into the same time series model, so that in the history the power of a lighting circuit read over OpenWebNet, the output of a line read over OPC UA and boundary energy read over IEC 870-5-102 all sit at the same level. Nobody needs to know which protocol a value came from in order to cross it with another.
The coexistence that produces the most value is precisely that crossing. Building consumption is only interpreted properly against activity: a warehouse consuming as much on a Saturday with no production as on a Tuesday at full output has an auxiliary services problem rather than a process one, and that is invisible when either series is read on its own. Separating process consumption from facility consumption is the precondition of any serious energy efficiency work, and it is why this protocol, which looks minor next to a plant one, ends up being the one that closes the balance.
On migration, the recommendation is not to plan one. Replacing a working building bus is an electrical works project with a cost and a service interruption, and nobody asks for it in order to be able to measure. What happens in practice is simpler: the existing installation stays as it is and is read through its gateway, and everything added later comes in over whichever route suits it, normally sensors over MQTT or process equipment over Modbus and OPC UA. Once an acquisition layer that accepts what is there exists, the building bus stops being an isolated system and becomes one more source.
The platform modules already work on that base, and the engineering project that deploys it in a building with an existing installation is interoperability between industrial and building systems.