Skip to content

Services and features

The Central Server is composed of multiple concurrent services that run in the background, depending on the active configuration and license. Some may be toggled on and off and some are always running.

Device connection service

This service is always enabled, and is responsible for connecting and maintaining sessions with all managed RAVAS devices on the network. On startup it reads the database for devices to connect to.

During runtime it works hand-in-hand with the Device scanning service to automatically add new devices and initiate or resume existing connections.

Devices may also be added manually by any user with at least the Manager role in the web interface (Add scale). This is intended for cases where a device is not discoverable or is not intended to be connected to (e.g. it is in RDC mode and will only push to the server, more on the RDC service). A device is identified by its IPv4 address and protocol (ASCII or RedBox).

This service attempts to maintain connections with all managed devices, reconnecting and logging the error when something goes wrong. When a connected device sends nothing for the Disconnect timeout, the server queries it and reconnects if it does not answer. After a failed connection attempt the server waits before the next one, adding the Reconnection time step to the wait after every failure, up to the Reconnection maximum time (see Connectivity). While waiting, the device's status is shown as Pending.

The server connects to ASCII scales on TCP port 10001 and to RedBox scales on TCP port 49112. For a managed ASCII scale it reuses the ASCII parameters stored in the database when reconnecting, because reading them from the scale is slow and may affect the indicator's operation. The Reconfigure button under ASCII protocol properties on the scale's Configure tab reads them from the scale again, which is useful when scale parameters like the unit label change.

Device scanning service

This service periodically broadcasts UDP packets on the ports 49111 (RedBox) and/or 30718 (ASCII). Each may be toggled on and off in the application settings.

The discovery process involves:

  • (Every 5 seconds) Broadcast the UDP packet on all network interfaces
  • Receiving a response from the scale
  • Initiate a TCP connection to the presumed scale
    • On RedBox: initiate a RedBox protocol connection and ask for the device UID, this confirms the validity of the device
    • On ASCII: send requests to get the parameters until the device unique ID (MacS) is retrieved, confirming that this is a valid device
  • Save the valid device in the database and disconnect from it
  • Pause handling the discovery of this IP address for 10 minutes by "tracking" the location, to avoid flooding the network with connection requests

Discovered network locations that are being paused are called "tracked locations"; they only appear in application logs. Locations of managed scales are not probed by discovery, as the server is already connected to them.

The broadcasts are sent to the broadcast address of each network the server is connected to, so they do not cross routers. Scales on other subnets have to be added manually.

If a device is managed and in the Pending connection phase (waiting to reconnect, mostly due to many consecutive failed attempts) and it is re-discovered on the local network, then the wait is cut short and the connection is re-attempted immediately.

This early reconnect will not happen if the error is not a connection timeout error. If instead the device is broken, for example if the device accepts the TCP connection but refuses to accept commands, the connection process fails and a reconnect is scheduled, however a re-discovery of this device will not trigger an early reconnect.

Server discovery responder

The server listens on UDP port 51001 and answers every packet it receives there with a fixed reply, so that programs on the local network can find the server. It is enabled by default. The broadcastSelf setting turns it off; it is not shown on the Settings page and can only be changed through the settings API.

RDC service

This service replicates the legacy behavior of the RAVAS Data Collector (RDC). It opens a TCP socket (by default on port 5555) awaiting weight records in the push data record (PDR) format defined for RDC. It requires the RDC feature in the license and can be toggled and moved to another port in the application settings.

The central server implements this protocol, and similarly to the legacy RDC, logs all connection events and requests made over this service.

The pushed weight records contain a three-character scale identifier. The central server finds the appropriate device by matching this identifier against the device's Custom ID, its Scale unique name, or its internal ID. In practice, set the Custom ID of the scale to the identifier configured on the indicator (e.g. 103). The Custom ID can be changed at any time by users with at least the Manager role.

Also similarly to the legacy RDC, the scales must be defined manually in the central server beforehand. These scales shouldn't be managed, as an indicator in RDC mode will not accept ASCII commands nor has any way to collect parameters or data in the server-to-scale direction.

Each message is answered with ACK or NACK:

  • weight records (WDR) and initialization messages (INI) from a known scale are acknowledged with ACK;
  • messages for an unknown scale, malformed messages and messages with an invalid date are answered with NACK and logged; the weight data is ignored;
  • a weight record with the same sequence number and alibi number as one already stored for that scale is acknowledged, but not stored twice.

The indicator sends the weighing date as dd/MM/yy or MM/dd/yy, depending on its configuration, without saying which. The server learns the order per scale from the first date that can only be read one way (a day above 12). Until then, a date that can be read both ways is taken as the reading closest to the time of receipt that is not in the future, allowing for one day of clock difference. The time is interpreted in the server's time zone.

Values in the custom fields after the alibi number are stored as Field #1, Field #2 and so on. Each field keeps its position: if the first field is empty and the second contains a product code, the code is stored as Field #2.

Indicators that upload over HTTP use the legacy upload route instead.

In order to view the collected weights, you may access Saved weights from the sidebar for an overview for all scales. Set the Source filter to RDC to only see weights received through this service or the legacy upload route.

This can also be done per-scale by accessing the relevant scale page, then going to the Saved weights tab.

Data collection

With data collection enabled, the server records data from the scales it is connected to, managed scales continuously and unmanaged scales while a request keeps a connection open.

The server keeps two kinds of weights, shown on separate pages:

  • Weight updates are the stream of weights read from connected scales. A new record is stored whenever the weight reported by a scale changes. They show how a scale was used over time, and are deleted after the Device weight retention time.
  • Saved weights are weights explicitly stored as a weighing result: received through the RDC service, uploaded through the API, or saved from a scale's current weight through the API. They are never deleted automatically.

Both pages can be filtered by scale, date and other fields, and the Export button downloads the selected records as a CSV file (at most 100 000 records per export).

Besides weights, the server collects:

  • the connection history of each scale, used for the uptime charts on the Monitoring page;
  • the values of RedBox parameters, shown on the scale's System tab;
  • device-related application logs and the logs generated by RedBox devices, shown on the scale's Logs tab.

The Application logs page shows the server's own logs stored in the database. Independently of these settings, the server writes its logs to files in C:\Program Files\RAVAS\Central Server\server\logs, see Logs.

How long collected data is kept is set in Data retention.