Thread Configuration

Threads control when the clocks perform routine tasks such as submitting clock entries or checking for software updates. Each thread task can be run on an interval-basis or following a set schedule.

Important: These values shouldn’t be modified without consultation.

Unless otherwise stated below, each thread has the following attributes:

name: The unique name that marks each thread. Each available thread is described in the table below. Don’t edit these values.
mode: The mode that the thread operates in. It’s recommended that you don’t edit these values. The following modes are available:
- interval: The thread runs at an interval. Use the interval attribute to set the interval length.
- schedule: The thread runs on a schedule. Threads that run in schedule mode have additional <schedules> tags that you need to configure to set the schedule:
  - schedule: The time that you want the thread to run every day, in the 24-hour format.
  - randomization: The number of seconds that the clock randomizes the scheduled start time by. This functionality helps to ensure that multiple clocks in one location don’t perform a thread at the same time and burden the network.
- demand: The thread runs as needed. This attribute is used only by threads that are tied to the Request Log Files and Request Clock Database checkboxes in Site Setup > Clock Devices. When users click these checkboxes, the threads are run immediately.
active: Set to yes to enable the thread or no to disable it.
interval: The number of seconds that the clock waits until running the thread again. This attribute applies only for threads running in interval mode.
retries: The number of times that the clock will retry running the thread after it fails. For example, to specify that the clock should retry the thread twice, specify retries="2".
retry_interval: The amount of time that the clock waits before it tries to run the thread again. For example, to specify that the clock should wait 60 seconds before retrying, specify retry_interval="60".

<threads> tags
Thread	Clock Pro Support	Clock+ Support	Description
SynchronizeTime	√	√	Determines how often the clock synchronizes its time with Dayforce.
CallHome	√	√	Controls how often the clock communicates with the admin server.
SendHeartbeat	√		Determines how often the clock sends its “heartbeat,” which tells the application that the clock is online.
UpdateSoftware	√		Determines when the clock automatically checks for software updates and installs the update when new software is found. This task is usually scheduled to take place at or near a specified time. By default, this thread is configured to randomize the scheduled start time by 2 hours (or 7,200 seconds).
UpdateFirmware	√		Determines how often the clock checks for firmware updates. When an update is found, the clock automatically installs it.
SubmitLogFiles	√		Determines when the clock’s log files are sent to Dayforce. If the interval is set to `0`, the task runs only when it’s triggered for diagnostic or troubleshooting purposes. Note: If the interval isn’t set to `0`, clocks might overwhelm the servers. This thread is initiated when users select the Request Log Files checkbox in Site Setup > Clock Devices.
SubmitClockDB	√		Determines when the clock’s database is sent to Dayforce. This thread is initiated when users select the Request Clock Database checkbox in Site Setup > Clock Devices.
UpdateDatabase	√	√	Determines how often the clock synchronizes its database with Dayforce. Data that’s synchronized includes the list of employees, schedules, job assignments, and dockets required for validation on the clock. It has the following additional attribute: `<incremental>`: Limits the amount of information that the clock receives when it updates the database. By default, this attribute is enabled and the clock receives only information that’s been updated since the last time it ran the thread. When disabled, the clock receives all of the information from the database, regardless of whether or not it’s been changed. This thread isn’t required for clocks operating in online mode.
ExchangeBioTemplates	√	√	Determines how often clocks send recently-enrolled or modified biometric templates to the server and receive templates enrolled on other clocks. It has the following additional attribute: `<page_size>`: Controls the amount of data sent at the same time to prevent overloading the server.
CleanupDatabase	√	√	Determines when the clock can clean up its database. This task must be scheduled at a time of low activity and not while software is being updated. It has the following additional attribute: `<punch_age>`: The age (in days) before exported clock entries are purged from the clock’s database.
SubmitPictureTemplates	√		Determines when the clock transmits picture templates to Dayforce. These picture templates are the pictures that the clock captured during the photo enrollment process. It has the following additional attribute: `<page_size>`: Controls the number of templates submitted at the same time to prevent overloading the server.
SendMessages	√		Determines when the clock sends information to its peers when clocks are configured for inter-clock communication. See Configure Inter-Clock Communication (Hardware Clocks Only).
SyncPeers	√		Determines how often the clock receives updated IP addresses from clocks it’s configured to communicate with. When the IP address is out of date, the clock stores any messages that failed and resends them after the address is updated.
SubmitClockInfoOnStartup	√		Determines if the clock transmits its health data (such as temperature) to Dayforce after it starts up.
SubmitClockHealth	√		Determines the clock’s schedule for transmiting its health data to Dayforce.
EssMessageSync	√		Determines how many unread messages exist for active employees who perform clock entries on the clock. This thread also sends the unread message count to the clock for display when the employee performs a clock entry.
NetworkReboot	√		Determines when the clock automatically reboots after losing network connectivity.
SubmitPunches	√	√	Determines how often clocks in standalone mode submit clock entries. It has the following additional attribute: `<page_size>`: Controls the number of clock entries submitted at the same time to prevent overloading the server. A value of 100 is recommended.