Services and features
The server runs these services in the background. Some always run, others depend on the license and the application settings.
Device connections
The server keeps a connection to every managed scale, on TCP port 10001 for ASCII scales and 49112 for RedBox scales. When a scale stays silent for the Disconnect timeout, the server checks on it and reconnects if it doesn't answer. After a failed attempt it waits before the next one, a Reconnection time step longer after every failure, up to the Reconnection maximum time (see Connectivity). While it waits, the scale is Pending.
Scales are added by discovery, or by hand with Add scale. Add a scale by hand when it can't be discovered, for example in another subnet, or when the server isn't meant to connect to it, like an indicator in RDC mode.
The server reads an ASCII scale's parameters once and reuses them when it reconnects, since reading them is slow and can disturb the indicator. After changing a parameter on the scale, such as the unit, select Reconfigure on the scale's Configure tab to read them again.
Device discovery
Every 5 seconds the server broadcasts a UDP packet on port 49111 for RedBox scales and on port 30718 for ASCII scales, each when enabled in the settings. It connects to each scale that answers, reads its unique ID, saves it and disconnects. It then leaves that address alone for 10 minutes.
Broadcasts don't cross routers, so only scales in the server's own networks are found; add the others by hand. When a managed scale that is waiting to reconnect after a timeout is found again, the server reconnects right away.
Server discovery responder
The server answers packets on UDP port 51001, so that programs on the local network can find it. The broadcastSelf setting turns this off; it isn't on the Settings page, only in the settings API.
RDC service
The RDC service takes over from the RAVAS Data Collector: it listens on TCP port 5555 for the weight records that indicators in RDC mode push. It needs the RDC module and is set up in the application settings.
As with the RDC, add each scale to the server by hand first, and leave it unmanaged: an indicator in RDC mode only sends, it doesn't take commands. Each record carries a three-character scale identifier, which the server matches against the scale's Custom ID, its Scale unique name or its ID. So set the Custom ID of each scale to the identifier configured on its indicator, e.g. 103.
The server answers each message with ACK or NACK:
ACKto weight records and initialization messages from a known scale. A weight record with the same sequence and alibi number as one already stored is acknowledged, but not stored twice.NACKto messages for an unknown scale, malformed messages and invalid dates. These are logged, and the weight is dropped.
Indicators send the date as dd/MM/yy or MM/dd/yy, depending on their configuration. The server works out which from the first date of each scale that can only be read one way (a day above 12); until then it takes the reading closest to the current time. Times are in the server's time zone.
The custom fields after the alibi number are stored as Field #1, Field #2 and so on, by position: a product code in the second field is Field #2, even when the first is empty.
The weights appear under Saved weights, for all scales or on a scale's page; set the Source filter to RDC to see only these. Indicators that upload over HTTP use the legacy upload route instead.
Data collection
With data collection on, the server records data from the scales it's connected to: managed scales all the time, others while a request keeps them connected.
It keeps two kinds of weights, on separate pages:
- Weight updates: every change of a scale's weight, which shows how it was used over time. Deleted after the
Device weight retention time. - Saved weights: weighing results, received through the RDC service, uploaded through the API or saved from a scale's current weight. Never deleted automatically.
Both pages can be filtered, and Export downloads the selected records as a CSV file, up to 100 000 at a time.
The server also collects the connection history of each scale, for the uptime charts on Monitoring, the values of RedBox parameters, on the scale's System tab, and logs, on the scale's Logs tab. Application logs shows the server's own logs from the database; it writes them to log files as well, whatever the settings.