Overvis Cloud is a comprehensive IoT platform for monitoring and controlling industrial equipment. Connect Modbus devices, visualize data in real-time, configure alerts, and integrate with your systems via API.
Overvis Cloud is an industrial IoT platform for remote monitoring and control of equipment via the Modbus protocol. It connects your field devices — temperature controllers, energy meters, PLCs, sensors — to the cloud, giving you real-time data access, historical logging, alerts, and remote control from anywhere with a web browser.
The guide is intended for engineers, integrators, and automation enthusiasts who are familiar with Modbus and industrial equipment, but new to the Overvis platform. For detailed connection troubleshooting and alternative connection methods, see Connecting Equipment. For platform features like alerts, visualizations, and reports, see the Overvis Cloud documentation.
A Modbus TCP communication controller — acts as a gateway between your Modbus RTU devices and the internet. We recommend the Overvis MC252 for the simplest setup experience. Other Overvis-compatible controllers are available at overvis.com/equipment.
A Modbus RTU device — the equipment you want to monitor or control (e.g. a temperature controller, energy meter, PLC, sensor). This device connects to the communication controller via RS-485.
RS-485 cable — a twisted pair cable to connect the Modbus RTU device to the controller’s RS-485 port.
Internet connection — Ethernet cable or cellular network (SIM card) for the communication controller.
A computer or smartphone — with a web browser to access Overvis Cloud.
You may also need:
Power supply for the communication controller (refer to the controller’s documentation for voltage and connector specifications).
Modbus device documentation — the register map, Modbus address, and communication settings of your RTU device. You will need these to configure parameters in Overvis.
Before you can register a controller in Overvis, it must be powered on and connected to the internet.
The steps below are for the Overvis MC252. Other Overvis-compatible controllers with a PIN code label follow a similar process — for specifics, refer to the controller’s manual.
Mount the device and connect a 12V DC power supply (9–30V range supported).
Connect an Ethernet cable to the LAN port, or insert a SIM card with data service into the SIM slot and attach the GSM antenna.
Apply power. The device initializes in about 15 seconds.
Press the R button to wake the display. It shows the current IP address prefixed with (E) for Ethernet or (G) for GSM, along with connection data rates.
The controller uses DHCP by default, so in most cases it obtains an IP address automatically after plugging in the Ethernet cable. With a SIM card (no PIN lock), cellular connection is typically established within a minute without any user action.
If the display shows 0.0.0.0, the device has not yet obtained an address — check the cable connection or SIM card. For detailed setup instructions and troubleshooting, see the MC252 Quick Start Guide.
Email — will be used for login and notifications. Double-check it before submitting.
Password — minimum 5 characters.
Organization name — optional. If left blank, a default name is derived from your email address. You can change it later.
Terms checkbox — you must agree to the Terms of Service and Privacy Policy to continue.
Click Sign up.
After registration, you are automatically logged in and redirected to the Create Network page (covered in the next step). A confirmation email is sent to the address you provided — click the link in it within 24 hours to keep your account active.
During registration, Overvis creates an organization for your account. In Overvis, an organization is the unit of billing and access control — it groups networks, users, and permissions together. It does not have to correspond to a real-world company: a single company might use several Overvis organizations to separate different sites, projects, or cost centers. For details on managing organizations and inviting team members, see Organizations & Users.
In Overvis, a network represents a communication controller and all the Modbus RTU devices accessible through it. The next step is to create a network — tell Overvis how to find and access your controller.
Navigate to the Create Network page — if you just registered, you are already there.
Locate the sticker on your MC252 (or other Overvis-compatible controller). It contains a QR code and a PIN — an 8-character alphanumeric code (e.g. A1B2C3D4).
Enter the PIN from the device label into the PIN code field and click Check connection to verify the controller is online and reachable.
If the check succeeds, Overvis confirms the connection and shows the controller details. If it fails, make sure the controller is powered on, connected to the internet (see Step 1), and try again.
Give your network a descriptive name (e.g. “Warehouse”, “Office HVAC”, “Home Heating”) and click Create network to finalize.
After creation, you are taken to the network page where you can see the controller and its connection status. Verify that the status shows the controller as connected before proceeding to the next step.
With the controller registered in Overvis, it is time to connect an actual Modbus RTU device to it. This step has two parts: physical wiring via RS-485 and registering the device in Overvis.
Connect the Modbus RTU device to the communication controller using a twisted-pair cable:
Controller terminal A (non-inverted, D+) → Device terminal A (D+, +)
Controller terminal B (inverted, D−) → Device terminal B (D−, −)
Make sure both devices use the same serial communication settings (baud rate, parity, stop bits). The MC252 defaults to 9600 baud, Modbus RTU, with automatic stop bit detection. Consult your device’s documentation and adjust settings on the controller if needed (via the MC252 web interface, Modbus tab — see MC252 Quick Start).
Fill in the device Name and Modbus ID (unit ID, 0–255 — check your device’s documentation or DIP switches).
In the Initialize with the template dropdown, select a template that matches your device model. Templates pre-configure all parameters (register addresses, data types, names, units) so you don’t have to set them up manually. Overvis includes templates for many common industrial devices.
Click Create device.
If no template is available for your device, you can add parameters manually after creating the device — see Step 5 and the Networks, Devices & Parameters documentation. You can also create your own templates for reuse — see Device Templates.
Once a device is added to your network, you can view its data in Overvis.
From the network page, click on the device name to open the device page.
The Details page shows the time of the last read at the top, followed by a list of parameters. Parameters are grouped into sections: Tracked (values are stored historically), Programmed (writable settings), and Untracked (read but not stored). If you applied a device template, all parameters are pre-configured with names, data types, and these flags.
Each parameter row shows the parameter name, its Modbus address, and the current value (with units). Click on a value to refresh it from the device on demand.
If you did not use a template, or need to add additional parameters, click Add Parameter in the sidebar and specify:
Name — a human-readable label for the parameter.
Device’s memory address — the Modbus register number (from your device’s documentation).
Register type — Holding Register, Input Register, Coil, or Discrete Input.
Type — how to interpret the register value (Int16, Uint16, Int32, Float32, etc.).
Units — measurement units for display (°C, kWh, V, A, etc.).
Overvis allows you to write values to Modbus registers on the device — for example, changing a temperature setpoint, switching an output on or off, or adjusting a configuration parameter.
Parameters in the Programmed section (those with the Programmable flag — set by the template or manually when adding a parameter) have a pencil icon next to their value. To change a value:
Click the pencil icon next to the parameter you want to change.
An inline editor appears in the row — enter the new value (or select from a dropdown for enumerated parameters).
Confirm the write.
Overvis sends the Modbus write command to the device through the controller. The displayed value updates on the next read cycle (by default every 10 minutes, configurable per device in its settings).
Every new account receives a €30 bonus — enough for 1–2 months of free experimentation, depending on the number of connected networks. No payment is required to get started. For pricing details and payment options, see Billing.
Overvis Cloud communicates with field equipment through Modbus TCP. In a typical setup, a communication controller (Modbus TCP gateway) connects to the internet and maintains a link with the Overvis server. Modbus RTU devices — temperature controllers, energy meters, PLCs, sensors — connect to the gateway via RS-485 and are accessed by Overvis through the gateway.
graph LR
A["Modbus RTU<br/>devices"] -->|"RS-485<br/>Modbus RTU"| B["Communication<br/>controller<br/>(Modbus TCP gateway)"]
B -->|"Internet<br/>Modbus TCP"| C["Overvis Cloud"]
C -->|"Web / HTTPS"| D["User<br/>(browser)"]
In Overvis, this entire chain is represented as a network: one communication controller plus all the Modbus RTU devices accessible through it. Each device within a network has a unique Modbus address (unit ID) and a set of parameters — individual register values that Overvis reads from or writes to the device. For details on managing networks, devices, and parameters after connection, see Networks, Devices & Parameters.
This page covers everything needed to establish the connection: registering the gateway in Overvis, wiring RS-485 devices, configuring serial communication settings, resolving conflicts with previously registered devices, and diagnosing connection problems.
Overvis supports three methods for connecting a Modbus TCP gateway to the platform. The first two (PIN code and activation code) use a reverse connection — the controller initiates an outbound TCP connection to Overvis, which avoids firewall and NAT issues. The third method (direct connection) requires Overvis to connect inbound to the controller, which needs a static public IP and port forwarding.
The PIN code is an 8-character alphanumeric code (e.g. A1B2C3D4) printed on a sticker attached to the device. The sticker also contains a QR code that encodes a URL like https://c.overvis.com/A1B2C3D4.
This is the simplest connection method and the recommended choice for first-time setup of Overvis-compatible controllers (MC252, EM-482, EM-483, and others).
How it works:
The controller connects outbound to Overvis and identifies itself by MAC address. When the user enters the PIN code, Overvis looks up the MAC address associated with that PIN and links it to the user’s network. Since the controller initiates the connection, no port forwarding or static IP is required — the connection works through firewalls, NAT, and dynamic IP addresses.
sequenceDiagram
participant Controller
participant Overvis
participant User
Controller->>Overvis: Connect & send handshake (MAC address)
Overvis->>Controller: Confirm handshake
Note over Controller,Overvis: Reverse connection established, waiting for binding
User->>Overvis: Enter PIN code on Create Network page
Overvis->>Overvis: Look up MAC address by PIN
Overvis->>Overvis: Bind connection to user's network
Overvis->>User: Network created
loop Polling
Overvis->>Controller: Read registers (Modbus TCP)
Controller->>Overvis: Return data
end
Steps:
Make sure the controller is powered on and connected to the internet (Ethernet or GSM). Verify connectivity on the device’s display or web interface.
Locate the sticker on the device. Either scan the QR code with your phone (it opens the Create Network page with the PIN pre-filled) or note the PIN to enter it manually.
Log in to Overvis at ocp.overvis.com and navigate to the Create Network page.
Select Use the PIN code printed on the device sticker, enter the PIN, and click Check connection.
If the check succeeds, Overvis confirms the controller is online and shows its details (controller model and firmware version). If it fails, verify that the controller has internet access and try again.
Enter a descriptive network name and click Create network.
Important characteristics:
The PIN code is reusable — it can be used multiple times, for example after deleting and re-creating a network.
If the controller is already bound to a network in your account, Overvis will warn you that the existing network will be disconnected and offer to proceed. All data in the old network is preserved.
If the controller is already bound to a network in another account, the PIN code cannot rebind it. You must use the activation code method instead (see Activation Code) or have the current owner unbind the device (see Device Conflicts and Takeover).
The activation code is an 8-digit numeric code (e.g. 38571098) generated by the Overvis server and sent to the controller after it establishes a reverse connection. The code is displayed on the controller’s screen (if it has one) or in its local web interface.
This method is used when the PIN code sticker is unavailable, or when you need to take over a controller that is already registered under another Overvis account. Since reading the activation code requires physical or local network access to the device, it serves as proof of ownership.
How it works:
The controller connects outbound to Overvis and receives a unique activation code, which it displays on its screen or web interface. The user reads this code and enters it in Overvis to bind the device to their account. The code changes every time the controller re-establishes a connection to the server (until it is bound).
sequenceDiagram
participant Controller
participant Overvis
participant User
Controller->>Overvis: Connect & send handshake (MAC address)
Overvis->>Overvis: Generate 8-digit activation code
Overvis->>Controller: Send activation code
Controller->>Controller: Display code on screen / web interface
Note over Controller,Overvis: Reverse connection established, waiting for binding
User->>Controller: Read activation code from display or web interface
User->>Overvis: Enter activation code on Create Network page
Overvis->>Overvis: Verify code, look up MAC address
Overvis->>Overvis: Bind connection to user's network
Overvis->>Controller: Confirm binding
Controller->>Controller: Display "active"
Overvis->>User: Network created
loop Polling
Overvis->>Controller: Read registers (Modbus TCP)
Controller->>Overvis: Return data
end
Steps:
Make sure the controller is powered on and connected to the internet.
Obtain the activation code:
Controllers with a display (e.g. MC252): the 8-digit code is shown on the screen after the server connection is established. The display shows the code prefixed with (E) for Ethernet or (G) for GSM (e.g. (E) 38571098).
Controllers without a display (e.g. EM-482, EM-483, EM-130): access the controller’s local web interface by its IP address. The code can be found on the status/parameters page, typically in a “Data store server activation code” or similar field.
Log in to Overvis at ocp.overvis.com and navigate to the Create Network page.
Select Use the one-time code displayed on the device screen, enter the 8-digit code, and click Check connection.
If the check succeeds, enter a network name and click Create network.
After successful binding, the controller’s display (MC252) will show active instead of the numeric code, or the web interface status page (EM-483, EM-130) will show “Active”. The activation code stops changing — the device is now permanently bound to this network.
Important characteristics:
The activation code has higher priority than the PIN code. It can take over a controller that is currently bound to another account, because reading the code proves physical access.
Once bound, the controller remains associated with this network even after reconnections — Overvis will not generate a new activation code until the device is unbound.
The activation code is single-use: each code is valid only until it is used or until the controller reconnects (which generates a new code).
Where to find the activation code by device:
Device
Location
MC252
Device display and web interface (Cloud tab)
EM-482
Web interface, status page
EM-483
Web interface, status page
EM-130
Web interface, settings/parameters page (“Data store server activation code”)
With a direct connection, Overvis initiates the TCP connection to your controller by its public IP address and port. This method works with any standard Modbus TCP device — it does not require Overvis-specific firmware or integration. However, it is more complex to set up and less secure than the reverse connection methods.
How it works:
Overvis establishes a TCP connection to the specified IP address and port, then communicates using standard Modbus TCP protocol. The connection is initiated by the Overvis server, so the target device must be reachable from the internet.
sequenceDiagram
participant User
participant Overvis
participant Router
participant Controller
User->>Overvis: Create network with direct connection<br/>(IP, port, gateway Modbus ID)
Overvis->>Router: TCP connect to public IP:port
Router->>Controller: Forward to controller (port forwarding)
Controller->>Router: Modbus TCP response
Router->>Overvis: Forward response
Overvis->>User: Connection verified, network created
loop Polling
Overvis->>Router: Read registers request
Router->>Controller: Forward to controller
Controller->>Router: Return data
Router->>Overvis: Forward response
end
Prerequisites:
Static public IP address from your ISP. Dynamic IP addresses are not supported — if your IP changes, Overvis will lose the connection.
Port forwarding configured on your router to redirect external traffic to the controller’s local IP and Modbus TCP port (default: 502).
DHCP reservation or static IP for the controller on your local network, so port forwarding rules remain valid.
Steps:
Obtain a static public IP address from your ISP.
Configure your router to forward a chosen external port to the controller’s internal IP address and Modbus TCP port (default 502).
Ensure the controller always has the same local IP — either by configuring DHCP reservation on the router or setting a static IP on the controller.
Log in to Overvis and navigate to the Create Network page.
Select Establish direct Modbus TCP connection.
Fill in the required fields:
Modbus TCP controller — select the controller model from the dropdown, or choose “Other Modbus TCP device” for third-party equipment.
Gateway Modbus Address — the Modbus unit ID of the gateway controller itself (default 111 for MC252; check your device’s documentation).
IP Address — the static public IP address of your router.
Port — the external port you configured for forwarding.
Click Check connection to verify Overvis can reach the device.
If the check succeeds, enter a network name and click Create network.
When to use direct connection:
Third-party Modbus TCP devices or gateways that don’t support Overvis reverse connections.
Devices that already have a static public IP and are set up for remote Modbus TCP access (e.g. by a SCADA system).
Environments where the controller cannot make outbound connections to the Overvis server.
Once a communication controller is registered in Overvis, the next step is connecting the actual field devices — temperature controllers, energy meters, PLCs, sensors, VFDs, and other Modbus RTU equipment — to the controller’s RS-485 port.
RS-485 uses a differential signaling pair — two wires carrying the same signal with opposite polarity. Connect the controller and device terminals as follows:
Controller terminal A (non-inverted, D+) → Device terminal A (D+)
Controller terminal B (inverted, D−) → Device terminal B (D−)
Optionally connect the shield/ground terminal (labeled ⊥, GND, or G) between devices if available.
Use shielded twisted-pair cable (Category 1 or better). Connect the shield to ground at one end of the bus according to ANSI/TIA/EIA-485-A-1998.
Bus topology:
RS-485 is a bus topology — all devices are connected in a daisy-chain (device to device), not in a star pattern. Avoid stub cables (T-shaped branches) longer than a few centimeters, as they cause signal reflections.
graph LR
A["Controller<br/>(master)"] --- B["Device 1<br/>ID: 1"]
B --- C["Device 2<br/>ID: 2"]
C --- D["Device 3<br/>ID: 3"]
D --- E["..."]
Termination:
Long RS-485 buses or buses operating at high baud rates may need termination resistors (typically 120 Ω) at both ends of the bus to reduce signal reflections. Some controllers have built-in termination (e.g. EM-482 has a 1000 Ω internal terminator). If you experience intermittent communication errors on a long bus, adding termination resistors is the first thing to try.
All devices on the RS-485 bus must use the same serial communication settings. A mismatch in any of these parameters will prevent communication.
Baud rate — the speed of data transmission in bits per second. Common values:
Baud rate
Typical use
1200
Slow/legacy devices
2400
Legacy devices
4800
Older equipment
9600
Most common default
19200
Faster polling
38400
Fast devices
57600
High-speed devices
115200
Maximum for most RS-485 devices
The baud rate must match between the controller and all connected devices. Higher baud rates allow faster polling but may be unreliable on long cable runs or in electrically noisy environments.
Byte format (parity and stop bits):
Each byte transmitted on the RS-485 bus includes optional parity and stop bits for error detection. The byte format must match across all devices. Common options:
Format
Description
8N1 (ABSENT)
8 data bits, no parity, 1 stop bit
8N2 (STOP)
8 data bits, no parity, 2 stop bits
8E1 (EVEN)
8 data bits, even parity, 1 stop bit
8O1 (ODD)
8 data bits, odd parity, 1 stop bit
SPACE
8 data bits, space (zero) parity bit, 1 stop bit
MARK
8 data bits, mark (one) parity bit, 1 stop bit
AUTO-STOP
Automatic detection — sends with 2 stop bits, accepts 1 or 2 stop bits. Available on some Overvis-compatible controllers.
The most common configurations are 9600 baud, 8N1 or 9600 baud, 8E1. Check your device’s documentation for the required settings.
Configuring serial settings on Overvis-compatible controllers:
For controllers connected via reverse connection (PIN or activation code), Overvis can read and write the RS-485 serial settings remotely. After creating the network, the network settings page shows the current Bit rate and Byte format of the controller, and allows you to change them.
For third-party controllers connected via direct connection, configure the serial settings through the controller’s own interface (web interface, front panel, DIP switches, etc.).
The RS-485 standard (ANSI/TIA/EIA-485-A) specifies a maximum bus length of 1200 meters (4000 feet). In practice, the achievable distance depends on the baud rate, cable quality, and electrical noise environment:
Baud rate
Practical max distance
9600
up to 1200 m
19200
up to 1200 m
38400
up to 1000 m
57600
up to 700 m
115200
up to 500 m
These are approximate values. Use shorter runs in electrically noisy environments (near VFDs, high-voltage lines, welding equipment). If you need to extend beyond 1200 m, use RS-485 repeaters or a second communication controller with its own Overvis network.
Maximum device count:
The number of devices on a single RS-485 bus depends on the receiver input impedance of the devices:
Receiver input current
Max devices
1 mA (standard)
32
0.5 mA (1/2 unit load)
64
0.25 mA (1/4 unit load)
128
0.125 mA (1/8 unit load)
256
Most modern Modbus RTU devices use 1/4 or 1/8 unit load receivers, allowing 128–256 devices on a single bus. Check the RS-485 transceiver specifications in your devices’ datasheets.
Each device must have a unique Modbus address (unit ID) in the range 0–255. Address 0 is reserved for broadcast in the Modbus protocol (writes to all devices, no response expected).
Modbus RTU — binary framing with CRC-16 error checking. This is the standard mode used by the vast majority of devices. Data is compact and transmission is efficient.
Modbus ASCII — ASCII-encoded framing with LRC error checking. Each byte is transmitted as two ASCII hex characters, making the data human-readable but doubling the bandwidth requirement. Used by some older or specialized devices.
Both modes use the same register model and function codes — the difference is only in how bytes are encoded on the wire.
Most Overvis-compatible controllers default to Modbus RTU. If your connected device requires Modbus ASCII, configure this in the controller’s serial port settings (web interface or via Modbus registers). Overvis itself communicates with the controller using Modbus TCP, which is mode-agnostic — the controller handles the RTU/ASCII translation on the RS-485 side.
Each physical Modbus RTU device connected to the controller’s RS-485 port is represented as a device in Overvis, identified by its Modbus unit ID within the network.
To add a device, open the network page in Overvis and click Add Device. Specify the device name, Modbus ID, and optionally select a device template to pre-configure all parameters. If no template is available, you can add parameters manually by specifying register addresses, data types, and names.
Information about your device’s Modbus register map, supported function codes, and data types is typically found in the device’s documentation or datasheet, usually in a section titled “Modbus registers”, “Communication protocol”, or “Register map”.
When you try to create a network using a controller that is already registered in Overvis, the behavior depends on which connection method you use and whether the controller belongs to your account or another account.
If the PIN code is already bound to a network in your account, Overvis shows a warning:
Connect code ABCD1234 is already bound to the network Warehouse. After you submit this form, this network will be disconnected. All data will be preserved.
You can proceed — the old network will be disconnected and the controller will be bound to the new network. The old network and its data (device parameters, readings history) remain accessible.
If the controller is already bound to a network in another Overvis account, the PIN code cannot rebind it. The PIN code has lower priority — it proves that you have the sticker, but not necessarily physical access to the device.
To take over the controller, use the activation code method instead.
The activation code has higher priority than the PIN code because it requires reading a code from the device’s display or web interface, which proves physical access. An activation code can take over a controller from any account — after binding, the device is removed from the previous owner’s network.
To unbind a controller from its current network (so it can be registered again, either by you or another user), use any of the following methods:
Delete the network in Overvis that the controller is bound to.
Change the network’s connection settings to a different connection method (e.g. switch from reverse connection to direct connection).
Reset activation on the device — access the controller’s web interface and click the “Restart Activation” (MC252, EM-483) or “Reset Activation Code” (EM-130) button. This removes the device from the Overvis network and generates a new activation code.
After unbinding, the controller re-connects to Overvis and receives a new activation code, ready for re-registration.
Some controllers support password-based access protection for reading and/or writing registers. If your controller has passwords configured, add them in the Controller access password(s) section. Overvis sends these passwords to the controller after connecting, exactly as entered.
You can add multiple passwords — for example, separate read and write passwords. The controller determines which level of access each password grants.
Controls how many Modbus requests Overvis sends to this network simultaneously (in parallel). The default is 1 — Overvis waits for each response before sending the next request (sequential mode).
Increasing this value allows Overvis to send multiple requests at once, which can speed up polling when the controller supports it. However, many RS-485 controllers process requests sequentially on the serial bus regardless, so setting a high value may not improve performance and can cause timeouts if the controller’s request queue overflows.
Use the default value of 1 unless you know your controller supports parallel request processing.
Networks can be disabled to pause all communication without deleting the network or losing data. A disabled network stops all readings, writes, background tracking, and alert processing. Dashboard and visualizations cannot access disabled networks. All existing data and settings are preserved, and the network can be re-enabled at any time.
After creating a network, the network page shows the live connection status of the gateway controller. The status indicator shows one of the following states:
Connected — the controller is online and communicating with Overvis. A tooltip shows the connection time (“since …”).
Disconnected — the controller is not reachable. A tooltip shows the last seen time and the disconnect reason:
“The device has not established a connection to the server” — for reverse connections (PIN/activation code), the controller has not connected outbound to Overvis.
“Server can’t establish the connection (timeout)” — for direct connections, Overvis tried to connect to the controller’s IP but timed out.
“No direct connection” — no direct connection configuration is active.
Connection problems fall into three tiers. Start at the top and work down — each tier builds on the previous one being resolved.
graph TD
A["Data access issue"] --> B{"Is the gateway<br/>online in Overvis?"}
B -->|No| C["Tier 1:<br/>Gateway not reachable"]
B -->|Yes| D{"Does the device<br/>respond to reads?"}
D -->|No| E["Tier 2:<br/>Device not reachable"]
D -->|Yes| F{"Is the data<br/>correct?"}
F -->|No| G["Tier 3:<br/>Data is wrong"]
F -->|Yes| H["Out of scope <br/>of this guide"]
Symptom: The network shows as offline in Overvis. No data is being read from any device. The connection status shows “The device has not established a connection to the server” (reverse connections) or “Server can’t establish the connection (timeout)” (direct connections).
This means Overvis cannot communicate with the communication controller. For reverse connections, it means the controller has not established or has lost its outbound connection to Overvis. For direct connections, it means Overvis cannot reach the controller’s IP and port.
Verify the controller is powered on and running. Check the power indicator:
Device
Normal power indicator
MC252
PWR LED stays on; display shows IP addresses
EM-482
PWR LED stays green
EM-483
Power LED on; error indicator (⚠) off
EM-130
On/Off indicator on
If the MC252 PWR LED does not light up, check the 9–30V DC power supply and fuse. If the EM-482 PWR indicator is constantly red or blinking fast in red, the device may be malfunctioning — contact the manufacturer. If the EM-483 error indicator (⚠) is red steady or periodic after power-on, the device has a fault.
2. Network connection (Ethernet / Wi-Fi)
The controller must have a working link to the local network before it can reach Overvis.
MC252 (Ethernet): Check that the Ethernet cable is connected and the LAN LED is active (blinking during data transfer). The display shows the assigned IP prefixed with (E). If the display shows (E) 0.0.0.0, DHCP is still negotiating — wait 20–60 seconds. If it shows (E) 192.168.0.111, DHCP failed and the device fell back to its factory default static IP. Verify the cable, router DHCP, or configure a static IP in the web interface (LAN/Internet tab).
EM-482 (Wi-Fi): The WI-FI LED blinks slowly (every 3 seconds) while connecting and turns on steady once connected. If the WI-FI LED keeps blinking for more than 2 minutes, the configured Wi-Fi access point is unavailable — check the SSID, password, access point distance, and that the access point is powered on. If the WI-FI and SRV LEDs are blinking alternately, the device is in Wi-Fi setup mode — either complete the configuration via its web interface, or exit setup mode by pressing the R button for about 3 seconds.
EM-130 (Wi-Fi): The device must be in Wi-Fi Client mode with the Overvis client enabled. If Wi-Fi is disabled or in Access Point mode, it will not connect to the internet. Configure Wi-Fi client mode through the device’s web interface.
3. Internet access and Overvis server connection
Even with a local network link, the controller must be able to reach the Overvis server over the internet.
MC252: Check whether the SRV LED is on — it indicates the cloud/server connection is active. In the web interface (Cloud tab), verify the cloud connection is enabled and the server address is correct (default: ocp.overvis.com, port 20502).
EM-482: The SRV LED should turn on shortly after the WI-FI LED. If SRV remains off for more than 2 minutes, the device cannot reach the internet. Verify the server connection address in the web interface. Check that your network firewall is not blocking outgoing connections.
EM-130: In the web interface remote access settings, verify the Overvis client is enabled (“Overvis turning on” = Yes) and the server address is correct (default: modbus.overvis.com, port 20502).
4. Firewall and port requirements
The controller initiates an outbound TCP connection to the Overvis server on port 20502. Corporate networks and firewalls may block this. Ask your network administrator to allow outbound TCP traffic to ocp.overvis.com:20502 (or modbus.overvis.com:20502 for EM-130).
5. DNS resolution
The controller needs to resolve the Overvis server hostname. If DNS is not working on the local network, configure a public DNS server (e.g. 8.8.8.8) on the controller. The EM-130 uses 208.67.222.222 and 8.8.8.8 as default DNS servers.
6. GSM/LTE connection (MC252)
For controllers using cellular connectivity:
Verify the SIM card is fully inserted (until you hear a click) and has active data service.
Check the antenna is attached to the ANT connector.
Check GSM signal strength on the MC252 display (should be >0%).
In the web interface (LAN/Internet tab → GSM section), verify the APN settings match your mobile operator’s requirements.
If the SIM has a PIN lock, enter it in the GSM settings. If in doubt, try disabling the SIM PIN on a phone first.
Try relocating the antenna for better signal.
7. Cloud connection not enabled on the controller
Some controllers ship with the cloud connection disabled by default:
MC252: In the web interface, open the Cloud tab and verify the cloud connection is enabled. Click “Save & Reset” after enabling it.
EM-130: The Overvis client is disabled by default. Enable it in the remote access settings of the web interface.
EM-482, EM-483: The cloud connection is enabled by default. If it has been disabled, re-enable it in the web interface.
Static IP — verify your public IP has not changed. Check with your ISP or visit a “What is my IP” site from the controller’s network.
Port forwarding — verify the router’s port forwarding rule is still active and points to the correct internal IP and port (default Modbus TCP port: 502).
Controller’s local IP — has the controller’s local IP changed (DHCP lease expired)? Re-configure DHCP reservation or use a static IP on the controller.
Firewall — verify no firewall between Overvis and the router is blocking the configured port.
Controller — verify the controller is powered, running, and its Modbus TCP service is active on the expected port. On the MC252, check the Modbus tab in the web interface to confirm Modbus TCP Server is enabled on port 502.
Symptom: The network is online (gateway is connected), but one or more devices show read errors, timeouts, or “no response” for all parameters.
The controller can talk to Overvis, but cannot communicate with the end device on the RS-485 bus.
1. Verify Modbus address
Check that the device’s Modbus address (unit ID) in Overvis matches the address configured on the physical device. The address is typically set via DIP switches, front panel, or device configuration software. Common default addresses vary by manufacturer — check the device manual.
2. Check RS-485 wiring polarity
Swap the A and B wires at the controller or at the device. Reversed polarity is the single most common RS-485 problem and does not cause equipment damage. Different manufacturers label terminals inconsistently — what one calls “A” another may call “B”. Look for D+/D- or +/- labels as a more reliable guide.
3. Match serial communication settings
All devices on the RS-485 bus must share identical serial settings. A mismatch in any parameter causes complete silence (no responses at all) or CRC errors:
Baud rate — verify the baud rate configured on the controller matches the device’s baud rate. The most common default is 9600.
Parity / stop bits — verify the byte format (e.g. 8N1 vs 8E1) matches between the controller and all devices. If unsure, try AUTO-STOP parity mode on controllers that support it (MC252, EM-482) — it sends with 2 stop bits and accepts 1 or 2 stop bits.
Modbus RTU vs ASCII — the vast majority of devices use RTU mode. If your device requires ASCII mode, configure the controller accordingly.
For Overvis-compatible controllers, these settings can be changed through:
MC252: Web interface (Modbus tab → RS-485 section), or remotely via Overvis network settings.
EM-482: Web interface during setup, or remotely via Overvis network settings.
4. Use the MC252 device search tool
The MC252 web interface has a built-in Search Devices tool (Modbus tab → Search Devices button) that scans all Modbus addresses and optionally tries different baud rates, parity, and protocol settings. This can identify connected devices and their actual configuration. A thorough search takes 30–60 minutes; use the Fast search option if you know all devices use the same settings.
5. Use the MC252 Send Request tool
The MC252 web interface has a Send Request tool (Modbus tab → Send Request button) that sends a single Modbus request and shows the raw response. Use it to test communication with a specific device address and verify the response. An exception code in the response does not necessarily indicate a device problem — it may just mean the device doesn’t have the requested register.
6. Check cable and bus topology
Check for damaged cable, loose terminal connections, or broken wires.
RS-485 must be wired in a daisy-chain (bus topology), not in a star pattern. Avoid stub cables (T-shaped branches) longer than a few centimeters.
On long buses (>100 m) or at high baud rates (>38400), add 120 Ω termination resistors at both ends of the bus. Note that the EM-482 has a built-in 1000 Ω internal terminator.
Try a shorter cable as a test to rule out cable issues.
7. Verify device power and state
Make sure the device is powered on and in normal operating mode (not in a configuration, firmware update, or error state). Some devices disable Modbus communication during certain modes.
8. Check for bus conflicts
Verify no two devices on the same RS-485 bus share the same Modbus address. Duplicate addresses cause collisions and garbled responses.
If you are near the device limit for your transceiver type (32 for standard 1 mA receivers, 128–256 for low-power receivers), try disconnecting some devices to see if communication improves.
9. Electrical noise
RS-485 communication can be disrupted by nearby variable-frequency drives (VFDs), motors, high-voltage switching, or welding equipment. Route RS-485 cables away from power lines and use shielded twisted-pair cable. Connect the cable shield to ground at one end of the bus.
Symptom: The device responds, but the values shown in Overvis are incorrect — wrong numbers, always zero, negative values when positive are expected, etc.
The communication path works, but the parameter configuration does not match the device’s register map.
1. Register address offset
Modbus register addressing conventions vary between manufacturers. Some device manuals document addresses starting from 0, others from 1, and some from 40001 (the Modicon convention, where 40001 = holding register 0). If your value is off by one register or consistently shifted, try adjusting the register address by ±1.
2. Register type mismatch
Modbus defines four register types. Using the wrong type reads from a different address space:
Register type
Function codes
Typical use
Holding registers
3 (read), 6/16 (write)
Read/write configuration and data
Input registers
4 (read)
Read-only measurements
Coils
1 (read), 5/15 (write)
Single-bit on/off states
Discrete inputs
2 (read)
Single-bit read-only states
Verify the parameter in Overvis uses the same register type as specified in the device documentation.
3. Data type and byte order
A temperature reading stored as a 32-bit float will appear as garbage if read as two independent 16-bit integers. Common data types:
16-bit unsigned integer (1 register)
16-bit signed integer (1 register)
32-bit float, IEEE 754 (2 registers)
32-bit unsigned/signed integer (2 registers)
For multi-register values, check both byte order (big-endian vs little-endian) and word order (AB CD vs CD AB). The MC252 Send Request tool in the web interface can help identify the correct interpretation by showing raw register values.
4. Scaling factor
Many devices store values with an implicit decimal point. For example, a temperature of 23.5°C may be stored as the integer 235 (×10) or 2350 (×100). The EM-130, for instance, represents all decimal values as integers with a conversion factor determined by the number of decimal places (1 decimal place = ×10, 2 = ×100, 3 = ×1000). Check the device documentation for the scaling factor.
5. Consult the device documentation
The device’s Modbus register map is the authoritative source for addresses, types, and scaling. It is usually found in the device manual, a separate “communication protocol” document, or on the manufacturer’s website. For Overvis-compatible devices, the register maps are available in the device documentation:
The EM-483 web interface status page shows the server connection state: the activation code (waiting for binding), “Active” (bound to Overvis), or “No Code” (registered via QR/PIN sticker).
The EM-130 has a single On/Off indicator and a Wi-Fi button — no display. Diagnose connection state through the web interface. In the remote access settings, check that the Overvis client is enabled and the activation code is shown (indicating the server connection is established).
Overvis Cloud Documentation
Networks, Devices & Parameters
Overvis organizes field data in a three-level hierarchy:
Level
Parent
Represents
Main responsibility
Network
Organization
One controller or gateway connection
Reachability and controller-level communication
Device
Network
One Modbus unit inside that network
Polling and write behavior for that unit
Parameter
Device
One readable or writable value on that device
Addressing, type conversion, storage, and writability
This page is the reference for all three levels — what they store, how they relate to each other, and how their settings affect communication and data handling. It follows the same order as the hierarchy: networks, then devices, then parameters. For a hands-on walkthrough, see Getting Started. For connection methods and troubleshooting, see Connecting Equipment.
Every network, device, and parameter has two identifiers:
Internal ID — a numeric primary key used in the API and database.
Slug — a URL-friendly string derived from the object’s name (e.g. warehouse, temperature-controller, current-temperature). Slugs are unique within their parent scope: network slugs are unique within the organization, device slugs within their network, and parameter slugs within their device. Overvis uses slugs in page URLs.
Networks and devices can be disabled without deleting them. Disabling preserves all configuration and stored data but stops communication:
A disabled network stops all reads, writes, and background polling for every device and parameter under it.
A disabled device stops all reads, writes, and background polling for every parameter under it.
Networks and devices can be disabled by a user, by the billing system (when the organization’s balance runs out), or by a platform administrator. The disable timestamp and actor are recorded so the reason is always visible.
Re-enabling restores normal operation immediately — no reconfiguration is needed.
There is no separate enabled / disabled switch for individual parameters. Tracked and programmable control polling, history, and writes (see Behavior flags); a parameter with both flags off can still be read on demand. To stop all Modbus traffic for a device — including on-demand reads — disable the device or network.
To create a network, go to the organization’s network list and click Add network. The create form guides you through selecting a connection method and entering connection details. For a step-by-step walkthrough of each connection method, see Connecting Equipment.
A descriptive label for the network (e.g. “Warehouse”, “Office HVAC”).
Description
Optional free-text description.
Connection
How Overvis reaches the controller: reverse connection (PIN code or activation code) or direct Modbus TCP (IP address and port). See Connecting Equipment for details on each method.
Modbus TCP controller
The model of the communication controller (e.g. MC252, EM-482, EM-130, or “Other Modbus TCP device” for third-party equipment). Determines which built-in features and settings are available. Matches the Modbus TCP controller: field in the network form.
Gateway Modbus address
The Modbus unit ID of the controller itself on the TCP link (default: 111). This is used when Overvis needs to address the gateway directly — for example, to read or change serial port settings on an Overvis-compatible controller. This is not the address of any field device.
Controller access passwords
Passwords sent to the controller after connecting. Some controllers require one or more passwords for read and/or write access. Multiple passwords can be configured (e.g. separate read and write passwords).
Maximum inflight requests
How many Modbus requests Overvis sends to this network simultaneously (default: 8). Increasing this value allows parallel requests, which can speed up polling when the controller supports it. Many controllers process RS-485 requests sequentially regardless, so a high value may not improve performance and can cause timeouts.
On supported controllers, a Controller Modbus settings block appears (bit rate and byte format). Overvis reads the current values from the controller and can write changes over the same link. Only shown when the controller type supports it and the network is connected. See Serial communication settings for choosing values that match your field devices.
Network settings do not include the Modbus addresses of devices behind the controller, parameter register addresses, or data interpretation rules. Those belong to the device and parameter levels.
The network page shows the gateway connection status and the list of all devices in the network.
The device list shows each device’s Modbus ID, name, number of tracked parameters, update period, and the time of the last reading. From this page you can enable or disable individual devices, open device settings, or delete a device.
For networks using a reverse connection (PIN code or activation code), the page also shows connection status and management actions such as dropping the connection.
A device represents one Modbus unit inside a network — one addressable endpoint behind the controller. All devices in a network share the same controller connection.
The key identifier is the Modbus ID (unit ID, 0–255), which must be unique within the network and match the address configured on the physical device (DIP switches, front panel, or device configuration software).
To create a device, open the network page and click Add device.
The create form asks for:
Name and optional description.
Modbus ID — the unit address of the physical device.
Device template (optional) — select a template to pre-configure all parameters automatically. You can choose from built-in templates or templates created within your organization. See Device Templates for details.
If no template is available for your device, you can add parameters manually after creating the device.
After creating the device, Overvis begins communicating with it immediately (if the network is connected and the device is enabled).
The Modbus unit ID (0–255). Must match the physical device address and be unique within the network.
Update period
10 minutes
How often Overvis performs background reads for tracked parameters on this device. Shorter periods give more frequent data but increase network traffic.
Read group size
1
The maximum number of consecutive registers Overvis combines into a single Modbus read request. The device settings UI accepts 1–16; the database allows up to 255 (for example when set via template import). Higher values reduce the number of requests by reading larger register blocks at once, which speeds up polling. A value of 1 means each parameter is read individually.
Modbus write function
0x6 for a single register, 0x10 for multiple registers (default)
Which Modbus function code to use when writing parameter values. The default option matches this label in the UI (Overvis chooses function 06 for single-register values and 16 for multi-register values). Other options: Always use function 06 (force single-register writes), Always use function 16 (force multi-register writes). Some devices only accept one specific write function — consult the device documentation.
Maximum retries
3
How many times Overvis retries a request after a timeout or no-response error before marking the device as unreachable.
Device settings do not define the connection path to the controller (that is the network level) or how individual register values are decoded (that is the parameter level).
The device page is where you view and interact with parameter values. Parameters are organized by their behavior flags (tracked, programmable) into sections — see Behavior Flags for definitions.
The device page shows:
Last reading — the timestamp of the most recent background reading for this device.
Next reading — when the next scheduled background read will occur.
Parameter list — all parameters organized into three sections (tracked, programmed, untracked), with categories within each section.
Tracked parameters display their last stored value by default. This value may be from the most recent background poll, not necessarily live.
To read a live value from the device:
Click on a parameter’s value to start reading it from the device in real time. Overvis will keep refreshing that value automatically until you click it again. This works for both tracked and untracked parameters.
Click the refresh icon in the column header to read all visible parameter values at once.
Untracked parameters show ”---” until you trigger an on-demand read.
Programmable parameters have a pencil icon next to their value. Clicking it opens an inline editor:
For numeric parameters, a text input appears where you enter the new value.
For enumeration parameters, a dropdown appears with the defined labels (e.g. “Standby”, “Heating”, “Cooling”) — Overvis writes the corresponding numeric value to the device.
The write is sent to the device immediately. If the write fails, Overvis shows an error message with the reason.
A parameter is the smallest operational object in the hierarchy. It represents one value definition on a device — a single piece of data that Overvis can read from or write to.
A parameter can represent:
One holding register or input register.
One coil or discrete input.
One bit inside a register.
A contiguous range of bits inside a register.
A multi-register value (e.g. a 32-bit float spanning two registers, or a 64-bit integer spanning four).
To add a parameter manually, open the device page and click Add parameter. The form includes all fields described below: name, address, register type, value type, behavior flags, conversion settings, and optional enumeration values.
To edit an existing parameter, click its name on the device page to open the parameter settings. The same form appears with the current values pre-filled.
If your device has many parameters, using a device template is faster than adding them one by one.
Each parameter stores the following identification and organizational fields:
Field
Description
Name
The primary display label (e.g. “Current Temperature”, “Setpoint”, “Operating Mode”).
Mnemonic
An optional short code or abbreviation (up to 20 characters), typically from the device documentation (e.g. “PV”, “SV”, “St”). When set, Overvis displays it before the name.
Description
Optional explanatory text.
Category
Groups parameters within the device page (e.g. “Measurement”, “Settings”, “Diagnostics”). Categories are purely organizational — they do not affect addressing, polling, or writes. Parameters without a category appear under “Uncategorized”.
Units
Measurement unit label for display (e.g. °C, kWh, V, A, %).
For bit and bit-group value types: which bit within the register (0 = least significant).
Bit group length
For bit-group value types: how many consecutive bits the value spans. Labeled Bit group length: in the parameter form.
String length
For string value types: how many registers the string occupies.
The same device memory address can legitimately appear in more than one parameter when the parameters represent different views of the same data — for example, a whole-register numeric value and a single bit flag inside that same register, or several independent bit flags from one status register.
The value type defines how the raw register data is interpreted. It determines the binary layout, byte order, and number of registers a parameter occupies.
Overvis supports a wide range of value types:
Category
Value types
Registers
8-bit integers
Unsigned Byte, Signed Byte
1
16-bit integers
Unsigned/Signed Short (big-endian and byte-swapped variants)
1
32-bit integers
Unsigned/Signed Int (big-endian, byte-swapped, and word-swapped variants)
2
64-bit integers
Unsigned/Signed Long (big-endian, byte-swapped, and word-swapped variants)
Byte String (2 ASCII characters per register) or Word String (1 ASCII character per register)
Variable
IP address
IPv4 address in byte order or word order
2
MAC address
MAC address in byte order or word order
3
Special
Unsigned 48-bit Int (3 registers), Unsigned 3 Last Bytes in Words (3 registers)
3
Byte order matters. Many devices store multi-byte values in big-endian order (most significant byte first), but some use byte-swapped or word-swapped layouts. If a value reads as garbage or an unreasonable number, the byte order is likely wrong — try the other variants for the same data width.
Three flags control how Overvis treats a parameter operationally:
Tracked — a tracked parameter participates in background polling and persistent storage:
Overvis reads it periodically according to the parent device’s update period.
Each reading is saved to the database with a timestamp.
Historical data is available in charts, reports, and the dashboard.
An untracked parameter is still part of the device model and can be read on demand, but it is not polled automatically and its values are not stored.
Programmable — a programmable parameter can be written through Overvis. Non-programmable parameters are read-only in the Overvis UI regardless of whether the underlying register supports writes.
Tracked and programmable are independent flags. A parameter can be:
Tracked only — monitored and stored, but not writable through Overvis.
Programmable only — writable, but not automatically polled or stored.
Both — polled, stored, and writable.
Neither — exists as part of the device model for on-demand reads only.
Always read/write as a group — when enabled, Overvis keeps the entire multi-register value together in one Modbus request instead of allowing it to be split across separate requests. This is relevant for parameters that span more than one register (e.g. 32-bit floats, 64-bit integers, strings) where partial reads could produce corrupted values if the device does not update all registers at the same instant.
After reading a raw value from the device, Overvis can transform it for display using three parameter-level settings:
Setting
Description
Multiplier
Scales the raw value. Applied as multiplication.
Shift
Adds a fixed offset after scaling.
Decimal places
Controls how many decimal digits are shown in the formatted value.
The conversion formula is:
displayed value = raw value × multiplier + shift
For example, if a temperature sensor stores values in tenths of a degree (raw value 235 means 23.5 °C), set multiplier to 0.1 to convert to degrees. If the device stores a value with a fixed offset, use shift to compensate.
Overvis stores raw register values in the database and applies conversion at display time. This means multiplier and shift affect how all readings appear — both historical and new. Changing the multiplier retroactively changes how old data looks in charts and reports. Decimal places affects formatting only, not the stored value.
When neither multiplier nor shift is set, Overvis treats the value as unscaled: the displayed value equals the raw register value (equivalent to multiplier 1 and shift 0).
Enumeration is a value type for parameters where a numeric register encodes a discrete state or mode — for example, machine status, operating mode, or alarm type. At the Modbus level it works like any other numeric parameter, but Overvis maps the raw values to human-readable labels using a lookup table.
Each entry in the enumeration table contains:
Field
Description
Value
The raw numeric value from the device.
Represent As
The display label shown in the UI (e.g. “Running”, “Standby”, “Error”).
Description
Optional explanatory text for this state.
For example, a parameter “Operating Mode” might have the mapping:
Value
Represent As
0
Standby
1
Heating
2
Cooling
3
Error
When reading, Overvis shows “Heating” instead of 1. When writing a programmable enumeration parameter, the user selects from a dropdown of the defined labels, and Overvis writes the corresponding numeric value.
Enumeration tables can be shared across multiple parameters, which is useful when several parameters on different devices use the same set of states.
Parameters can optionally define minimum and maximum values. These are informational boundaries — they help constrain write inputs in the UI and provide context for expected value ranges. They do not affect how values are read from the device.
This usually means the value type or byte order does not match what the device actually sends. For example, reading a 32-bit float as a 16-bit unsigned integer, or using big-endian byte order when the device uses word-swapped order.
How to fix:
Open the parameter’s settings and check the value type. Confirm it matches the device documentation for that register.
If the data width is correct but the value still looks wrong, try the other byte-order variants for the same width (e.g. switch from “Float big-endian” to “Float word-swapped” or “Float byte-swapped”).
Check the device memory address — some device manuals use 1-based register numbering while Overvis uses 0-based. If the manual says register 40001, the Overvis address is typically 0 (holding register).
If a multiplier or shift is configured, verify the conversion formula produces reasonable results.
The device is not responding to Modbus requests within the timeout.
Common causes and fixes:
Wrong Modbus ID — verify that the Modbus ID set in Overvis matches the address configured on the physical device. Check DIP switches, front panel settings, or the device configuration software.
Device not powered or not connected — confirm the device is powered on and wired to the RS-485 bus connected to the gateway controller.
Network is disconnected — check the network’s connection status indicator. If the gateway itself is offline, no devices in that network can be reached. See Connecting Equipment — Troubleshooting.
RS-485 settings mismatch — the baud rate and byte format (parity, stop bits) on the gateway must match the device. Mismatched serial settings cause communication failures. See Connecting Equipment — Serial Settings.
Duplicate Modbus IDs — two physical devices on the same RS-485 bus with the same Modbus address will interfere with each other and cause intermittent failures or corrupted responses.
A ”---” value means Overvis has no stored reading for that parameter. This is normal for untracked parameters that have never been read manually.
How to fix:
Click on the value field to trigger an on-demand read from the device. If the device is online and the parameter address is valid, the current value will appear.
If you need historical data for this parameter, enable the tracked flag in parameter settings.
If the on-demand read fails, the device may be unreachable — check the device unreachable section.
When Overvis cannot write a value to a parameter, common causes include:
Parameter is not programmable — writing is only allowed for parameters with the programmable flag enabled. Enable it in parameter settings.
Wrong write function — some devices only accept function code 06 (single-register write) or function code 16 (multi-register write), but not both. Change the Modbus write function in device settings from “Normal” to the specific function your device expects.
Register is read-only — the underlying Modbus register type (e.g. input register, discrete input) does not support writes. Check the device documentation.
Value out of device range — the device may reject values outside its internal limits even if the Overvis parameter allows them.
Controller access password missing — some controllers require a write-access password. Check the controller access passwords in network settings.
If tracked parameters update less frequently than the configured update period:
Multiple devices sharing one controller — all devices in a network share the same connection. If many devices with many parameters exist on one network, polling all of them takes time. The actual cycle time may exceed the update period.
Read group size too low — a read group size of 1 means each parameter is read individually, which requires one Modbus request per parameter. Increasing the read group size (within the 1–16 range in the device settings UI, or up to 255 when allowed) combines consecutive registers into fewer requests, which speeds up polling.
High inflight requests with slow controller — many RS-485 controllers process requests sequentially. Setting inflight requests too high may cause queued requests to time out while waiting, triggering retries and further slowing the cycle.
Frequent retries — if some devices on the bus are unreachable or intermittently failing, Overvis spends time on retries before moving on. Each retry waits for a timeout before it counts as failed.
On the device page, you can bulk-change behavior flags. Select parameters using the checkboxes and use the buttons below the parameter list to mark them as tracked or untracked. You can also change tracking in individual parameter settings.
Enabling tracking starts background polling and data storage for that parameter. Disabling tracking stops polling and storage, but existing historical data is preserved.
Can I use the same register address for multiple parameters?
Yes. This is common when one register contains multiple independent bit flags — you can create separate bit-type parameters for each flag, all pointing to the same register address but with different bit positions. Similarly, you might have one parameter reading the full register as a numeric value and another parameter reading a single status bit from it.
What happens to historical data if I change parameter settings?
Changing value type, multiplier, or shift retroactively changes how all stored readings appear — see Value Conversion. Changing the register address or register type makes the parameter read from a different location going forward; old data still shows the values from the previous address.
Networks, devices, and parameters are the foundation for other Overvis features:
Dashboard — tracked parameters can be pinned to the organization dashboard for at-a-glance monitoring. The dashboard groups displays by network and device.
Alerts — threshold and offline alerts are configured on individual parameters or devices. Alert state is shown on the device page and dashboard.
Visualizations — custom interactive dashboards that read parameter values in real time.
HACCP Reports — food safety compliance reports built from tracked temperature parameters.
Device Templates — reusable parameter configurations for quick device setup.
Overvis Cloud Documentation
Dashboard
The Dashboard is the organization-level overview page in Overvis Cloud. It brings together the most important parameters from all your networks and devices into a single screen, so you can monitor live values, check connection status, see active alerts, and write values to programmable parameters — all without navigating to individual device pages.
The dashboard shows two kinds of content:
Parameter widgets — individual parameters you have added to the dashboard. These are organized by network and device automatically.
Visualizations — custom interactive widgets configured to appear on the dashboard. These are rendered above the parameter widgets. See Visualizations for details.
The parameter widget set is shared across the organization — all users in the same organization see the same parameters on the dashboard. There are no per-user layouts, custom arrangements, or multiple dashboards per organization.
Full-featured dashboard for operators and administrators. Supports adding/removing parameter widgets, writing values to programmable parameters, and navigating to network and device settings.
Monitoring
/view/
Read-only dashboard for display screens and view-only users. Shows the same data and layout, but hides management controls (add/remove, write).
Both modes show the same organization-wide parameter widgets and visualizations. Users who open the manage dashboard without management permissions are redirected to the monitoring dashboard automatically.
The dashboard offers two layout options, toggled with the Widget view / Table view buttons at the top of the page. The selected view is remembered in the browser.
When the dashboard has more than three devices (across all networks), Collapse all / Expand all buttons appear next to the view toggle, allowing you to expand or collapse all network and device panels at once.
Widget view is the default layout. The page is organized as expandable panels grouped by network and device.
Network panels — each network appears as a collapsible section showing:
Network name (dimmed if the network is disabled).
Connection status icon — a green check mark when connected, or a red cross when disconnected.
Time since the last connection (e.g. “3 minutes ago”), or “Not connected.” if the network has never connected.
An alarm bell icon if any active alert is associated with the network.
When expanded in manage mode: a link to network details, and a Manage link for VPN-type networks.
Device panels — inside each network, each device with dashboard parameters appears as a collapsible card showing:
Device name.
Last reading time (e.g. “Last reading: 3 minutes ago”), or “Never read.” if the device has not been read yet.
Next scheduled reading (e.g. “Next reading: in 2 minutes”), or a status message if something prevents reading:
“Network is unreachable” — the gateway/controller is offline.
“No incoming network connection” — the reverse-connection gateway has not connected yet.
“Device is unreachable” — the gateway is online but the device is not responding.
“Currently reading” — a read is in progress right now.
“Device is disabled” — the device has been disabled.
“Background readings deactivated” — automatic readings are turned off.
“Unknown device” — the device cannot be identified.
Alert and event indicators for that device.
A Summarized readings report link that opens a readings report for all parameter widgets displayed for that device.
Parameter widgets — inside each device panel, each parameter shows:
Parameter name.
Latest formatted value (with units), or ”–” if no reading is available or the device is disabled.
Time of the latest reading.
Visual status based on active alerts — normal (default), warning, or critical styling.
Expanding a parameter widget. Clicking a parameter widget expands it to show:
Min and max values over the last 24 hours.
A 24-hour history chart showing the last day of readings in 15-minute intervals.
A Full history link to the complete readings report for that parameter.
A realtime readings section that polls live values from the device every second while the widget remains expanded. Values are shown as a compact bar chart that fills with readings over time.
Realtime readings only work while the parameter widget is expanded. Collapsing the widget stops the polling. If the device is disabled, the realtime section shows “Device is disabled” instead.
Writing values. On the manage dashboard, clicking the value of a programmable parameter opens a write dialog where you can enter a new numeric value and send it to the device. Programmable parameters are indicated by a dashed underline and a pen icon on their value. Clicking the value opens the write modal; clicking elsewhere on the widget expands/collapses it.
Table view shows the same parameter widgets in a compact tabular layout. Instead of nested network and device panels, devices are listed as flat rows: each row is labeled with that device’s network name and device name, separated by » (same pattern as in the interface).
Expanding a device row shows a table with the columns listed below. In the UI, the header row shows Parameter as text; the next header cell is a sync icon only; the third and fourth header cells have no text labels.
Column
Content
Parameter
Parameter name, plus alert/event indicators.
Sync
Toggle button to start/stop realtime reading for that parameter. The icon spins while active.
Value
Latest formatted value (live value when sync is active).
Chart
Link to the full readings history for that parameter.
The sync icon in the device header row toggles realtime reading for all displayed parameters on that device at once.
Table view does not provide write or remove controls. Use it for monitoring screens where you need to see many parameters at a glance.
Each device panel in widget view has an Add parameter display button (visible in manage mode only). Clicking it opens a modal that lists the device’s tracked parameters, grouped by category. Parameters already on the dashboard are excluded from the list.
This method only offers parameters that are already marked as tracked. If the parameter you want is not listed, add it from the device page instead (see below).
On the device details page, select one or more parameters using the checkboxes and click Add to dashboard.
This method is more flexible:
It can add several parameters at once.
If a selected parameter is not yet tracked, Overvis automatically marks it as tracked before adding it (since dashboard display requires periodic readings).
On the manage dashboard in widget view, each parameter widget has a remove button (trash icon) to unpin it from the dashboard. Removing a parameter widget does not delete the parameter itself or its historical data — it only removes it from the dashboard view.
If a parameter is deleted from the device configuration, its dashboard widget disappears automatically.
The search field at the top of the dashboard filters by network name and device name. It does not search parameter names.
When you type multiple words, Overvis matches devices whose combined network and device name contains all the words (in any order). For example, typing “warehouse temperature” matches a device named “Temperature Controller” in a network named “Warehouse”.
The dashboard keeps data current through automatic updates:
Full structure (network list, device list, parameter widgets) is loaded once when the page opens.
Values and status (parameter readings, connection status, device read times, alert state) are refreshed every 10 seconds for expanded networks and devices. Collapsed panels are not polled — their values update once they are expanded.
Realtime readings for individually expanded parameter widgets are polled every 1 second while they remain expanded.
Disabled networks and devices remain visible on the dashboard, but their behavior changes:
Disabled devices show a “Device is disabled” status instead of the next reading time.
Parameter values show ”–” and are not updated (no reads or writes are performed).
The write dialog is not available for parameters on disabled devices.
Realtime readings show “Device is disabled” instead of live values.
Disabling does not remove parameter widgets from the dashboard. When the network or device is re-enabled, normal polling and display updates resume. For more on disabling, see Networks, Devices & Parameters — Disabling.
If a parameter does not show up after you add it, reload the page — the dashboard loads its full structure once on page load and may not reflect changes made in another tab. If the parameter still does not appear, check that it belongs to a device in the current organization and that the parameter has not been deleted.
A dash (”–”) instead of a value means Overvis has no recent reading for that parameter. Common reasons:
Device is disabled — enable the device to resume readings.
Network is unreachable — the gateway/controller is offline. Check the network connection status in the network panel header.
Device is unreachable — the gateway is online but the specific device is not responding. Check the Modbus address and wiring. See Connecting Equipment — Troubleshooting.
Parameter has never been read — if the device shows “Never read.”, wait for the next scheduled reading cycle or trigger a manual read from the device page.
If values update on the device page but not on the dashboard, expand the network and device panels — collapsed panels are not polled for new values.
The search field only matches network names and device names — it does not search parameter names. If you are searching for a parameter by name, you need to find it by its device or network name instead.
Multiple words are matched independently: all words must appear somewhere in the combined network name and device name (in any order).
No. Each organization has one dashboard with one shared set of parameter widgets. All users in the organization see the same parameters. The dashboard layout (grouping by network and device) is automatic and cannot be rearranged.
Why do my expanded panels reset when I reload the page?
The expand/collapse state of network and device panels is saved in your browser’s local storage — it persists across reloads. However, expanded parameter widgets (focused for realtime readings) and search queries reset on reload by design.
If you notice panel state is lost, you may have cleared your browser data, or you are using a different browser/device.
Expand a parameter widget in widget view to see a 24-hour sparkline (mini chart). Click the Full history link below the chart to open a detailed readings report. In table view, use the chart icon in the last column to go directly to the readings report.
What is the difference between widget view and table view?
Widget view shows parameters as interactive cards with sparkline mini charts, realtime readings, write controls, and the ability to add/remove parameters. It is best for active monitoring and control.
Table view shows parameters in a compact table with sync toggles for realtime values. It does not have write or add/remove controls. It is best for monitoring screens and situations where you need to see many parameters at once.
Why does the dashboard show outdated values for some devices?
The dashboard only refreshes values for expanded network and device panels. If a network or device panel is collapsed, its parameter values are not polled until you expand it. Expand the panel to see the latest values.
How do I add a parameter that is not listed in the “Add parameter display” modal?
The dashboard’s “Add parameter display” modal only shows parameters that are already tracked (have automatic periodic readings enabled). If the parameter you want is not listed:
Go to the device page.
Select the parameter using its checkbox.
Click Add to dashboard.
Overvis will automatically enable tracking for the parameter and add it to the dashboard.
Overvis Cloud Documentation
Device Templates
Every Modbus device needs a set of parameters before Overvis can read data from it — register addresses, value types, names, units, tracking flags, and so on. Setting these up manually for a 50-register energy meter is time-consuming; doing it for twenty identical meters is impractical.
Device templates solve this. A template is a saved, reusable parameter configuration for a specific device model. Select a template when creating a device (or apply one later), and Overvis configures all parameters, dashboard widgets, visualizations, and alerts automatically.
A device template stores two kinds of information:
Device-level settings — metadata and communication defaults:
Name, manufacturer, and version — identify the template (e.g. PAC3200, Siemens, 1.0). A template is uniquely identified within its scope (global or organization) by the combination of name, manufacturer, and version.
Category — free-text grouping (e.g. Temperature controller, Energy meter).
Read group size — how many consecutive registers to batch into a single Modbus read request (1–255, default 1).
Write function — which Modbus write function code to use: normal (auto-select based on register count), always-6 (always use function code 06 — Write Single Register), or always-16 (always use function code 16 — Write Multiple Registers).
Description — optional notes about the device or template.
Parameter definitions — one entry per register or bit the device exposes:
Name — human-readable label (e.g. Supply temperature).
Address — Modbus register number (0–65535).
Register kind — holding, input, coil, or discrete-input.
Value type — how to interpret the raw register data. Overvis supports a wide range of types: signed and unsigned integers of various widths (8/16/32/48/64-bit), floating-point (32-bit and 64-bit), BCD, bit and multi-bit extractions, strings, IP addresses, MAC addresses, and enumeration values. Multi-register types can use big-endian, byte-swapped, or word-swapped byte order. Coil and discrete-input registers must use the bit value type.
Units — measurement units (°C, kW, bar, etc.).
Category and label — for grouping and short identification in the UI.
Multiplier and shift — linear scaling applied to the raw value: displayed = raw × multiplier + shift. Not available for bit, string, IP address, and MAC address value types.
Decimal precision — number of decimal places to display (0–20).
Bit position (0–15) and bits amount (1–16) — for bit and bits value types, which bits within a register to extract.
String length — for byte-str and word-str value types, the number of characters (1–255).
Is tracked — whether Overvis stores historical readings for this parameter.
Is programmable — whether the parameter can be written to from the UI.
Read as group — whether to include this parameter in grouped reads.
Auto-add widget — whether to create a dashboard widget for this parameter when applying the template.
Enumeration mappings — for enum type parameters, a table mapping numeric values to human-readable text (e.g. 0 → Off, 1 → On, 2 → Error).
Min/max values — expected value range for validation and display.
Optional extras:
Alert templates — pre-defined alerts in YAML format. When the template is applied, Overvis can create alerts automatically (e.g. “send email when temperature exceeds 80°C”). See the Alerts Templates Reference for the YAML syntax.
Device visualization — an embeddable visualization (HTML/JS) that gets attached to the device page.
Translations — parameter names, descriptions, categories, units, and enumeration labels in multiple languages (English, Ukrainian, Polish, Russian).
Global templates are maintained by Overvis and available to all users. They cover common industrial devices — controllers, energy meters, PLCs, sensors, and gateways. You cannot edit global templates, but you can clone them into your organization to customize.
Organization templates belong to a specific organization. They are visible only to members of that organization. You can create, edit, clone, delete, and export organization templates freely.
In the Overvis web interface, go to Templates in the left sidebar:
Your Templates shows templates owned by your current organization.
Global Templates shows the shared library.
Both views display the template name, manufacturer, version, and parameter count (tracked and programmable). Click a template to see its full parameter list and settings.
Your Templates lists the templates your organization owns or has cloned:
Global Templates lists the shared library maintained by Overvis:
If a global template is close to what you need but requires modifications — different scaling, extra parameters, adjusted alerts — clone it:
Open the global template.
Click Copy template.
The clone appears in your organization templates with the same parameters, ready to edit.
If a template with the same name already exists, the clone is created with a numeric suffix (e.g. PAC3200 (1)). Enumeration mappings and translations are fully copied to the clone.
If you have already configured a device manually — set up all its parameters, units, tracking flags, and so on — you can save that configuration as a template:
Open the device page.
Click Save as Template.
Enter a template name (required). The form only asks for the name; Overvis copies all parameters, register settings, enumeration mappings, read group size, write function, and device metadata into the new template.
Click Create template.
The new template appears in your organization library with the same parameters, register settings, and enumeration mappings as the device. You can edit name, manufacturer, version, category, and description later on the template settings page.
For new device models, or when you want precise control over every field, create a template as an Excel .xlsx file and import it.
Go to Your Templates.
Click Upload Template.
Upload the .xlsx file.
Overvis validates the file structure and content. If there are errors, they are reported with the sheet name, row, and cell reference.
On success, the template is added to your organization library.
If a template with the same name, version, and manufacturer already exists in your organization, the import replaces it — the old template is deleted and the new one takes its place.
The Excel file must have an Info sheet and a Params sheet. Optional sheets: Visualization (device visualization source code) and Alerts (alert template YAML). No other sheet names are allowed. See the Device Templates Reference for the complete specification.
After creating or cloning a template, you can edit its metadata (name, manufacturer, version, category, and description) through the template settings page. The settings page also has an Alarms template YAML: field where you can add or edit alert definitions directly, without re-importing the Excel file.
To change individual parameter definitions, export the template to Excel, make changes in the spreadsheet, and re-import.
Any template — global or organization — can be exported as an .xlsx file. The exported file has the same structure as the import format, so you can round-trip: export, edit in a spreadsheet, and re-import.
When adding a device to a network, select a template from the dropdown. The device will be created with all template parameters pre-configured. Overvis records which template was used, so you can see the original template on the device page.
When applying a template, you control what happens with several settings:
Parameters:
Template parameters are matched to existing device parameters by a composite key of register address, register kind, bit position, and bits amount. If a matching parameter already exists on the device, it is updated in place. If not, a new parameter is created.
Remove device parameters which are missing inside the template — optionally delete any device parameters that do not have a match in the template. Useful when replacing one template with another.
Alerts:
Add alerts from template — primary checkbox (on by default). When checked, Overvis creates alerts from the template YAML. Two optional nested checkboxes apply only when the primary checkbox is checked:
Replace existing alerts presented inside the template — remove existing alerts that match a template alert definition, then add template alerts (clean re-apply for those definitions).
Remove alerts associated with this device and missing inside the template — remove existing alerts that are not defined in the template.
With only Add alerts from template checked, template alerts are added alongside existing alerts.
Enabling the first nested checkbox alone applies add and remove presented. Enabling the second nested checkbox alone applies add and remove missing.
Enabling both nested checkboxes removes all existing alerts, then adds template alerts.
Uncheck Add alerts from template to skip alert creation (nested checkboxes must be off).
Dashboard widgets:
Add widgets from template to dashboard — primary checkbox (on by default). When checked, Overvis creates dashboard widgets for parameters marked with auto-add widget in the template.
Optional nested checkbox Remove device widgets which are missing inside the template — removes dashboard widgets for parameters that are not covered by a template row with auto-add widget enabled (including parameters not linked to the applied template).
Uncheck Add widgets from template to dashboard to skip widget creation (the nested checkbox must be off).
Visualizations:
Create device visualization from template — primary checkbox (on by default). When the template includes a device visualization, attach it to the device.
Nested checkbox Remove currently existing device visualizations (on by default): with both checkboxes on, replace any existing visualization with the template’s version.
With only Create device visualization from template checked, add the template visualization without removing existing ones.
Uncheck Create device visualization from template to skip visualization creation (Remove currently existing device visualizations must be off).
After applying, Overvis refreshes the device configuration on the communication operator so polling begins immediately with the new parameters.
Click on any template to see its full details: device-level settings, the complete parameter list with addresses, value types, tracking flags, and enumeration mappings.
Templates support multilingual parameter names, descriptions, categories, units, and enumeration labels. The base language is always English. Additional translations (Ukrainian, Polish, Russian) can be included in the Excel file or managed through the template settings.
When applying a template, you choose which language to use. Overvis looks up translations for that language and applies them to parameter names and other text fields. If a translation is missing for a specific field, the English value is used.
Some device parameters represent discrete states rather than continuous values — operating modes, error codes, status flags. Templates handle these with the enum value type.
An enumeration mapping defines which numeric register value corresponds to which human-readable text. For example, a status register might map 0 → Stopped, 1 → Running, 2 → Error, 3 → Maintenance.
Enumeration mappings are defined per-parameter in the template and can include translations. When a template with enum parameters is applied, Overvis creates the mapping automatically, so the dashboard and parameter views show the text labels instead of raw numbers.
When importing a template from Excel, Overvis validates the file structure and every field value. Common causes of validation errors:
Missing required sheets — the file must have both an Info sheet and a Params sheet. Any sheet with an unrecognized name causes an error.
Missing required Info fields — read group size and write function must be present on the Info sheet.
Invalid value type or register kind — check that the Type and Register Kind columns use exact values from the Device Templates Reference.
Coil/discrete-input with wrong value type — coil and discrete-input registers must use the bit value type. Other types are not allowed.
Multiplier/shift on incompatible types — bit, string, IP address, and MAC address types do not support multiplier or shift. Set them to 1 and 0 (or leave blank).
Bit fields on non-bit types — bit position and bits amount should only be set for bit and bits value types.
Enum without mappings — parameters with enum value type must include at least one mapping in the Represent As column.
Enum translation mismatch — if enum mappings are translated, each language must have the same number of mappings with the same numeric values.
The error message includes the sheet name, row number, and cell reference to help locate the issue.
If applying a template does not update existing parameters as expected:
Matching is by address and register kind, not by parameter name. A template parameter updates an existing device parameter only when both share the same register address, register kind, bit position, and bits amount. If these differ (e.g. you changed the address in the template), the old parameter stays and a new one is created.
Check for duplicate addresses — if the device has two parameters at the same address and register kind, matching behavior may be unexpected. Clean up duplicates before applying.
Check the alert YAML syntax — invalid YAML prevents alert creation. The Alerts Templates Reference has the full specification.
Check that referenced parameters exist — each alert condition references a parameter by address and register kind. If the referenced parameter is not in the template, the alert cannot be created.
Check the apply options — make sure Add alerts from template is checked in the apply form (and that alert YAML and referenced parameters are valid).
Check for errors — if the import page shows no errors but the template doesn’t appear, try refreshing the page.
Check the correct organization — templates are scoped to your current organization. Make sure you are viewing the correct organization’s templates.
Same name replacement — if a template with the same name, manufacturer, and version already existed, it was replaced. The template is there but the old content was overwritten.
Yes. You can apply templates sequentially. Each apply merges or replaces parameters based on the matching logic (address, register kind, bit position, bits amount). To combine parameters from two templates, apply the first one, then apply the second without enabling Remove device parameters which are missing inside the template.
What happens to existing parameters when I apply a template?
By default, existing parameters are kept. Parameters that match a template parameter (by address, register kind, bit position, and bits amount) are updated with the template’s settings. Template parameters that don’t match any existing parameter are added as new parameters. Enable Remove device parameters which are missing inside the template to delete unmatched device parameters.
There is no bulk re-apply feature. To update all devices using a template, import the updated template, then apply it to each device individually. Use Remove device parameters which are missing inside the template if you want each device to match the template exactly.
Not directly. Templates belong to one organization or to the global library. To share a template, export it as an .xlsx file and import it into the other organization. The global library is shared across all organizations but can only be modified by superusers.
What is the difference between global and organization templates?
Global templates are maintained by Overvis, available to everyone, and read-only. Organization templates belong to your organization, are private to your members, and can be freely edited. Clone a global template to your organization if you need to modify it.
Can I edit individual parameters in a template without re-importing?
No. The web interface only allows editing template metadata (name, manufacturer, version, category, description) and the alert YAML. To change parameter definitions, export the template to Excel, edit the spreadsheet, and re-import.
What happens if I delete a template that devices were created from?
Nothing breaks. The devices keep their parameters and continue operating normally. The device’s reference to the template is cleared, but no parameters or settings are removed.
Device Templates Reference — complete technical specification of the Excel file format, all supported value types, alert YAML syntax, and validation rules.
Overvis continuously reads parameter values from your devices. An alert lets you define conditions on those readings — and get notified by email, SMS, or voice call when something goes wrong. Alerts also maintain a log of every time a condition was triggered and resolved, giving you an audit trail of incidents.
Conditions — rules that compare live parameter readings to threshold values. For example, “temperature is above 8°C” or “parameter has a reading error”.
Actions — notifications to send when conditions become true. You choose the channel (email, SMS, voice call), the recipient, and an optional delay.
Follow-ups — additional notifications for later stages of the incident: when the alert is confirmed by a person, when it resolves on its own, or when nobody has responded for a while.
Overvis evaluates conditions automatically after each parameter reading cycle. When conditions are met, the alert activates and starts executing actions. When conditions are no longer met, the alert resolves automatically.
Give the alert a descriptive name (e.g. “Cold room temperature too high”). The name appears in notifications and in the alert log, so it should be immediately understandable to whoever receives the message. The name can be up to 200 characters long.
The description is optional and can contain additional context.
Each condition monitors one device parameter and compares its value to a threshold.
To add a condition, select a network, then a device on that network, then a parameter on that device. Only tracked parameters are available — untracked parameters are not polled, so there is nothing to compare.
Next, choose a comparison operator and enter a threshold value:
Operator
Meaning
Greater than
Value > threshold
Greater or equal to
Value ≥ threshold
Less than
Value < threshold
Less or equal to
Value ≤ threshold
Equal to
Value = threshold
Not equal to
Value ≠ threshold
Has reading error
Parameter could not be read (no threshold needed)
The threshold is compared against the parameter’s displayed value — the value after any multiplier defined in the parameter settings has been applied. Enter the threshold in the same engineering units you see on the device page (e.g. °C, kW), not in raw register values.
“Has reading error” is a special condition that triggers when the parameter cannot be read at all — for example, the device is offline, or the Modbus address is invalid. No threshold value is needed. To avoid false positives during system startup, reading error conditions are silenced for approximately 2 minutes after the system starts.
Condition logic. If an alert has multiple conditions, you choose how they combine:
Every condition should be satisfied (AND) — the alert activates only when all conditions are true simultaneously.
Any condition triggers the event (OR) — the alert activates when at least one condition is true.
Actions define what happens when the alert activates. Each action specifies:
Channel: Email, SMS, or Voice call.
Recipient: An email address or phone number. Leave empty to use the organization’s default notification email or phone (configured in organization settings). If the recipient is left empty and no default is configured, the notification is skipped.
Delay: How long to wait before sending the notification. Options range from “Immediately” to “If not resolved in 2 hours”.
The delay is useful to avoid false alarms from brief fluctuations. If the alert resolves before the delay expires, the notification is never sent.
Follow-up actions let you escalate or notify at later stages of an incident:
Stage
Meaning
When resolved
The conditions are no longer met and the alert deactivated on its own. Use this to notify that the situation has returned to normal.
When confirmed
Someone has acknowledged the alert (see Confirming alerts below). Use this to notify the team that the issue is being handled.
If not confirmed and not resolved in…
Nobody has acknowledged the alert within the specified time. Use this for escalation — for example, call a manager if the original SMS was not confirmed within 30 minutes.
For the “not confirmed” stage, you select a timeout (from 5 minutes to 48 hours). If the alert is confirmed or resolves before this timeout, the follow-up notification is cancelled.
Each follow-up specifies a channel (email / SMS / voice call) and a recipient, same as actions.
flowchart LR
A["Inactive<br/>(monitoring)"] -->|"Conditions<br/>met"| B["Active<br/>(notifications sent)"]
B -->|"User<br/>confirms"| C["Confirmed"]
B -->|"Conditions<br/>clear"| D["Resolved"]
C -->|"Conditions<br/>clear"| D
D -.->|"Ready for<br/>next incident"| A
Inactive — conditions are not met. The alert is monitoring but has not triggered.
Active — one or more conditions became true (depending on the AND/OR logic). Overvis creates an alert record in the log and begins executing “Do…” actions. A confirmation code is generated. If “If not confirmed and not resolved in…” follow-ups are configured, their escalation timers begin counting down.
Confirmed — someone acknowledged the alert via email link or SMS reply (see below). “When confirmed” follow-ups execute, and any pending escalation timers are cancelled.
Resolved — the conditions are no longer true. Overvis closes the alert record and executes “When resolved” follow-ups (if a “started” notification was sent). Any remaining pending actions are cancelled. The alert returns to Inactive and is ready to activate again on the next incident.
While the alert is Active and unconfirmed, escalation follow-ups (“If not confirmed and not resolved in…”) fire at their configured timeouts. This is not a separate state — the alert remains Active, and escalation can happen multiple times with different timeouts (e.g. SMS after 15 minutes, voice call after 1 hour).
Each time an alert activates and later resolves, a separate alert record is created in the log. An alert can only have one active (unresolved) record at a time.
When an alert fires, notifications include a way for the recipient to confirm (acknowledge) the alert:
Email notifications contain a confirmation link. Clicking it opens a page that confirms the alert and shows the event details.
SMS notifications include a 5-digit confirmation code. Reply with this code to the same number to confirm.
Confirmation serves two purposes:
It triggers any “When confirmed” follow-up actions (e.g. notifying the team that someone is handling the issue).
It cancels any pending “If not confirmed” escalation actions.
Once confirmed, the alert remains active until the conditions clear and it resolves automatically. Confirmation does not silence or resolve the alert — it only signals that a person is aware of the problem.
The Alerts page lists all alerts in the current organization. For each alert, you can see:
The alert name and description.
A bell icon colored by log level. If the alert is currently active, the icon is highlighted.
A conditions table showing the network, device, parameter, condition, last reading value, and reading timestamp for each condition. Triggered conditions are visually highlighted.
An actions summary listing what notifications are configured.
From this page, you can access each alert’s Settings, Log, Duplicate, or Delete actions.
The alert log records every time an alert activated and resolved. There are two views:
Organization-wide log (Alerts → Alerts Log in the sidebar) — shows all alert records across all alerts, newest first.
Per-alert log (open an alert → Log) — shows records for a single alert only.
Each log entry shows:
Column
Content
Date
When the alert activated.
Event Name
The alert name, prefixed by log level (e.g. “Warning: Cold room temperature too high”).
Current Status
Active, Confirmed on (date), or Resolved on (date).
You can expand each entry to see timestamped details — a chronological list of what happened during the incident (conditions triggered, notifications sent, confirmation received, resolution).
Technical managers can clear the log for an alert — removing finished (resolved) records that are older than a chosen period: 1 day, 1 week, 1 month, 1 year, or all finished records.
If you manage many similar devices, you can include alert definitions in a device template. When the template is applied to a device, Overvis creates the alerts automatically — saving you from configuring the same thresholds and actions for each device individually.
Alert templates are written in YAML and attached to the device template either through the web interface or in the template Excel file. See the Alerts Templates Reference for the YAML syntax and examples.
The SMS log (accessible from the Alerts section in the sidebar as “SMS Log”) shows a record of all SMS and voice call messages sent by the alert system. Each entry includes:
The date and time the message was sent.
The associated alert name.
The message text.
Sender and receiver phone numbers.
Whether it was an SMS or a voice call.
Delivery cost.
This is useful for verifying that notifications were delivered and for tracking SMS and voice call usage and costs.
The parameter is not tracked. Only tracked parameters are polled for readings. If the parameter is not tracked, Overvis has no values to compare. Go to the device page and make sure the parameter has the “Tracked” flag enabled. See Behavior Flags.
The device or network is disabled. Disabled devices and networks do not process alerts. Check that both the network and the device are enabled.
The parameter has no recent readings. If the parameter has never been read (e.g. the device has not been polled yet), conditions cannot evaluate. Check the “Last reading” column on the alerts overview page — if it shows ”-”, the parameter has not been read yet.
Threshold is in wrong units. The threshold is compared against the displayed value (after multiplier). If you enter a raw register value instead of the engineering value, the condition may never match. Make sure the threshold uses the same units shown on the device page.
Condition logic mismatch. If you have multiple conditions with “Every condition should be satisfied” (AND), all of them must be true simultaneously. Check whether one condition is preventing the alert from activating.
No default recipient configured. If you left the recipient field empty, Overvis uses the organization’s default notification email or phone. If neither is configured, the notification is silently skipped. Set default recipients in organization settings, or enter an explicit recipient in the alert action.
Email going to spam. Check your spam or junk folder. Add the Overvis notification sender address to your email whitelist.
SMS is disabled for the organization. If SMS sending has been disabled (e.g. due to billing), SMS and voice call notifications will not be delivered. Check if a notice about disabled SMS appears at the top of the Alerts page.
Delay has not expired yet. If you configured a delay (e.g. “If not resolved in 30 min”), the notification will not be sent until the delay period passes. If the alert resolves before that, the notification is cancelled.
Use action delays. Set a delay like “If not resolved in 5 min” or longer. Brief fluctuations that resolve quickly will not trigger notifications.
Adjust thresholds. If the threshold is too close to the normal operating range, small variations will trigger the alert. Add a margin to account for normal fluctuation.
Use AND logic for multiple conditions. Requiring all conditions to be satisfied simultaneously reduces false positives from isolated spikes.
“When resolved” follow-ups are only sent if at least one activation notification was already sent or scheduled. If the alert activated and resolved too quickly (before any “Do…” action fired), no resolution notification is sent. This is intentional — it avoids orphan “resolved” messages for events that were too brief to notify about.
Email confirmation link. Make sure you are clicking the confirmation link from the original notification email. Links are specific to each alert event — a link from a previous event will not work for a new one.
SMS confirmation code. Reply with the 5-digit code to the same phone number that sent the SMS. The code is valid only while the alert is active and has not been confirmed yet.
Alert already resolved. If the alert resolved before you confirmed, the confirmation page will indicate that the event has already been resolved. Confirmation is no longer needed in this case.
Yes. Each action and follow-up has its own recipient field. You can configure one alert to email an operator and another to SMS a manager. Within a single alert, you can add multiple actions to notify different people through different channels.
If a device cannot be reached, parameters will have reading errors. You can use the “Has reading error” condition to be notified when a device stops responding. After the system starts, reading error conditions are silenced for approximately 2 minutes to avoid false alarms during startup.
Can I temporarily disable an alert without deleting it?
There is no “pause” button in the alert settings. To temporarily stop an alert from firing, you can either remove the conditions or actions and restore them later, or set all actions to “Nothing” (no notification). Alternatively, duplicating the alert before editing preserves the original configuration for easy restoration.
Overvis evaluates alert conditions immediately after each parameter reading. The detection speed depends on the polling interval configured for the network — typically a few seconds to a minute. There is no additional delay between a parameter reading and the condition evaluation.
What is the difference between actions and follow-ups?
Actions (“Do…”) fire when the alert first activates. They are the initial notifications. You can add a delay to them (e.g. “If not resolved in 10 min”) to filter out brief events.
Follow-ups (“Follow up…”) fire at later stages: when the alert resolves, when someone confirms it, or when nobody has confirmed it within a timeout. They are used for escalation and resolution tracking.
No. Clearing the log only removes resolved (finished) alert records that are older than the selected period. Active alert records and the alert configuration itself are not affected.
Yes. Expand an alert log entry to see a detailed timeline of all notifications sent during the incident, including timestamps and recipients. For SMS and voice call delivery details, check the SMS Log page.
The Parameter Values Report is an interactive tool for exploring historical data from your tracked parameters. It combines a time series chart, a data table, and export capabilities on a single page. You can overlay multiple parameters from different devices, zoom into specific time intervals, and download the raw data as CSV or Excel.
Main menu — go to Reports > Parameter Values. The report opens with no parameters selected; use the parameter tree to choose what to display.
Device details page — click the chart icon next to any tracked parameter. The report opens with that parameter already loaded.
Parameter page — click the Readings action link in the sidebar.
Monitoring mode — the same report is available in the read-only monitoring interface. Users with view-only access are redirected here automatically.
When you open the report from a device or parameter page, the URL contains paramIds=..., so the chart loads immediately with data for those parameters.
The parameter tree at the top of the page shows your organization hierarchy: networks, devices, and their parameters. Only tracked parameters (those with history recording enabled) appear in the tree.
Expand the tree nodes to find the parameters you want to analyze.
Check the parameters you want to include. A counter next to the tree shows how many parameters are currently selected. There is a configurable limit on how many parameters can be displayed at once (shown in the placeholder message below the tree).
Click Show report to load the data.
When you change the parameter selection, the time range resets to the Last 24 hours preset if the current preset is Custom. If you already have a non-Custom preset selected, it keeps that preset. The chart and table reload with the new selection.
Two date-time pickers (YYYY-MM-DD HH:mm) let you set an arbitrary from and till. You can type directly into the fields or use the calendar popup. Press Enter to apply a typed value, or Escape to discard it.
When you pan or zoom on the chart (see below), the preset automatically switches to Custom and the date-time fields update to reflect the new range.
Decimal precision — a dropdown (0 through 6 decimal places) controls how values are displayed in the chart axis labels, tooltip, legend, and table. The default is 2 decimal places.
Expand/collapse — toggles the chart between normal and double height.
The chart displays parameter values over time as colored lines. Each selected parameter gets its own line with a distinct color (up to 10 colors, which then cycle). If a device was offline or polling was interrupted, the chart shows breaks in the line where no readings were recorded.
Hovering over the chart shows a tooltip with the timestamp and the value of each visible parameter at that point. The closest line is shown in bold. When the visible time window is under 10 minutes, timestamps include seconds.
Drag horizontally to pan the time window left or right.
Hold Shift and drag to select a rectangular area and zoom into it.
Scroll the mouse wheel over the chart to zoom in or out, centered at the cursor position.
On touch devices: single-finger drag to pan, two-finger pinch to zoom.
Quick zoom buttons below the chart let you snap to a fixed duration (10 min, 15 min, 30 min, 1 hour, 8 hours, 24 hours) ending at the current view’s right edge.
Step buttons (< and >) shift the window left or right by one window-width.
All navigation updates the date-time fields and the data table in sync.
Each legend row has inline multiplier (×) and shift (+) controls. These let you visually rescale individual lines so that parameters with different units or magnitudes can be compared on the same chart.
Multiplier — scales the parameter’s values. Enter a number and press Enter to apply (e.g., enter 0.001 to convert millivolts to volts).
Shift — offsets the parameter’s values up or down.
Normalize — automatically calculates a multiplier and shift to fit the line within the currently visible Y-axis range.
Reset — restores the multiplier to 1 and the shift to 0. Only appears when the line has non-default transforms.
Transforms are purely visual — they affect the chart display only, not the data table or exported data.
By default, the Y-axis shows a scale that fits all visible lines. Clicking on a line in the chart pins the Y-axis labels to that specific parameter’s scale (the legend entry appears highlighted). Click again or click a different line to change the reference. Clicking away from any line (on the chart background) clears the reference and returns to the auto-fitting scale.
Below the chart, a table lists readings within the current time window.
Columns are:
Column
Content
Time
Timestamp of the reading
Parameter columns
One column per selected parameter, showing the device name in the header and the parameter name below it
Readings from different parameters that occur within 60 seconds of each other are merged into the same row. As you pan or zoom the chart, the table updates to show only the rows within the visible window.
The export form appears below the data table when parameters are selected. It has its own from/till date pickers (date only, no time — exports always cover full days) that are independent of the chart view range.
Set the from and till dates for the export period.
Choose the format: CSV or Excel (XLSX).
Click Download. The file downloads in a new browser tab.
The exported file contains all raw readings (not sampled) for the selected parameters within the chosen date range. The date pickers default to the last 7 days. Timestamps in the exported file use your browser’s local timezone.
When viewing the report with parameters selected, a save form appears inline next to the parameter tree’s action bar:
Enter a name for the report (minimum 3 characters).
Click Save report. The report stores the current parameter selection and view state (decimal precision, line visibility, multiplier/shift transforms, and the selected preset).
When viewing a saved report, the save form is replaced with an update form (the page heading may read Update saved report). You can change the name, modify the parameter selection, adjust line transforms, and click Update report to save the changes.
Open Reports → Parameter Values, then use Saved reports in the readings section to open the list of saved reports (not a separate top-level menu item). The list shows each report’s name and creation date.
For each saved report, you can set up automatic delivery of the readings data to email recipients:
Open the saved report’s mailing settings (gear icon in the saved reports list).
Enter an email address.
Choose a period: Daily, Weekly, or Monthly.
Choose a format: Excel (XLSX) or CSV.
Click Add recipient.
You can add multiple recipients with different periods and formats. Each email-period-format combination must be unique per report.
The mailing list table shows the following for each recipient:
Column
Content
Email
Recipient email address
Last sent
Date when the report was last sent to this recipient
Sending error
Error message if the last send attempt failed
Next sending
Scheduled date for the next report delivery
Period
Daily, Weekly, or Monthly
Format
XLSX or CSV
The automated mailing sends data for the previous period: daily mailings include the previous day, weekly include the previous 7 days, and monthly include the previous month. Timestamps in mailed reports use UTC.
The report URL preserves the full view state in the URL hash, including the time range, decimal precision, and per-line visibility/transform settings. You can copy the URL from the browser address bar and share it — anyone with access to the organization will see the same view.
Gaps indicate periods when no readings were recorded. This typically happens when:
The device was offline or the gateway lost its internet connection.
Polling was temporarily interrupted (e.g., during a network reconfiguration).
The parameter was added to tracking after some data had already been collected for other parameters.
There is no corrective action for past gaps — they reflect the actual data availability. To prevent future gaps, ensure the gateway has a stable internet connection and the device is powered on.
Export File Contains No Data or Fewer Rows Than Expected
If viewing a long range (e.g., Last 365 days), note that the chart samples up to 1000 points per parameter for responsive performance. The full data is available via export.
There is a per-deployment configurable limit. The exact number is shown in the placeholder message below the parameter tree when no parameters are selected (same wording as in the app, e.g. Please select up to {} parameters to display. — with the limit filled in, such as 10). If you need to compare more parameters, create multiple saved reports with different parameter sets.
No. The chart shows up to 1000 sampled data points per parameter for the visible window. This sampling ensures the chart remains responsive even over long time ranges. For complete raw data without sampling, use Download on the export form, which includes all readings within the chosen date range.
Yes. Copy the URL from the browser address bar — it includes the current time range, decimal precision, and line transform settings in the URL hash. Anyone with access to the same organization can open the link and see the same view. They must be logged in to Overvis.
What is the difference between chart data and exported data?
The chart and table display sampled data — up to 1000 points per parameter, spread across the visible time window. This is sufficient for visual analysis but is not the full dataset.
The export feature produces a file with all raw readings — every recorded value for the selected parameters within the export date range. Use exports when you need complete data for external analysis or archiving.
Why are some table rows missing values for certain parameters?
The table merges readings from different parameters that occur within 60 seconds of each other into the same row. If a parameter did not report a value near that timestamp, its cell shows a dash (-). This is normal when parameters have different polling intervals or reporting frequencies.
What happens if I delete a saved report that has automated mailing?
Deleting a saved report also removes all associated mailing records. Recipients will stop receiving automated reports. A confirmation step is shown before deletion.
Can I use the report in the monitoring (view-only) interface?
Yes. The report is available in the monitoring interface at the same URL pattern. Users with view-only access can view charts, tables, and use the export feature. However, saving reports and configuring automated mailing require manage-level access.
Overvis Cloud Documentation
Resource Consumption Report
The Resource Consumption Report is a tool for analyzing accumulated counter and meter data, showing resource usage growth over selected time periods segmented into half-hour, hourly, or daily intervals.
This report helps you analyze readings from parameters that represent continuous resource usage like energy meters (kWh), water meters (m³), gas meters, and any accumulating counter values. If a parameter value continuously grows over time, this report can analyze its growth patterns.
The report divides the selected time range into segments (half-hour, hour, or day). For each segment, it finds the highest recorded reading within that segment and subtracts the latest reading recorded before the segment started. This difference — the delta — represents how much the counter grew during that interval. If the parameter has a multiplier or shift configured, those are applied to the delta (delta × multiplier + shift).
Reports are organized as a tree. Main branches (top-level) each produce a separate chart. Branches can contain child nodes — other branches, individual parameter values, formulas, or links to branches from other reports. A branch’s value equals the sum of all its children, so you can group meters by department, building, or resource type and see both the total and the breakdown.
Consider a facility with multiple departments, each with their own meters:
Department 1
Energy Meter 1 (E11) - kWh
Energy Meter 2 (E12) - kWh
Water Meter 1 (W11) - m³
Department 2
Energy Meter 3 (E21) - kWh
Water Meter 2 (W21) - m³
You can structure a report to analyze this data:
Total Resources
├── Total Energy
│ ├── Department 1 Energy
│ │ ├── E11
│ │ └── E12
│ └── Department 2 Energy
│ └── E21
└── Total Water
├── Department 1 Water
│ └── W11
└── Department 2 Water
└── W21
With this structure, the report shows total energy and water consumption for the entire company, broken down by department, down to individual meters. You can compare departments side by side and identify which department or meter contributes most to overall usage.
The report view page shows interactive bar charts — one per main branch. Each bar represents a time segment, and its height shows the consumption delta for that period. If level markers are configured, they appear as horizontal reference lines on the chart and the bars are color-coded when they exceed a threshold.
A legend above the charts lists all main branches as checkboxes. Uncheck a branch to hide its chart. A dropdown at the top lets you switch between reports in the same organization.
Below the charts, three export buttons are available: Download as Excel, Download as PDF, and Send PDF to e-mail. Only the branches currently visible (checked in the legend) are included in exports.
Detailed report — a checkbox next to the export buttons (visible to managers only). When checked, the exported file includes the full hierarchy of branches, sub-branches, individual meter readings, and formula calculations. When unchecked (or when viewing as a monitor), the export shows only the main (top-level) branches — a summary suitable for executive reports.
Send PDF to e-mail — click the button, enter the recipient’s email address, and the report is generated and delivered immediately. This uses the same time range, segmentation, and branch selection as the regular PDF export.
Navigate to Reports → Resources Consumption and click Create new to open the report constructor. A report is defined by its tree structure — you build a hierarchy of branches that describes how your consumption data should be grouped and calculated.
Each node in the tree has a type that determines where its value comes from:
Type
Purpose
Branch
A container for child nodes. Its value equals the sum of all children. Use branches for grouping — by department, building, resource type, etc. You can nest branches up to 5 levels below the root.
Value
References a single device parameter. Displays that parameter’s consumption (delta) per time segment. You select the parameter through a three-step dropdown: network → device → parameter.
Calculate
Evaluates a formula that combines multiple parameters. Reference parameters by their ID with the # prefix (e.g. #561 * 2 + #558). See Using Formulas for syntax details.
Link
References an existing branch from this or another report in the same organization. The link picker shows all branches from all reports, so you can reuse common structures without duplicating them.
To build the tree, start by clicking Add main branch to create a top-level (root) branch. Within each branch, click Add branch to add children of any type. The tree grows from top to bottom — main branches at the top, leaf nodes (Value, Calculate, Link) at the bottom.
Main (top-level) branches have two additional settings that affect the online view:
Category — an optional label that groups related branches under a heading. For example, you might group all energy branches under “Energy” and all water branches under “Water”. Branches without a category appear first, followed by category groups. Categories are only used in the online view and do not appear in Excel/PDF exports.
Level markers — up to 4 threshold values, each with a color. On the chart, these appear as horizontal reference lines and as color-coded stacked bar segments. For example, you might set a yellow marker at 50 kWh and a red marker at 100 kWh to highlight when consumption exceeds expected levels. Level markers are only used in the online view and do not appear in Excel/PDF exports.
When viewing a report, you choose the time range and segmentation interval using the controls above the charts.
The time range determines which period to analyze. The preset dropdown offers Last day, Last 7 days, and Last 30 days, or you can select Custom and pick specific dates with the date pickers.
The segmentation determines how the time range is divided into intervals: By half-hour (30-minute intervals), By hour, or By date (daily intervals). Smaller intervals produce more detail but also more data points — on large date ranges with many parameters, you may need a larger interval to avoid hitting export limits.
Charts and exports use the timezone detected from your browser. All segment boundaries are aligned to your local timezone.
The Calculate node type uses formulas to combine multiple parameters. Formulas reference parameters by their ID (prefixed with #) and are evaluated for each time segment using that segment’s delta values.
Example formula:
(#561 + 10) / 2 + #558
This formula takes the delta of parameter #561, adds 10, divides by 2, then adds the delta of parameter #558.
If a referenced parameter has no data for a given segment (e.g. the device was offline or the parameter was deleted), its value is treated as 0.
Users with the manager role can create, edit, and delete reports, and have access to the Detailed report checkbox for exports.
Monitors can be granted view-only access to a specific resource consumption report. They can view the charts and download exports, but only the short (non-detailed) version — the detailed checkbox is hidden. Monitors cannot create or edit reports. Monitor access is configured when inviting a user to the organization, where you can bind the monitor role to a specific report.
The requested combination of date range, segmentation, and number of parameters exceeds the export limit. The error message shows the nearest available date for your chosen segmentation.
Solutions:
Reduce the date range.
Use a larger segmentation interval (e.g. “By date” instead of “By hour”).
Hide some main branches before exporting — only visible branches (checked in the legend) are included.
The parameters you selected are likely not accumulating counters. This report calculates the difference (delta) between readings within each segment. If the parameter value doesn’t change between readings (e.g. it’s an instantaneous measurement like temperature), all deltas will be zero.
Solutions:
Verify the selected parameters represent accumulating counters (energy, water, gas meters, etc.).
Negative deltas can occur when a meter counter resets or rolls over.
Solutions:
Check the raw parameter readings on the device page to confirm the counter reset.
If the parameter has a multiplier or shift configured, verify those values are correct — the delta is computed as (value - previous_value) × multiplier + shift.
A parameter ID in the formula doesn’t match any existing parameter (missing IDs are treated as 0).
The formula syntax is invalid (parse errors default to 0).
Solutions:
Hover over each parameter on the device page to confirm its ID.
Verify all #id references in the formula match existing parameters in your organization.
Check the formula for syntax errors — when entering a formula, parameter names appear below the input field and missing or incorrect IDs are highlighted.
The online chart may clamp the start date if the requested range would exceed the chart data point limit. The export uses the full requested date range. This means you may see a shorter time range in the chart than what appears in the downloaded XLSX/PDF.
Any parameter that represents an accumulating counter — the value grows over time. Common examples: energy meters (kWh), water meters (m³), gas meters, run-hour counters, production counters. Parameters that represent instantaneous values (temperature, pressure, voltage) are not suitable for this report; use the Parameter Values Report instead.
Can I include parameters from different devices in one report?
Yes. The tree structure lets you combine parameters from any devices across any networks in the same organization. This is useful for aggregating consumption across multiple meters or locations.
For each time segment, the system finds the highest recorded reading within that segment and subtracts the latest reading recorded before the segment started. If there is no prior reading, zero is used. The result is then multiplied by the parameter’s multiplier and adjusted by its shift value (if configured).
Yes, use the Link node type when creating a report. It lets you reference any branch from any report in the same organization, so you don’t have to rebuild common structures.
No. Resource Consumption Reports can only be sent via email manually using the Send PDF to e-mail button. For scheduled automatic report delivery, see the Parameter Values Report.
If a parameter referenced by a Value node is deleted, that node will show no data (empty deltas). If a parameter referenced in a Calculate formula is deleted, its value is treated as 0 in the formula. The report structure itself is preserved — you can edit it to replace the missing parameter.
Yes. Exports are limited by the total number of data points (segments × parameters). The exact limits depend on the format — PDF has a lower limit than Excel. If you exceed the limit, you’ll see a “Segment limit exceeded” error with a suggested date range. Reduce the date range or use a larger segmentation interval.
Overvis Hazard Analysis and Critical Control Points (HACCP) Report
HACCP (Hazard Analysis and Critical Control Points) is a systematic food safety management approach that identifies, evaluates, and controls hazards throughout the food production and storage chain. In refrigeration and cold chain operations, HACCP requires continuous temperature monitoring at critical control points, with documented evidence that safety limits are maintained.
The Overvis HACCP Report tool automates temperature monitoring compliance for refrigeration and freezer control points. It pulls temperature readings from monitored devices and produces structured reports that:
Display temperature values at configurable time intervals (from 15 minutes to daily)
Detect when temperatures exceed operational or critical thresholds
Flag missing data or unknown equipment status
Support documenting corrective actions for detected exceptions
Enable formal review and sign-off by authorized personnel
Export to Excel for record-keeping and audits
This tool supports temperature monitoring documentation requirements under common HACCP frameworks, including Codex Alimentarius principles and EU food hygiene regulations (EC 852/2004). It is designed specifically for refrigeration and freezer HACCP review and is not a general-purpose HACCP system covering all hazard types.
Each report is scoped to a single organization. If you manage multiple facilities, generate separate reports for each organization.
All temperatures are treated as Celsius. All date and time calculations use the organization’s configured timezone, including correct handling of daylight saving time transitions.
Configure the report (see Report Builder). Go to Reports > HACCP: the action tab reads HACCP report, while the page heading is HACCP. Set the report name, date range, time interval (cadence), and temperature display mode. Add one or more temperature parameters by selecting a network, device, and parameter for each. Optionally configure setpoint, defrost, and on/off parameters. Set operational and critical thresholds as needed.
Save as a template (optional, see Report Templates). Save the current configuration as a template for future reuse. Templates store everything except the date range, so you can quickly regenerate reports for new periods without reconfiguring parameters and thresholds each time.
Generate the report (see Generated Report). Click Generate report to produce the report from live data. The exception summary appears immediately, showing any threshold violations, data gaps, and unknown equipment states across the selected period.
Document corrective actions (see Corrective Action Notes). Review the exception summary and add corrective action notes to any exceptions that require them. Notes are attached to specific exception intervals and are included in the final report.
Submit review (see Report Review). An authorized user adds review comments and submits the review. This creates a permanent, immutable snapshot of the report — including all readings, exceptions, and corrective action notes as they were at generation time.
Export to Excel (see Excel Export). Export the report to an Excel file at any point after generation, whether before or after review. The exported workbook contains the same data shown in the browser.
To open the HACCP report, go to Reports > HACCP in the main navigation menu (1) (tab HACCP report; builder page heading HACCP).
The feature is organized into three sections (2), accessible via navigation tabs at the top of the page:
HACCP report — short tab label; the builder page heading is HACCP. The report builder where you configure parameters, generate reports, document corrective actions, and submit reviews.
Templates — short tab label; the templates list page heading is HACCP Templates. Saved report configurations that can be loaded into the builder for quick regeneration with new date ranges.
Reviewed Reports — short tab label; the list page heading is Reviewed HACCP Reports. All submitted report snapshots, available for viewing and export.
The navigation tabs remain visible on all HACCP pages, including template detail, delete confirmation, and reviewed report detail pages.
The report builder is the main working area of the page whose heading is HACCP (the action tab label is HACCP report). It allows you to configure which temperature parameters to monitor, set the reporting period and time interval, define acceptable temperature thresholds, and generate the report.
The builder is always visible at the top of that page. After you generate a report, the results appear below the builder. You can freely adjust builder settings without losing the generated report or any draft corrective action notes — changes only take effect when you click Generate report again. Regenerating the report replaces the previous results and discards all draft corrective action notes.
Report name — a free-text name for the report. This name appears in the report header, in template and reviewed report lists, and in the exported Excel file. Required.
From date / Till date — the date range for the report, inclusive. Defaults to the last 7 days. You can select any date range; the system enforces a total dataset size limit that depends on the number of parameters and interval size. All dates and times throughout the report use the organization’s stored timezone. If you need a different timezone for the organization, ask your Overvis administrator or support — the UI may not expose a dedicated timezone field under Organization settings in all deployments.
Interval size — the time cadence at which readings are grouped into segments. Available options:
1 day — one segment per calendar day
1 hour — segments aligned to each hour of the day
30 minutes — segments aligned to each half-hour
15 minutes — segments aligned to each quarter-hour
Shorter intervals produce more detailed reports but increase the report size. The combination of date range, interval size, and number of configured parameters determines the total dataset size.
Temperature value — controls how the temperature reading is computed for each segment when multiple readings exist within it:
Start of interval — the reading closest to the beginning of the segment
Average — the arithmetic mean of all readings in the segment
Minimum — the lowest reading in the segment
Maximum — the highest reading in the segment
This choice affects both the displayed values and threshold exception detection. For example, if Average is selected, a brief spike above a critical limit may not trigger an exception if the average stays within range.
The temperature parameters list defines which control points are included in the report. Each entry represents one monitored temperature parameter along with its optional supporting parameters and thresholds.
You must configure at least one temperature parameter before the report can be generated. Up to 100 parameters can be included in a single report.
To add a parameter, click Add temperature parameter below the list. To edit an existing parameter, click its name in the list. To remove a parameter, click the trash icon on its row. To reorder parameters, drag using the handle on the left side of each row — the list previews the new position while dragging.
The parameter configuration dialog opens when you add or edit a temperature parameter. It contains the following sections:
Temperature parameter (required) — the primary temperature reading for this control point. Select the network, then the device, then the specific parameter. Only tracked parameters are available for selection — these are device parameters that Overvis reads periodically in the background and stores in the database. If a parameter you need is not listed, make sure it is set up as tracked in the device configuration.
Setpoint parameter (optional) — a reference setpoint value used for deviation coloring in the report table. When configured, each cell is colored on a blue-to-white-to-orange gradient based on how far the temperature deviates from the setpoint. The deviation scale uses steps of 1°C per color level. The setpoint does not affect exception detection — it is used for visual indication only.
To add a setpoint, click Setpoint parameter to expand the section, then select the network, device, and parameter. To remove it, click the trash icon next to the section name.
Defrost parameter (optional) — indicates whether the equipment is in a defrost cycle. When defrost is active, the corresponding cells are highlighted with a yellow background in the report table. Defrost status is shown for informational context only — it does not create exceptions and does not suppress threshold violations.
On/off parameter (optional) — indicates whether the equipment is running. When the equipment is off, the corresponding cells are shown with a grey background. Equipment being off is informational and does not create exceptions on its own. However, threshold violations are still detected even when equipment is off. If the equipment is on (or its state is unknown) and the temperature reading is missing, this is flagged as an unknown status exception.
For both defrost and on/off parameters, two additional controls are available:
Evaluation mode — determines how the boolean state is derived from readings within a segment:
Any true — the state is considered active if any reading in the segment matches the true value
Any false — the state is considered active if any reading in the segment does not match the true value
Use start-of-interval value — only the reading closest to the segment start is used (this is the same “closest to start” logic used by the Temperature value > Start of interval mode, applied here to the boolean parameter instead of the temperature parameter)
True value — the numeric value that represents the active state. Defaults to 1. All parameters are compared numerically regardless of how they may be displayed elsewhere in Overvis. For equipment where the active state is represented by 0 (inverse wiring), set the true value to 0.
Each temperature parameter can have up to four threshold values configured. Thresholds define the acceptable temperature ranges for a control point and drive exception detection in the generated report.
Operational thresholds define the normal operating range:
Operational low — the lowest acceptable temperature during normal operation. Temperatures below this value trigger an operational deviation exception.
Operational high — the highest acceptable temperature during normal operation. Temperatures above this value trigger an operational deviation exception.
Operational deviations indicate that the temperature has drifted outside the desired range but has not yet reached a safety-critical level. These typically require investigation and corrective action to prevent further drift.
Critical thresholds define the absolute safety limits:
Critical low — the minimum safe temperature. Temperatures below this value trigger a critical limit breach exception.
Critical high — the maximum safe temperature. Temperatures above this value trigger a critical limit breach exception.
Critical limit breaches indicate a direct food safety risk and require immediate corrective action and documentation.
Set critical thresholds based on the critical limits established in your HACCP plan. Operational thresholds should be set tighter than critical limits to provide early warning before a critical breach occurs — this gives your team time to take corrective action before food safety is compromised.
All threshold values are optional. When a threshold is not configured, the corresponding exception type is not checked for that parameter. Within each pair (operational or critical), the low value must not exceed the high value.
Threshold violations are detected based on the computed segment value (as determined by the Temperature value setting), not from raw individual readings within the segment. If a critical threshold is violated, it takes precedence over an operational threshold violation for the same segment.
After clicking Generate report, the report appears below the builder. It consists of three areas: a header block (with legend, exception totals, and review form), an exception summary table, and a detailed table that loads on demand.
The header displays the report name, selected date range, and interval size. Next to the metadata, a color legend shows the meaning of all visual styles used in the report:
Deviation gradient — an 11-step blue-to-white-to-orange scale showing how far the temperature deviates from the setpoint. Each step represents 1°C. Blue indicates below setpoint, orange indicates above setpoint, white indicates close to setpoint.
Operational threshold breach — a thin inset border in blue (below the operational low limit) or red (above the operational high limit), without bold text. Thickness distinguishes this from a critical breach at the same side (same colors).
Critical threshold breach — a thicker inset border in the same blue or red, plus bold text. Critical uses a heavier outline than operational so the two are easy to tell apart without changing hue.
Defrost — yellow background indicates the equipment is in a defrost cycle.
Off — grey background indicates the equipment is turned off.
Missing or unknown value — italic text (often with a - in the cell) indicates a missing temperature or unknown/inferred context; see tooltips for detail.
Below the legend, exception totals are shown:
Total exceptions — the total number of detected exception intervals across all parameters.
Exceptions without corrective action — how many exception intervals do not yet have a corrective action note attached.
Unknown status/data intervals — the number of intervals where data was missing or equipment status was unknown.
The exception summary table is the primary HACCP review surface. It lists every detected exception interval across all configured parameters, sorted by parameter and time.
Each row shows:
Parameter — the temperature parameter name, with network and device shown above it for context.
Exception — one of the three exception types (see below); the live table uses the short header Exception.
Start / End — the local date and time when the exception interval began and ended.
Duration — how long the exception lasted.
Min / Max — the minimum and maximum computed segment values across all segments in the exception interval. These reflect the selected Temperature value mode (Start of interval, average, minimum, or maximum), not raw individual readings.
Limit / Setpoint — the threshold value or setpoint that was violated.
Corrective action — whether a corrective action note has been added for this exception.
The report detects three types of exceptions. When multiple exception conditions apply to the same time segment, the highest-priority type takes precedence.
Critical limit breach (highest priority) — the computed temperature value for a segment is below the configured critical low threshold or above the configured critical high threshold. This represents a direct food safety hazard that requires immediate corrective action and documentation. In the detailed table, critical breaches are shown with bold text and a thicker colored inset border (blue for low, red for high).
Operational deviation (medium priority) — the computed temperature value is outside the operational threshold range but has not reached a critical limit. This indicates the system is drifting from its target operating conditions and may require adjustment to prevent a critical breach. Operational deviations use the same blue/red inset colors as critical on that side, but a thinner border and no bold text.
Unknown status/data (lowest priority) — temperature data is missing or an equipment status parameter has an unknown state. This can occur when:
The temperature reading is missing and equipment is confirmed to be on
The temperature reading is missing and no on/off parameter is configured
The temperature reading is missing and the on/off state itself is unknown
A configured defrost or on/off parameter has no readings in the segment
This exception type covers two distinct situations under one label: missing temperature readings (a monitoring failure) and unresolved equipment states (an equipment status question). Both appear as “unknown status/data” in the exception summary, but the detailed reason is shown in the tooltip or cell annotation. If the equipment is confirmed to be off and the temperature reading is missing, this is not flagged as an unknown status exception.
How exception intervals are formed: the report examines each time segment independently, classifies it according to the rules above, and then merges consecutive segments of the same exception type into continuous intervals. When the exception type changes between adjacent segments, a new interval begins. For example, two hours of operational deviation containing a 20-minute critical breach in the middle produces three separate intervals: operational deviation, critical limit breach, and operational deviation.
Important: defrost and off states are informational only — they do not create exceptions on their own and do not suppress threshold violations. If a critical or operational threshold is violated during a defrost cycle or while equipment is off, the exception is still detected and reported. In the detailed table, threshold violation indicators (borders and bold text) are overlaid on top of the defrost or off background color, so both states remain visible simultaneously (see Cell visual styling).
You can attach corrective action notes to any exception interval in the summary. Notes serve as documentation of what action was taken in response to a detected exception.
To add a note, click the corrective action cell for the relevant exception row. Each note records the text you enter, your display name, and the timestamp when it was created. You can edit or delete notes freely while working on the generated report.
Once the report is submitted for review, all corrective action notes become part of the immutable reviewed snapshot and can no longer be modified.
The detailed table shows the full time-segment matrix for all configured parameters. It is hidden by default and is not loaded until you explicitly expand it by clicking Show detailed table. This keeps the initial report generation fast, since the detailed table can be large.
Each row in the table represents one configured temperature parameter (identified by network, device, and parameter name). Columns are organized by day, with each day containing:
Setpoint — the setpoint value at the start of the day. If the setpoint changes during the day, a * marker appears next to the day-start value. A - is shown when no setpoint reading exists for that day.
Segment columns — one column per time segment in the day. Each cell shows the computed temperature value (or - for missing data) with visual styling that conveys the segment’s status at a glance.
Daily status — a rollup of the worst condition observed during the day, using the following precedence: critical breach > operational deviation > no data > unknown values > OK.
Cell visual styling uses the following precedence (highest priority first):
Off (grey background) — equipment is off in this segment.
Defrost (yellow background) — equipment is in defrost cycle.
Deviation coloring (blue-to-orange gradient) — temperature deviation from the setpoint, when a setpoint is available. Each color step represents 1°C of deviation.
White background — no setpoint configured, or temperature is at the setpoint.
Threshold violations are overlaid on top of the background color:
Operational threshold breach: thin inset border — blue when below the operational low limit, red when above the operational high limit.
Critical threshold breach: thicker inset border in the same blue or red, plus bold text.
Missing or unknown values are shown in italic text with a - value.
At the bottom of each day column group, a footer row shows summary counts: total segments, segments with operational deviations, segments with critical breaches, and segments with unknown values.
You can export the report to an Excel file (.xlsx) at any point after generation. From a generated report, click Export to Excel. From a reviewed report detail page, use Export to Excel or Export reviewed report (labels may differ slightly by view; both produce a workbook from the current context). When exporting a generated report, the data reflects the readings captured at generation time. When exporting a reviewed report, the data comes from the stored immutable snapshot.
The exported workbook contains two sheets:
Sheet 1 — “HACCP Report” contains:
Report header: report name, organization, date range, interval size, and generation timestamp.
Review metadata: export type (generated or reviewed), reviewer name, review date, and review comments.
Exception totals: total exceptions, exceptions without corrective action, and unknown status/data intervals.
Exception summary table: the same information as the browser exception summary — parameter, Exception (exception type; the table header is the short label Exception), start/end times, duration, min/max temperatures, relevant limit or setpoint, and corrective action notes. Notes are included in the export regardless of whether the report has been submitted for review.
Sheet 2 — “Details” contains:
Color legend: a reference key explaining cell colors, border weights (thinner for operational limit breaches, thicker for critical), and text styles, consistent with the browser table.
Full segment matrix: the same detailed table shown in the browser — one row per parameter, one column per time segment, grouped by day. Includes setpoint columns, daily status rollups, and day footer counts.
Cell notes: where the browser shows tooltips for unknown or inferred values, the Excel file places the same explanations as cell comments.
The workbook is formatted for printing with landscape A4 page layout, header rows repeated on every printed page, and a page footer showing page numbers and “Generated by Overvis (www.overvis.com)”.
Templates save a report configuration for reuse, so you can quickly generate reports for new date ranges without reconfiguring parameters and thresholds each time. Templates are organization-level — all users in the organization can see and use them.
A template stores:
Report name
Configured temperature parameters (with all optional parameters and thresholds)
Interval size (cadence)
Temperature value display mode
A template does not store the date range, generated report data, corrective action notes, or review metadata. When you load a template, the date range defaults to the last 7 days.
Saving a template. After configuring the builder on the main HACCP report page, click Save template. The template is saved with the current report name and configuration. You are redirected to the template detail page. (When the builder is already opened in a template context, the control may read Save new template — see below.)
Loading a template. Open the Templates tab to see the list of saved templates. Click a template name to open the builder with the template’s configuration prefilled. From there, adjust the date range if needed and click Generate report.
Updating a template. When viewing a template’s builder page, modify the settings as needed and click Update template to save the changes. You can also click Save new template to create a separate template with the modified configuration.
Deleting a template. In the template list, click the trash icon next to a template. A confirmation page appears before the template is permanently deleted.
The template list shows each template’s name (as a clickable link) and creation date. Saving, updating, and deleting templates requires edit permissions on the organization.
After generating a report and documenting any corrective actions, an authorized user can submit the report for review. This creates a permanent, immutable record of the report.
The review form appears in the header area of the generated report and contains:
Reviewed by — automatically set to the submitting user’s name. Not editable.
Reviewed at — automatically set to the current date and time. Not editable.
Review comments — free-text field for the reviewer’s commentary. Editable before submission.
Click Submit review to finalize the report. The system captures a complete snapshot of all readings, exception intervals, and corrective action notes as they existed at generation time. After submission, you are redirected to the reviewed report detail page.
Submitting a review requires edit permissions on the organization. The review cannot be undone — once submitted, the snapshot and all its contents are permanent.
The Reviewed Reports tab shows all submitted report snapshots for the organization. The list displays:
Report name (clickable link to the detail page)
Date range
Reviewed by
Reviewed at
Review comments
Click a report name to open the detail page. The detail page shows the same report view as a generated report — header, legend, exception summary with corrective action notes, and an expandable detailed table — but in read-only mode. The builder form is not shown on this page. All data comes from the stored snapshot, not from live readings.
Reviewed reports are stored indefinitely. You can export a reviewed report to Excel from its detail page. The exported file uses the stored snapshot data, ensuring the export always matches exactly what was reviewed.
Organization owners can delete a reviewed report by clicking the delete action in the list. Deleting removes the report from the list and makes its detail page inaccessible. If a deleted report needs to be restored (for example, during an audit), contact Overvis support at support@overvis.com.
My temperature parameter is not listed in the dialog. What should I do?
Only tracked parameters appear in the selection lists. Make sure the parameter is configured as tracked in the device settings. Once it is tracked, Overvis will begin reading and storing its values, and it will appear in the HACCP parameter selection dialog.
Equipment exceeds thresholds during defrost cycles. How do I handle this?
Defrost cycles do not suppress threshold exception detection. If your equipment routinely exceeds thresholds during defrost, the report will show these as exceptions each time. You can document them with a standard corrective action note explaining that the deviation occurred during a planned defrost cycle. If defrost-related exceptions are expected and do not represent a food safety risk, consider adjusting the threshold values to account for normal defrost behavior, or leave the thresholds unconfigured for parameters where defrost spikes are routine.
I submitted a reviewed report with incorrect information. Can I fix it?
Reviewed reports are immutable and cannot be edited after submission. To correct the record, generate a new report for the same date range with the correct settings, add appropriate corrective action notes, and submit it for review. Organization owners can delete the incorrect reviewed report from the list.
What happens if there is only one reading in a segment?
All temperature value modes (Start of interval, average, minimum, maximum) return the same value when only one reading exists in the segment. The mode only affects the result when multiple readings fall within the same segment.
How does daylight saving time affect the report?
The report uses the organization’s configured timezone and handles DST transitions correctly. On days when clocks change, the number of segments may differ from other days — a 23-hour day will have fewer segments and a 25-hour day will have more. Segment boundaries always align to local clock time.
Can I schedule automatic report generation?
No. HACCP reports are generated on demand. You can save a template to speed up repeated configuration, but you must manually set the date range and click Generate report each time.
How often should I generate reports?
This depends on your HACCP plan requirements. Some facilities generate daily reports, others weekly. Use the date range and template features to match your review schedule.
What if my device goes offline for an extended period?
Missing readings are flagged as “unknown status/data” exceptions in the report. The exception summary will show the exact time intervals with missing data so you can investigate the cause and document corrective actions. If the equipment was intentionally turned off, configure the on/off parameter to avoid false alerts.
Can multiple users work on corrective actions for the same report simultaneously?
No. The generated report exists only in the browser of the user who generated it. Each user must generate their own instance of the report. Only one user can submit the report for review.
What is the maximum date range I can report on?
There is no fixed limit on the date range. The system enforces a total dataset size limit based on the combination of date range, interval size, and number of configured parameters. If the report would be too large, you will see an error message when attempting to generate. In that case, reduce the date range, use a longer interval, or split the report into multiple smaller reports.
Can I attach supporting documents (photos, calibration certificates) to the report?
Attachments are not supported directly in the HACCP report. If you need to include supporting documents, export the report to Excel and combine it with your attachments in your document management system. Similarly, if a reviewed report requires an electronic signature, export it to Excel and sign it through your organization’s electronic document system.
How long are reviewed reports stored?
Reviewed reports are stored indefinitely. They can be viewed, exported, and used for audits at any time. Organization owners can delete reviewed reports that are no longer needed; deleted reports can be restored by contacting Overvis support at support@overvis.com.
Control point — a point in the cold chain where temperature is monitored, typically a refrigerator, freezer, or cold storage unit.
Corrective action — an action taken in response to a detected exception, documented as a note attached to the exception interval in the report.
Exception interval — a continuous period during which an exception condition persists. Adjacent time segments with the same exception type are merged into one interval.
Interval size — the time period used to divide the report into segments for analysis. Also referred to as cadence. Options: 1 day, 1 hour, 30 minutes, 15 minutes.
Template — a saved report configuration (parameters, thresholds, interval size, display mode) that can be reloaded for quick report generation with a new date range.
Reviewed report — an immutable snapshot of a generated report that has been submitted for review, including all readings, exceptions, corrective action notes, and review metadata.
Segment — a single time slot within a day, determined by the interval size. For example, with a 1-hour interval, each day has 24 segments (23 or 25 on DST transition days).
Setpoint — the target temperature for a control point, used for deviation coloring in the report table.
Tracked parameter — a device parameter that Overvis reads periodically and stores in the database. Only tracked parameters can be used in HACCP reports.
Overvis Cloud Documentation
Visualizations
Visualizations in Overvis Cloud are custom, interactive pages (HTML/SVG/JavaScript) that display the current state of your equipment and provide remote control capabilities. They are the same feature labeled Visualizations in the app navigation. While Overvis handles device connectivity, data collection, and alarm processing automatically, visualizations give you the flexibility to present this information exactly how you need it.
Visualizations are HTML/SVG/JavaScript code embedded into Overvis pages. You create the visual design using any vector graphics editor, export it as SVG, and then add special attributes to bind live data from your devices to the graphics.
After clicking “Create visualization” the result is:
You can even add it to the Dashboard in Overvis:
This visualization is static. To display actual device data, you need to use data bindings - special HTML/SVG attributes that connect visual elements to device parameters.
This tutorial walks through creating a complete visualization for refrigeration equipment monitoring. You’ll learn how to display live temperatures, add interactive setpoint controls, show alarm indicators, and implement toggle switches.
Create the visualization design in your vector graphics editor. For this example, we’ll create a storage room layout with freezer units showing:
Room floor plan
Temperature displays for each fridge
Setpoint controls
Alarm indicators
An energy meter
A defrost mode switch
A door status indicator
When designing your visualization, follow these guidelines:
Use placeholder values. Insert representative placeholder values for all dynamic data. For temperatures expected to be negative with one decimal place, use “-12.3”. This helps with layout and positioning during design.
Separate dynamic from static elements. Keep dynamic values as separate objects from static labels. For example, “-12.3” and “°C” should be separate text objects, so only the number gets updated with live data.
Keep text as text. Don’t convert dynamic text elements to curves or paths. Static text can be converted to reduce file size, but dynamic elements must remain editable text.
Use compatible fonts. Stick to web-safe fonts (Arial, Times New Roman, Courier) or use Droid Sans, which Overvis provides to all visualizations. Custom fonts require additional CSS configuration.
Position everything upfront. Draw all elements in their final positions, including elements that will be hidden initially (like alarm indicators in both triggered and normal states, or switches in both on/off positions).
Name your layers descriptively. Use clear layer names in your graphics editor. These names often become element IDs in the SVG, making it much easier to locate specific elements when adding data bindings.
To display a device parameter value as text, add the param-value attribute to a text element. For example, to show the probe temperature from a fridge controller:
Find the text element in your SVG code (look for layer names you set earlier):
The on-click="edit-param:..." attribute opens a dialog when clicked, allowing the user to enter a new value. After saving, Overvis writes the value to the device and updates the visualization.
Adding cursor:pointer to the style makes the cursor change to indicate the element is clickable.
:block - Value when condition is true (show element)
:none - Value when condition is false (hide element)
:r - Read directly from device in real-time
Set the default style="display:none;" so the element is hidden initially. When the parameter equals 1, the display style changes to block, making the indicator visible.
Each state has on-param-value that shows it when the parameter matches (:=1 for ON, :=0 for OFF). The parent group has on-click="toggle-param:PARAM_REF:DEFAULT_VALUE:VALUE_ON:OPTIONS" that flips the parameter between 0 and 1 when clicked. The :g option at the end refreshes all visualization data after the change.
To allow users to edit labels or names that aren’t stored in device registers, use the visualization’s own database storage. First, enable this feature by adding an attribute to the root <svg> tag:
<svguse-vis-data="yes" ...>
Then mark text elements that should be editable and stored:
The text-replacement attribute specifies a storage key. The initial text content becomes the default value. When users click the element (due to on-click="edit-visdata:..."), they can edit and save a new value that persists in the database.
Complete the visualization by adding the remaining data bindings. For the energy meter, display the value from the database rather than reading it directly from the device:
Notice there’s no :r flag. This reads the last value from the database (updated every 5 minutes) rather than polling the device directly. This reduces network load for values that don’t need real-time updates.
The completed visualization displays live equipment data, allows user interaction, and updates automatically:
By default, param-value reads the last stored value from the database. Add the :r option to read directly from the device in real-time. Choose based on your needs:
Use database reads (no :r option) when:
The value changes infrequently
Exact real-time data isn’t critical
You want to reduce network traffic and improve refresh speed
When displaying multiple alarms simultaneously, create separate indicator elements for each alarm type and position them to avoid overlap. Use individual on-param-value bindings for each. For complex alarm scenarios, consider using JavaScript to dynamically position indicators.
While data bindings handle most common scenarios, you can use JavaScript for advanced functionality. Visualizations run in the context of the Overvis web page, giving you access to the full browser API and Overvis-specific functions.
To make authenticated API calls from your visualization, you need to include the session token. The token is stored in browser storage and accessible via JavaScript.
Use the preInitViz() function to execute code before the visualization initializes. This is useful for fetching data from the API or setting up custom logic:
<script>
window.preInitViz=function(callback) {
// Get the authentication token from session storage
Check that the refresh interval is configured correctly, verify parameter addresses match your device configuration, and confirm devices are online and responding. Use your browser’s developer console (F12) to check for JavaScript errors.
Data shows error codes (NOLR, NOPR, NORV, etc.)
NOLR (No Last Reading) - Parameter has never been read or not tracked. Mark it as “tracked” in device settings or add :r option for real-time reads.
NOPR (No Parameter for realtime) - The realtime slot could not resolve a parameter. Check that the parameter reference in the visualization is valid.
NORV (No realtime value) - The realtime read did not return a value. Check device connectivity and try reading the parameter on the device parameters page to see the actual error.
NON (No Network) - Referenced network doesn’t exist or you don’t have access.
NOP (No Parameter) - Referenced parameter doesn’t exist in the device.
Interactive elements don’t work
Verify on-click syntax matches the documentation. Ensure cursor:pointer is in the style attribute. Check that another element isn’t covering the clickable element (SVG layer order matters).
Styling looks wrong
Confirm your SVG export didn’t convert text to curves. Use inline styles within SVG elements to avoid conflicts with page CSS. Validate SVG structure using an SVG validator tool.
Refresh is slower than expected
If you’re reading many parameters with the :r option (real-time reads), each one requires a device query. The next refresh cycle doesn’t start until the previous one finishes. Use database reads (without :r) for non-critical values to optimize refresh cycle time, or increase the update-period-sec setting.
Can I use external JavaScript libraries like Chart.js or D3.js?
Yes. Include them via CDN in a <script> tag at the beginning of your visualization source code. However, be aware that large libraries may slow down page loading.
Can I create multi-page visualizations?
Visualizations are single-page by design, but you can simulate multiple pages using JavaScript to show/hide different sections, or create multiple separate visualizations and link between them using on-click="goto:vis:...".
How do I debug visualization JavaScript?
Use your browser’s Developer Tools (F12). Console logs, breakpoints, and network inspection work normally. Check the console for errors related to API calls or data binding issues.
Can visualizations access data from multiple organizations?
No. Each visualization belongs to one organization and can only access data from networks and devices within that organization. The API enforces this through authentication tokens.
What’s the difference between parameter system ID and parameter address?
Parameter address is the Modbus register address on the device (e.g., 101). System ID is Overvis’s internal database identifier for that parameter. Use addresses in references like 12-34-56-78-90-ab>1>101, or use system IDs with the # prefix: #1234567.
Can I style visualizations with custom CSS frameworks?
Yes, but include the framework’s CSS file in a <style> or <link> tag. Be aware that the Overvis page has its own styles that might conflict. Use specific selectors or inline styles to avoid issues.
How do I handle time zones?
All dates from the Overvis API are in UTC. Use JavaScript’s Date object and toLocaleString() to convert to the user’s local time zone, or specify a particular time zone if needed.
If you need assistance creating Overvis visualizations, contact us at support@overvis.com. We’re happy to help with custom visualizations, answer questions about advanced features, or clarify documentation.
Overvis Cloud Documentation
Organizations & Users
Overvis Cloud uses organizations to separate equipment, data, and billing between different customers or projects. Each user account can belong to one or more organizations, and each membership has a specific role that determines what the user can do.
An organization is the top-level container in Overvis. All networks, devices, parameters, alerts, visualizations, reports, and billing belong to a specific organization. Data is fully isolated between organizations — users only see the data of the organization they are currently working in.
Organization owners and managers can edit the following settings. In the sidebar, this page is opened via Details under your organization name; the page title is Organization settings.
Name — the display name of the organization (up to 200 characters)
Country and contact phone
Notification language — the language used for automated emails and SMS notifications. Available languages: English, Ukrainian, Polish, Russian.
Default notification email and phone — used as defaults when creating new alerts
Billing details — full name, country, city, address, ZIP, phone, email, and VAT number (used for invoices)
Owners additionally see member management options on the organization pages.
An organization is created automatically when you register a new Overvis account. The organization name is set during registration. If you leave it blank, the default name is derived from your email:
If the email domain has 10 or more characters (e.g. user@longcompany.com), the domain is used as the name (longcompany.com).
If the domain is shorter (e.g. user@acme.co), the full email address is used as the name (user@acme.co).
You always belong to at least one organization. If an owner removes you from an organization and you have no other memberships, a new empty organization is automatically created for you.
If you belong to several organizations (for example, as an owner of your own and as a viewer in a client’s organization), you work in one organization at a time. You can switch between them using the organization selector in the top navigation bar.
When you log in, Overvis automatically selects an organization where you have an owner or manager role. If you have no owner or manager role in any organization, the first available organization is selected.
A user account represents one person. Each account has a unique email address and an auto-generated username, and belongs to one or more organizations.
To create an account, go to the sign-up page and provide:
Email address — used for login and notifications (must be confirmed after registration)
Password — minimum 5 characters
Organization name (optional) — name for the organization that will be created for you
A username is generated automatically from your email address at registration. You can log in using either your email or username.
If you received an invitation link, you can register through it — your account will be added to the inviting organization instead of creating a new one.
After registration or changing your email, you receive a confirmation email. You have 24 hours to confirm the new email address. During this grace period, the platform treats the email as confirmed and you can use all features normally. After 24 hours without confirmation, some actions (like managing devices or creating alerts) are restricted until you confirm your email.
In your account settings (User settings > Personal info in the sidebar), you can change:
First name, middle name, last name, and phone number
Additional account actions available from the sidebar:
Change email — requires re-confirmation within 24 hours
Change password — requires your current password
API Keys — manage programmatic access tokens (see API Keys)
Delete account — permanently remove your account
The interface language is changed using the language switcher in the navigation bar (English, Ukrainian, Polish, Russian). This setting is saved to your account.
You can delete your account from User settings > Delete account. This permanently removes your user account, API keys, and associated data.
Account deletion may be blocked in the following cases:
You are an owner of an organization that has other members. You must first remove all other members or transfer ownership to another user before deleting your account.
Your organization has a positive account balance. Contact support to resolve the balance before deleting.
If you are the only member of an organization, that organization and all its networks and devices are deactivated upon account deletion.
Each organization membership has exactly one role. The role determines what the user can do within that organization. There are eight roles, split into two groups: full-interface roles (access the complete Overvis management interface) and monitor roles (access only the simplified monitoring interface at /view/).
These roles give access to the full Overvis management interface with varying levels of permissions.
Owner is the highest role. An owner has full control over the organization, including:
Viewing all data, sending commands to devices
Creating and editing networks, devices, parameters, alerts, templates, visualizations, and reports
Inviting, editing, and removing organization members
Accessing billing, payment history, and account balance
Editing organization settings
Only owners can manage organization members. There is no limit on the number of owners per organization, but typically there is one.
Manager has the same capabilities as the owner, except they cannot manage organization members. Managers can:
View all data, send commands to devices
Create and edit networks, devices, parameters, alerts, templates, visualizations, and reports
Access billing, payment history, and account balance
Edit organization settings
Technical Manager is similar to Manager but without billing or organization settings access. Technical managers can:
View all data, send commands to devices
Create and edit networks, devices, parameters, alerts, templates, visualizations, and reports
They cannot access billing or payment information, cannot manage members, and cannot edit organization settings.
Operator can view data and send write commands to devices, but cannot change the organization structure. Operators can:
View all networks, devices, parameters, and reports
Send write commands to devices (e.g. change a setpoint or toggle a relay)
They cannot create, edit, or delete networks, devices, alerts, or other objects.
Viewer has read-only access. Viewers can:
View all networks, devices, parameters, dashboards, and reports
They cannot write to devices or modify anything. This role is useful for stakeholders, executives, or anyone who needs to see the data without changing it.
Monitor roles provide access to the simplified monitoring interface only (the /view/ section). Users with these roles cannot access the full management interface. Monitor roles are designed for wall-mounted displays, field technicians with limited access needs, or external viewers.
Monitor Operator can view monitoring dashboards and send write commands to devices.
Monitor Viewer has read-only access to monitoring dashboards.
Monitor No Parameters can view monitoring dashboards but cannot see the parameters list. This role is only assignable by platform administrators and is not available in the standard invitation or member edit forms.
Monitor roles can optionally be bound to a specific visualization or resource report. When bound, the user is automatically redirected to that specific view when they log in or navigate outside allowed pages. This is useful for setting up a dedicated display screen that always shows one dashboard or report.
A monitor user can be bound to either a visualization or a resource report, but not both.
Select a role: Manager, Technical Manager, Operator, Viewer, Monitor Operator, or Monitor Viewer
For monitor roles, optionally select a visualization or resource report to bind the user to
Send the invitation
The invited person receives an email with a link. The link is valid for 2 days. If they already have an Overvis account, they will be asked to log in and then the invitation is applied. If they don’t have an account, they are taken to the registration page first.
You cannot invite someone directly as an Owner — ownership can only be assigned by editing an existing member’s role.
Go to Organization > Members to see all current members and pending invitations. Each entry shows the member’s name (or email if no name is set), their role, and management actions.
The removed user loses access to the organization immediately and receives an email notification. If they have no other organization memberships, a new empty organization is created for their account automatically.
You cannot remove yourself from the organization through the member management interface.
API keys provide programmatic access to the Overvis REST API. They belong to your user account (not to a specific organization) and inherit all your organization memberships and roles.
To use the API, first authenticate by sending a POST request:
POST /v1/authenticate/
{
"apiKey": "513cf747-eb5c-4d5f-931f-d22c9872c73c",
"password": "your_password_here"
}
The response contains a session token and its expiration time. Use this token to authenticate subsequent API requests. The token expires after a period of inactivity — each API request extends the token’s lifetime automatically.
If more than 24 hours have passed since registration or email change without confirming, your access to most features is restricted. Go to User settings > Change email, re-enter your email address, and a new confirmation email will be sent. You get another 24-hour window to confirm.
Only owners and managers can access billing information and edit organization settings. If you need access, ask the organization owner to change your role. You can check your current role in the top navigation bar next to the organization name.
Member management (inviting, editing roles, and removing members) is restricted to the owner role. Managers and other roles cannot manage members. If you need to invite someone, ask the organization owner.
Invitation links are valid for 2 days. If the link has expired, ask the organization owner to send a new invitation. The old invitation can be deleted from the members page.
I was removed from an organization and lost my data
When you are removed from an organization, you lose access to that organization’s data. The data itself is not deleted — other organization members still have access. If you were removed by mistake, ask the organization owner to re-invite you. If you had no other organization memberships, a new empty organization was created for your account automatically.
You are an owner of an organization that has other members. First transfer ownership to another member (edit their role to Owner), then either leave the organization or try deleting again.
Your organization has a positive account balance. Contact support@overvis.com to resolve the balance.
If a monitor user is bound to a specific visualization or resource report, they are automatically redirected to that view. To change or remove the binding, the organization owner should edit the member’s settings and update the bound visualization or report.
Yes. You can be a member of as many organizations as needed, with a different role in each. Use the organization switcher in the top navigation bar to switch between them. Each organization’s data, billing, and settings are completely separate.
Yes. There is no limit on the number of owners. However, most organizations have one owner. To make another member an owner, the current owner edits their role from the members page.
You cannot remove yourself from an organization through the member management interface. If you want to leave, first assign the Owner role to another member, then ask them to remove you.
What is the difference between Operator and Monitor Operator?
Both can view data and send write commands to devices. The difference is in the interface they access:
Operator uses the full management interface with access to all pages (networks, devices, parameters, reports, etc.), but cannot create or edit objects.
Monitor Operator only has access to the simplified monitoring interface (/view/ section), which shows dashboards. They cannot access the full management interface.
Yes. Use the language switcher in the navigation bar to change the interface language. Available languages: English, Ukrainian, Polish, Russian. This setting is saved to your account and applies on your next login.
The notification language is an organization-level setting that controls the language of automated emails and SMS (alert notifications, system messages). It is separate from your personal interface language. Owners and managers can change it in Organization > Settings.
API keys belong to your user account, not to a specific organization. When you authenticate with an API key, you get a session that has access to all organizations where your account is a member, with the same roles and permissions as your user account.
Overvis Cloud uses a prepaid balance model. Your organization has an account balance in EUR, and the system deducts the cost of services from it automatically each day. When the balance runs low, you receive email warnings. When it is exhausted, all your networks are disabled until the balance is replenished.
There are no subscription tiers or monthly plans — you pay only for the services you use. The billing pages are available to organization managers (owners and managers); viewers do not have access.
Network processing — a fixed daily rate per network (gateway connection). The default rate is €0.50/day (€15/month) per network. Promotional or referral discount codes can lower the per-network rate (see Discount Codes). Volume discounts are available for deployments with 10 or more gateways — contact sales for details.
Data storage — each network includes a base amount of data storage at no extra cost. Additional storage is billed at €0.20/month per 1,000,000 data points. For reference, logging 100 parameters every 60 seconds generates approximately 150,000 data points per month, so most users stay within the included storage.
SMS notifications — charged per message at the time of sending, based on the destination phone number. Typical rates: €0.03–0.05/SMS within the EU, varying by destination country. SMS costs are deducted from the balance immediately when the notification is sent. Email notifications are free and unlimited.
The daily network processing charge is deducted once per day for the previous day’s service. If a network was enabled for any part of the previous calendar day, a charge is applied.
All prices are net (VAT excluded). See the Overvis pricing page for full pricing details.
Account balance (EUR) — the main spendable balance, funded by card payments, bank transfers, or cash.
Bonus balance (EUR) — promotional credit (e.g. the registration bonus). Bonus balance is used first when charges are applied. Bonus balance is non-refundable.
Both balances are visible in the sidebar of every page. Click the Account balance area in the sidebar to open a dropdown menu with quick links to:
Top Up Balance — add funds to your account
Account Balance Report — view charges and estimated expenses
Payment History — see past payments and download receipts
Enter the desired amount in EUR (minimum €1) and click Topup. You will be redirected to a secure payment page powered by Stripe. After a successful payment:
The amount is credited to your account balance immediately.
A PDF receipt is generated and emailed to the billing email address configured in organization settings.
The maximum top-up amount depends on your current account balance — the system caps the total account balance at a configured limit (e.g. €1,000). If your current balance is already near this limit, the available top-up amount will be reduced accordingly, and the card top-up form may be temporarily unavailable.
For payments by bank transfer or cash, contact your assigned personal manager (shown on the page if assigned) or Overvis support. The support contact details are displayed on the top-up page.
The Account Balance Report page (accessible from the sidebar balance menu) is the central place for understanding your expenses. It has two main sections: estimated expenses and expenses history.
This section shows a projection of your upcoming charges based on currently enabled networks. It is displayed as a table with three tabs:
First tab — projected cost from today through the end of the current calendar month. The tab label shows the month name and how many days are left in the month (column headers include till EOM for the end-of-month projection).
30 days — projected cost for the next 30 days
365 days — projected cost for the next 365 days
For each network, the table shows:
Column
Description
Network name
Name of the network (disabled networks are shown in grey)
Below the estimates, a monthly expenses history table shows all actual charges and credits for a selected month. Use the Month dropdown to switch between months (data is available from the month your organization’s first charge occurred).
Rows are grouped by category. Click on a category row to expand it and see individual records:
Top-up — payments received (card, bank transfer, cash), with payment method, receipt document number, and date. Also includes bonus balance credits.
System — system-generated credits (e.g. the registration bonus).
Network processing — daily charges per network. Expandable to individual daily records showing the bill date and discount code (if any).
Network storage — data storage charges per network.
SMS notifications — charges grouped by phone number, expandable to individual messages with timestamps and quantities.
Cashback — referral cashback credits, if applicable (see Discount Codes).
Other — miscellaneous adjustments.
Each row shows four columns:
Column
Description
Description
What the charge or credit is for
Quantity
Number of individual records in this group
Amount
EUR amount (green for credits, red for charges)
Bonus
Bonus balance change (if any)
At the bottom of the table, the report shows:
Total — net change for the selected month
Balance on period start — account and bonus balance at the beginning of the month
Balance on period end — account and bonus balance at the end of the month
The system monitors your balance and sends email notifications when it drops below certain thresholds. Notifications are sent when your remaining balance can cover approximately 30 days, 10 days, and 5 days of service at the current daily rate.
When the balance is fully exhausted (reaches zero or below), a final balance exhausted email is sent with a direct link to the top-up page.
You can configure who receives billing notifications by setting the billing email in organization settings.
If your organization’s balance (account + bonus) drops to zero or below during the daily billing run:
All networks in the organization are disabled by the billing system.
An email notification is sent to the organization’s billing email.
Disabled networks stop polling devices — no new readings are collected and no alerts are triggered.
SMS notifications are also blocked when the balance is insufficient.
Historical data remains safely stored according to your organization’s data retention settings, even after networks are disabled.
To restore service: top up your account balance. Once the balance is positive again, re-enable your networks manually from the network settings page. The system does not re-enable them automatically.
Overvis supports promotional and referral discount codes that reduce the daily network processing rate. A discount code is applied to a specific network and sets a custom (lower) cost per day for that network.
Discount codes have the following properties:
A fixed per-day network cost (overriding the default rate)
An optional expiration period (number of days after activation)
An optional maximum number of applications (quota)
An optional registration deadline (the code cannot be applied after this date)
When a discount code expires, the network’s daily rate is automatically reset to the default rate.
Some discount codes include a referral cashback — a daily credit paid to the referring organization’s account balance for each day the referred network is active. The cashback is calculated from the non-bonus portion of the daily charge only. Cashback entries appear in the Account Balance Report under the Cashback category.
Organization settings include a Billing Information section where managers can provide details used on receipts and invoices:
Organization name / contact person (required)
VAT code — VAT identification number
Country and City
Company address and Postal code
Phone
Email (required) — receipts, invoices, and billing notifications are sent to this address
To update these fields, go to Organization settings (click the organization name in the sidebar, then Organization settings) and scroll to the Billing Information section.
Your organization’s balance (account + bonus) dropped to zero or below during the daily billing run. The system automatically disables all networks when the balance is exhausted.
Solution: Check the Account Balance Report to see the charges that led to the zero balance. Top up your balance and manually re-enable your networks from each network’s settings page.
Your current account balance is close to the maximum allowed. The system limits the total account balance, so the available top-up amount decreases as your balance grows. If your balance is already near the limit, the card payment form may show a message that the top-up feature is temporarily unavailable.
Your bank is declining the transaction. Contact your bank to verify the card can be used for international EUR payments.
Solution: Try a smaller amount. If the card form is unavailable, use bank transfer or contact support.
I don’t see billing pages or the balance in the sidebar
Only organization managers (owners and managers) have access to billing pages. If you are a viewer, the balance display and billing menu are not shown.
Solution: Ask an organization manager to upgrade your role, or contact support.
Balance is being charged but I disabled my network
The daily charge covers the previous calendar day. If your network was enabled for any part of yesterday, a charge will appear today. After disabling a network, you may see one final charge the following day.
Solution: This is expected behavior. No further charges will appear for this network after the final day’s charge.
SMS notifications require sufficient balance. When the balance is too low, SMS sending is blocked.
Solution: Check your balance and top up if needed. Verify that the SMS notification is still configured in your alert settings. You can switch to email notifications, which are free and unlimited.
SMS notifications can add unexpected costs, especially if many alerts are triggered.
Multiple networks are enabled — each network incurs a separate daily charge.
A discount code expired, resetting the network to the default daily rate.
Solution: Open the Account Balance Report, select the month in question, and expand the SMS notifications and Network processing categories to see individual charges.
The billing system runs once per day and charges each enabled network for the previous calendar day’s service. The exact time of the billing run may vary, but charges always appear for the previous day.
Go to the Account Balance Report from the sidebar balance menu. The Expenses history section shows all charges grouped by category. Click on any category row to expand it and see individual records with dates and amounts.
No. When the balance runs out, networks are disabled and stop collecting new data, but all previously recorded data remains stored according to your organization’s data retention settings. Once you top up and re-enable your networks, data collection resumes.
You can disable individual networks from their settings page. Disabled networks do not incur daily processing charges. Your data, device configurations, and alert settings remain intact. Re-enable the network at any time to resume service.
Discount codes are applied per network. Open the network details page and click Apply discount code. Enter the code, review the price change on the confirmation page, and click Confirm. Once applied, the code and its effect on pricing are shown on the network details page. You can remove a manually applied code at any time from the same page.
Why is the top-up form showing a lower maximum than expected?
The maximum top-up amount is calculated as the configured limit minus your current account balance. For example, if the limit is €1,000 and your current balance is €800, you can top up at most €200.
SMS costs depend on the destination phone number’s country. The cost per message is deducted from your balance at the time the SMS is sent. You can see all SMS charges itemized in the Account Balance Report under the SMS notifications category.
Overvis provides REST-like HTTP API with request payload and response encoded in JSON format.
Base API URL is https://ocp.overvis.com/api/v1/. Further documentation will list the requests as
entrypoints with paths that should be concatenated to the base API URL. E.g. API version retrieval
endpoint is /version/, that means, the full URL of the version request should be
https://ocp.overvis.com/api/v1/version/.
All API requests require Content-Type: application/json HTTP header set.
All POST requests require HTTP payload to be a UTF-8 encoded plain-text with semantically-correct
JSON content. Empty payload is not allowed for POST requests, send null if endpoint requires no
data.
All requests return HTTP status code 200 if executed correctly.
5xx status codes represent server-side unexpected errors and are automatically reported to the
developers.
4xx status codes represent errors that are client’s concern and should be dealt with on the
client side. These errors have JSON payload which look like this:
{
"errorCode": "ErrCode",
"errorMessage": "Human-readable error message in english."
Manually updates network fields. This is a low-level endpoint for updating specific fields like
name, description, or connection details without necessarily re-applying a full solution.
Endpoint
POST /net/:netId/change/
Parameters
Path Parameters
netId (number, required): The ID of the network.
Body
All fields are optional:
name (string): Network name.
description (string): Network description.
devicePasswords (string[]): Controller passwords.
controllerModbusUnitId (number): Modbus Unit ID (0-255).
sku (string): Device SKU.
solution (string): Solution type.
connectionType (string): direct, backward, or vpn.
mac (string): MAC address.
ip (string): IP address.
port (number): Port.
connectCode (string): Connect code.
maxInflightRequestsNum (number): Max parallel requests.
Authorization
Permission: manager (edit access to org objects)
Requires a valid session token in the Authorization header.
Response
status: ok.
netSlug: Current slug of the network.
Example Request
{
"name": "Updated Name",
"description": "Manual update"
}
POST /net/:netId/connection-status/ - Get Network Connection Status
Returns specified number of data points for a requested parameters on a given time range.
Endpoint
POST /readings/dispersed/
Parameters
Body
paramIds (integer[], required): List of parameter IDs.
from (string, required): Start date of the check range (ISO 8601).
till (string, required): End date of the check range (ISO 8601).
points (integer, required): Number of points to take in this date range (for each parameter).
Maximum: 1000.
Response
Result is an array of “segment” records. Each record is an array where the first item is a ISO 8601
datetime, and the second item is an array of parameter values during that segment in the order of
paramIds provided.
Returns stored data points for a requested time range for a given parameter.
Endpoint
GET /readings/get/
Parameters
Query Parameters
paramId (integer, required): ID of the parameter.
from (string, optional): Start date of the range (ISO 8601). If omitted, response will contain
last pointsLimit data points up to till date.
till (string, optional): End date of the range (ISO 8601). If omitted, end date will be the
current time.
pointsLimit (integer, optional): Limit on the number of the returned data points. Maximum and
default: 1000.
Response
Result is an array of data points. Each record is an array where the first item is a ISO 8601
datetime, and the second item is the parameter value (number or null). Data points are sorted by
dates in a descending order.
Example Request
GET /readings/get/?paramId=284&from=2020-01-01T00:00:00Z&till=2020-08-17T00:00:00Z&pointsLimit=100
Example Response
[
["2019-07-26T16:28:00Z", 7.0],
["2019-07-26T16:33:42Z", 7.0],
["2019-07-26T16:39:24Z", 7.0]
]
POST /readings/min-max-range/ - Range of Readings Values for a Given Period
Saves the data entered by the user in the visualization.
Endpoint
POST /vis/:visId/data/save/
Parameters
Path Parameters
visId (number, required): ID of the visualization.
Body
code (string, required): Key for the value.
value (string, required): Value to be saved.
Response
Returns an empty object on success.
Example Request
POST /vis/7/data/save/
{
"code": "roomName",
"value": "Room 1"
}
Example Response
{}
Overvis Cloud Documentation
Device Templates Reference
This reference covers the technical specification of the device template Excel file format used for import and export in Overvis Cloud. For a general overview of how templates work, see the Device Templates guide.
Device templates use the Microsoft Excel .xlsx format. Only .xlsx is accepted — older .xls files, CSV, and other formats are not supported.
A template workbook contains two required sheets and two optional sheets. The sheet names are exact and case-sensitive — any unrecognized sheet name causes an import error.
The Info sheet stores device-level metadata and communication defaults. Values are read from fixed cell positions (not by column headers).
Row
Column A (1) — label
Column B (2) — value
Required
1
Manufacturer:
Manufacturer name (up to 200 characters)
No
2
Model:
Template name / device model (1–200 characters)
Yes
3
Device Version:
Version string (up to 50 characters)
No
4
Category:
Category text (up to 200 characters)
No
5
(empty)
6
Read Group Size:
Integer 1–255
Yes
7
Write Function:
normal, always-6, or always-16
Yes
Description is stored in column D (4), starting from row 2. If the description is longer than 32,000 characters, it is split across multiple cells in that column (row 2, row 3, etc.). On import, all cells in column D below row 1 are concatenated.
Template name (row 2) is the primary identifier. Together with manufacturer and version, it forms a unique identity within a scope (global or per-organization). Importing a template with the same name+manufacturer+version as an existing one in your organization replaces the existing template.
Read group size controls how many consecutive Modbus registers Overvis combines into a single read request. A value of 1 reads each parameter individually. Higher values (e.g. 16) batch adjacent registers into fewer requests, which speeds up polling but requires the device to support multi-register reads across that range.
Write function determines which Modbus function code is used when writing parameter values:
Value
Meaning
normal
Overvis chooses automatically — function 06 (Write Single Register) for single-register values, function 16 (Write Multiple Registers) for multi-register values.
The Params sheet defines all device parameters. Row 1 is the header row; data starts from row 2. Columns are matched by header name (not by position), so column order does not matter.
Grouping label (up to 200 characters), e.g. Inputs, Configuration, Status.
Mnemonic
label
Short identifier (up to 20 characters), e.g. T1, P.out. The column can also be named Label.
Description
description
Longer explanation of what this parameter represents.
Units
unitName
Measurement units (up to 20 characters), e.g. °C, kW, bar, %.
Multiplier
multiplier
Scaling factor applied to the raw register value. displayed = raw × multiplier + shift. A value of 1 is treated as “no multiplier.” Not allowed for bit, string, IP address, and MAC address types.
Shift
shift
Offset added after multiplying. A value of 0 is treated as “no shift.” Same type restrictions as multiplier.
Decimal Precision
decimalPrecision
Number of decimal places to display (integer 0–20).
Min
minValue
Minimum expected value (for display and validation).
Max
maxValue
Maximum expected value (for display and validation).
Bit Position
bitPosition
For bit and bits types: which bit within the register to start from (0–15). Required for bit and bits, not allowed for other types.
Bits Num
bitsAmount
For bits type only: how many consecutive bits to extract (1–16). Required for bits, not allowed for other types including bit.
Parameter text fields can be translated into additional languages. Add translation columns by appending a space and a language code to the base column name:
Base column
Translation column examples
Name
Name uk, Name pl, Name ru
Category
Category uk, Category pl, Category ru
Description
Description uk, Description pl, Description ru
Units
Units uk, Units pl, Units ru
Supported language codes: en, uk (Ukrainian), pl (Polish), ru (Russian). English is the base language — the main column values are always English, and en translation columns are not needed.
A translation column requires the corresponding English column to have a non-empty value in the same row. You cannot translate an empty field.
The following types do not support multiplier or shift values: bit, byte-str, word-str, byte-ipaddr, word-ipaddr, byte-macaddr, word-macaddr. Setting a multiplier or shift on these types causes a validation error.
When the Type is enum, the Represent As cell defines mappings from numeric values to display text. The cell must contain multiple lines, each with fields separated by semicolons (;):
<value>;<display text>
<value>;<display text>;<description>
The description is optional. Example cell content (each line in the same cell):
0;Stopped
1;Running
2;Error;Critical fault detected
3;Maintenance;Scheduled service mode
Rules:
English mappings are required — the base Represent As column must be filled.
Each numeric value must be unique within the English mappings.
To provide enumeration mappings in other languages, add columns named Represent As XX where XX is the language code in uppercase:
Represent As UK — Ukrainian
Represent As PL — Polish
Represent As RU — Russian
Each translation column uses the same semicolon-and-newline format as the base column. The numeric values must match the English values exactly — the same set of values, in any order. Example Represent As UK cell:
When the Type is bit, the Represent As cell can contain a system representation code — a short text identifier referencing a built-in bit representation (e.g. showing On/Off or Open/Closed instead of 1/0).
The value must reference an existing system bit representation code. If the code is not recognized, import fails with an error listing the available codes.
This is distinct from enum mappings: the cell contains a plain string (no semicolons or newlines), and it is only valid for bit type parameters.
The optional Visualization sheet contains the HTML/JavaScript source code for an embeddable device visualization. Row 1 is a header; the actual content starts from row 2 in column A (1).
Long content is split across multiple cells (row 2, 3, etc.) at 32,000-character boundaries and concatenated on import.
When the template is applied to a device, the visualization source can contain {{device_id}} and {{network_id}} placeholders, which Overvis replaces with the actual IDs.
Overvis validates the template during import at multiple levels. If any validation fails, the template is not imported, and errors are reported with their sheet name, row, and cell reference.
Each parameter row is validated independently. A row with errors is skipped, but other rows are still validated (all errors are collected and reported).
Templates are always imported into the current organization (never directly to the global library). To make a template global, use the separate “Make global” action in the web interface.
If a template with the same name, version, and manufacturer already exists in the organization, the existing template and all its parameters, translations, and enumeration definitions are replaced with the imported data.
Import is atomic: if any validation error occurs, no changes are made.
Exporting a template produces an .xlsx file with the same structure described above. The exported file can be edited in any spreadsheet application and re-imported.
The export includes:
Info sheet with all device metadata.
Params sheet with all parameters, including any translation columns that have data.
Visualization sheet (only if the template has a device visualization).
Alerts sheet (only if the template has alert YAML).
Exported files use frozen header rows and auto-filters on the Params sheet for easier navigation.
Overvis visualization source code is an HTML snippet. This snippet code is not processed on the
server-side and is embedded inside the Overvis page HTML as-is. It can contain JavaScript inside
<script> tags, CSS inside <style> tags, or SVG images inside <svg> tags. It should not
contain <!...>, <html>, <head>, <body> or other header tags because they are already
present on the Overvis page.
There are several extension tags and attributes that are added by the JavaScript to the Overvis
page for simplifying visualization data binding. The following reference will list all such
additions. Visualization code is not required to use them and can directly call Overvis API
instead.
In the reference below, the following syntax: update-period-sec="{{number}}" means that the
double curly braces should be replaced by the referenced value type. In this example, the correct
usage will be something like this: update-period-sec="60".
After the visualization is loaded, it gathers all used data bindings from the source code and
starts the automatic data refresh process. Visualization data is being refreshed every 10 seconds
by default.
The next refresh cycle doesn’t start before the previous one is finished. The length of the refresh
cycle depends on how many parameters are being read from the devices and the connection quality.
So, if there are many parameter readings to be requested at once from the slow channel, the refresh
cycle may take more time than planned. To optimize the refresh cycle time, prefer loading parameter
values from the Overvis database instead of reading them from the devices directly.
Those functions are added to the global window object and accessible everywhere in the code:
Function
Description
preInitViz(cb)
This function is called after the visualization source code is embedded in the page, but before the references and aliases are being resolved. This function can add additional binds or modify visualization source code. cb is a callback function that should be invoked at the end of preInitVis.
onVizUpdate(data)
This function is invoked after any bound data is received (at least after each refresh cycle). data is an object with references as keys.
writeParamValue(ref, val, cb, refreshAll)
Send parameter value to the device. ref - parameter reference; val - value as a string; cb - a function that should be called after the writing process will be finished; refreshAll - boolean, if true - refresh all data on the visualization, if false - refresh only the changed parameter.
All referenced objects should exist in Overvis. For example, you can’t reference the network by
IP/MAC address if the network with this IP or MAC is not created under your account.
Networks can be referenced in one of the following ways:
By the slug string. Slug is a unique code assigned to each object. It can be taken from the URL of the parameter settings page in Overvis.
~{{alias name string}}
~someParam
Using alias. Alias with this name should be provided by the alias tag in visualization code.
{{device reference}}>{{address}}
12-34-56-78-90-ab>111>123
By the parameter address inside the device. Note, this parameter should exist in the device parameters list in Overvis. {{address}} can also contain additional specifications, see below.
Parameter address has the following extended syntax:
Any container tag in HTML/SVG code has an additional possible attribute:
param-value="{{paramRef}}:{{options}}"
This attribute specifies that the contents of this tag should be replaced by the value of the
parameter referenced by {{paramRef}}. By default, this value will be taken from the Overvis
database of last known parameter values.
{{options}} is a comma-separated list of flags. Currently supported flags:
r - read data directly from the device,
p{{number}} - display data with specified precision.
Also, the following attribute can be used in conjunction with param-value:
param-value-mod="{{evalExpr}}"
It applies the quick mathematical expression evalExpr where the current value will be passed as
x.
Placeholder text loading... will be replaced with the value of parameter 123 of the device 111 in the network 12-34-56-78-90-ab. Value will be taken from the database, so this parameter should be marked as tracked in the system.
<div param-value="12-34-56-78-90-ab>111>123:r" />
The value of the parameter will be read from the device on each refresh. The parameter can be untracked.
By default, the value of the parameter is taken from the Overvis database, not read from the
device. This makes visualization refresh much faster, but it has the following consequences:
Only tracked parameter values are stored in the database.
The update interval of the value depends on the update of the device background readings
(specified in the device settings) and not on the visualization refresh period.
If there is no network connection, the last known value will still be displayed.
If the parameter is untracked or has never been read yet, NOLR will be displayed instead.
If you want to perform an actual reading of the device parameter, set the :r option at the end.
In this case:
It doesn’t matter if the parameter is tracked or untracked.
The value of the parameter is read from the device after each visualization refresh cycle
(usually every 10s).
If the network connection is missing, NORV is displayed.
Several special codes are returned by the server on various exceptions. You may see them instead of
the parameter value:
NON - parameter network does not exist.
NOP - parameter does not exist.
NOLR - no last reading for the parameter in the database (parameter has never been read). That
usually means that this parameter is untracked. Mark it as tracked or use real-time value
reading.
NORV - error reading parameter value from the device. Try reading it on the device parameters
list page to see the actual error.
React on the parameter value change: on-param-value="..." attribute
This attribute toggles the property or style specified by {{property}} between {{valueOn}} and
{{valueOff}} depending if the parameter referenced by {{paramRef}} satisfies the
{{condition}}.
{{condition}} can be one of the following:
>value
<value
=value
!=value
>=value
<=value
or {evalExpr} where evalExpr in curly braces can be any boolean JS expression with current
parameter value provided as x. See examples below.
If the condition is satisfied, the property and the style by the name provided by {{property}}
will be set to {{valueOn}}. Otherwise it will be set to {{valueOff}}.
{{options}} is a comma-separated list of flags. Currently supported flags:
r - read data directly from the device. By default it is taken from Overvis database of last
known parameter values.
Set text style color to red if the parameter value is greater than 10. Otherwise - green. Value is taken from the Overvis database, so the parameter should be tracked.
Text "alert!" will be visible if the parameter value is less than 20. The value is read from the device in real-time. By default (until the value is loaded), the text is hidden.
This attribute toggles the property or style specified by {{property}} between {{valueOn}} and
{{valueOff}} depending if the network referenced by {{netRef}} has connection or not.
If the parameter {{paramRef}} has the value different from {{defaultValue}} it should be set
to {{defaultValue}}, otherwise {{valueOn}}.
Example: <button on-click="toggle-param:12-34-56-78-90-ab>1>123:0:1:g">Toggle power</button> -
toggle parameter 123 between 0 and 1, where 0 is the default value. After the toggle, full
visualization refresh is done (because of the :g option at the end).
edit-param:{{paramRef}}:{{options}}
Open the dialog window to edit and save the value of the parameter.
Add {{amount}} to the value of the parameter {{paramRef}} and save the new value. Amount can
be negative. The parameter is refreshed before being incremented and written to the device.
edit-visdata:{{key}}
Open the dialog window to edit and save the visualization string with the key {{key}}. See
visualization strings table.
{{options}} is a comma-separated list of flags. Currently supported flags:
g - after the action is completed, do a complete refresh of all visualization data. If omitted,
by default - only the affected parameters will be refreshed.
An additional tag can be used anywhere in the code:
<aliasname="{{aliasName}}"... />
Alias tag should contain name attribute which specifies the name of the alias and one of the
following attributes which specifies the alias target:
network="{{networkRef}}"
device="{{deviceRef}}"
param="{{paramRef}}"
vis="{{visualizationRef}}"
Aliases are used when the object has to be referenced several times in the code. It helps to make
the references more understandable by giving them names. Also, it allows to quickly change the
target object, for example, if the network controller was replaced and the network MAC was changed.
Aliases can be used in references by specifying alias name after ~ (tilde symbol). Also, aliases
can be used inside other aliases, e.g. network alias can be used inside the device alias.
Visualizations can store string values to the Overvis database as key-value pairs. All stored
values are loaded during the visualization start-up if use-vis-data="yes" specified in
visualization settings tag.
To edit the value, use Overvis API. Also, the value can be edited by the user through the dialog
window. To open the dialog window, add the on-click="edit-visdata:{{key}}" attribute to the
button.
The following attribute allows you to use stored strings.
Text replacement: text-replacement="..." attribute
This example shows the room name as "Main room" by default, but also allows to edit it by
clicking on the "Edit". Edit will persist between page refreshes and different accounts accessing
this visualization.
A device template can include an alert template — a YAML definition of alerts that Overvis creates automatically when the template is applied to a device. This lets you ship standard monitoring rules (temperature limits, connection loss detection, etc.) together with the parameter configuration.
When applying a template, the user controls how alerts are handled — add new alerts, replace existing ones, or skip alert creation entirely. See Applying a template — Apply options for details. After creation, the alerts are independent and can be freely customized.
Documentation bellow assumes that you are changing one of the templates owned by your organization. If you want to modify the global template, accessible to all Overvis users, you have to copy it under your account. To do this, just download the template as an Excel file and upload it to your templates.
Manually created templates can be found in the local device template library. To access it, click on the “Your templates” link under the “Templates” section in the navigation.
Find the device template you want to modify and click the gear icon on the left to access the template settings.
On the settings page, scroll down until you find the “Alarms template YAML” textbox. Put the template code inside that box. The structure of this YAML is described in a later section of this document.
Save the changes. If the alerts template interpreter will encounter any errors it will report the details below the field.
description: "This alert tracks the value of the input 1. If value is less than 5 or larger than 10 during 5 minutes, SMS will be sent to the default phone. Also, if the default email address is specified, email will be sent right after the event starts and resolves."
level: "warning"
conditions_logic: "any"
conditions:
- param: "150h"
condition: "<"
value: "5.0"
- param: "150h"
condition: ">"
value: "10.0"
actions:
- kind: "sms"
recipient: "-"
stage: "init"
timeout_minutes: 5
- kind: "email"
recipient: "-"
stage: "init"
- kind: "email"
recipient: "-"
stage: "resolved"
- name: "No connection!"
description: "This alert checks connection to the network by verifying if the tracked firmware version parameter is reading correctly. If there was no reading during 5 minutes, Voice message will be sent to the default phone number."
Each event should contain one or more conditions (specified in the “conditions” field). Conditions determine when this event starts and resolves. Each condition is described as an object with following fields:
Name
Required
Type
Description
param
yes
string
Parameter address this condition will check. Syntax is described below. Parameter with this address should be listed in the template. Also, parameter should be tracked for this condition to work.
condition
yes
string
Logical operator that will compare parameter reading and the condition value specified in the “value” field. Allowed operators: >, >=, <, <=, =, !=, err. err checks for reading errors and doesn’t require “value” to compare to.
value
yes (if condition is not err)
string/number
Value to compare parameter reading to.
param is a string in one of the following formats:
<register address><register kind>
<register address>.<bit address><register kind>
Where “register kind” is one of:
h - holding register
i - input register
d - discrete input
c - coil
Examples of the condition objects:
YAML
Condition will be enabled if…
{param: "123h", condition: ">=", value: "10.5"}
Value of the parameter with the holding register address 123 is larger or equal 10.5 (comparison takes in account parameter multiplier and parameter type transformation).
{param: "123.5i", condition: "=", value: 1}
Value of the parameter that corresponds to the bit #5 of the input register address 123 is equal to 1.
{param: "1c", condition: "err"}
Reading of a parameter with the coil address 1 resulted in an error (either no connection, or MODBUS exception during parameter reading).
Each event should have one or more actions (specified in the “actions” field). Actions determine how the system should behave during each stage of the event. Each action corresponds to the one of the four “stages”:
init - event just started and is active.
not_confirmed - event was not confirmed during specified period of time. Confirmation period is specified in the action’s timeout field.
confirmed - event was confirmed by user (by SMS or clicking on the link in the notification email).
resolved - event resolved and is not active anymore.
Each action is described as an object with the following fields:
Name
Required
Type
Description
kind
yes
string
Kind of the action. Valid values: sms, email, call.
recipient
yes
string
Recipient email address or phone number (depends on the action kind). - value (minus sign) corresponds to the default email or phone.
stage
yes
string
Stage of the event when this action will be executed. Allowed values: init, not_confirmed, confirmed, resolved (see above).
timeout_minutes
no
number
Timeout in minutes before executing this action (positive integer). If an event leaves the appropriate stage during this timeout (for example “not confirmed” event resolves or being confirmed), action is never executed.
There are two ways to attach alert YAML to a device template:
In the Excel file — add an Alerts sheet to the template workbook. Row 1 is a header; the YAML goes in column A starting from row 2. See the Device Templates Reference — Alerts sheet for details.
In the web interface — open the template settings page and enter the YAML in the “Alarms template YAML” text field. Errors are reported below the field on save.
