Advanced Network and Service Health Monitor

v1.1

The Advanced Network and Service Health Monitor provides centralized health monitoring for up to thirty-two independently configured network devices or services.

Each method-specific monitor may use ICMP, TCP, HTTP, HTTPS, a direct DNS IPv4 A-record query, or a read-only SNMPv1/SNMPv2c single-OID GET request and provides separate effective and underlying status, dependency suppression, maintenance feedback, bounded rolling response-time statistics, counters, timestamps, results, diagnostics, and transition events.

Checks continue during suppression and maintenance and are serialized through a bounded Buttonwood Runtime queue to control RTI processor and network load.

Up to eight dealer-named Composite Statuses can evaluate existing monitor results using All, Any, or Quorum logic without creating additional network traffic or consuming the thirty-two-monitor capacity.

Integration Designer Setup

1. Add the driver to the test project.

2. Under Monitor Types, enable each required method and select its count from 0 through 32. The combined count across ICMP, TCP, HTTP, HTTPS, DNS, and SNMP must not exceed 32.

3. The selected counts expose stable method-specific monitor sections. Turning off a monitor type hides and disables that type without changing the saved count.

4. Retain Enable Monitor for active slots. Clearing it preserves the slot configuration and identity but stops its checks and events.

5. Give every monitor a unique descriptive name, such as Core Switch ICMP or Firewall HTTPS Management. The name is used in Driver Events, System Variables, commands, and diagnostics.

6. Select Enable Dependency only when an upstream monitor must be available before this monitor can report meaningful independent health. Leave it clear for an independent monitor.

7. Enable Dependency reveals Dependency Monitor immediately below it. Select one configured and individually enabled earlier monitor by its stable type-and-number label, such as ICMP Monitor 01. Do not leave None selected when Enable Dependency is checked.

8. Dependency Monitor choices are intentionally static. Integration Designer cannot individually filter Driver Property choices or replace them with dealer-entered names, so the list can include earlier slots that are not configured or enabled. Startup validation rejects unavailable selections and reports Configuration Valid as false.

9. Enter each host without http://, https://, a port suffix, or a path. Enter HTTP or HTTPS paths separately and begin them with a slash.

10. Start with a 60-second Cycle Interval, 3-second Probe Timeout, 250-ms Request Spacing, Failure Confirmation of 3, and Recovery Confirmation of 2. Increase the interval when many monitors or slow failures are expected.

11. Enable Trace and leave Verbose Trace off initially. Send programming, wait for Startup Delay, and confirm Configuration Valid, Feedback Synchronized, and Monitoring Active.

12. Commission every monitor with both a known-good result and a controlled failure. Restore the target and confirm that the configured recovery count is honored.

13. Leave Maximum Acceptable Response Time at zero while observing normal performance. When performance alerting is required, set a site-appropriate millisecond threshold above the normal range and verify both confirmed degradation and recovery.

14. When a combined Boolean result is required, enable Composite Statuses, select the number of composites, and configure each member using its single Member Monitor dropdown. Select the stable method-and-number label corresponding to the required configured monitor. Review the Composite Statuses section before using the result in automation.

Selecting the Appropriate Monitor Type

Use ICMP when basic IP reachability and round-trip time are useful and the target permits ping. ICMP failure does not prove that the host is powered off because firewalls and many devices block or rate-limit ICMP.

Use TCP when acceptance of a particular port is the meaningful minimum test. TCP confirms only that the host accepted a connection on that port; it does not prove that the application, login, API, webpage, or complete device is healthy.

Use HTTP when an unencrypted web endpoint can return an exact expected status. GET may also require a case-sensitive literal substring from the response body. HEAD checks status only and can fail when a server does not implement HEAD correctly.

Use HTTPS when TLS and the web endpoint must both succeed. Prefer the DNS hostname covered by the server certificate instead of an IP address. HTTPS publishes the RTI TLS certificate reason for investigation and provides no certificate-verification bypass.

Use DNS when the selected resolver must answer an IPv4 A-record query for a hostname. A blank Expected IPv4 Address accepts any returned A record; populate it only when the service is documented to use a stable address. DNS success proves that resolver answered this query, not that the resolved service is reachable.

Use SNMP when the device exposes a documented numeric scalar OID through a read-only SNMPv1 or SNMPv2c agent. SNMP success proves that the agent returned the requested OID without a protocol error; it does not prove that every device function is healthy. The driver never sends SNMP SET operations.

Category identifies the target as a Device or Service for dealer organization. It does not change how the selected probe operates.

ICMP Monitor Example

Example purpose: confirm that a managed core switch responds on its management address.

Monitor Name: Core Switch ICMP. Category: Device. Host: 10.0.50.2. Maximum Acceptable Response Time: 0 during initial commissioning; after observing a stable baseline, a dealer may use a site-appropriate value such as 50 milliseconds.

Interpretation: Online means this management address answered ping. It does not prove that every switch port, VLAN, uplink, PoE output, routing function, or management service is working.

TCP Monitor Example

Example purpose: confirm that the managed switch's HTTPS management port accepts a connection.

Monitor Name: Core Switch HTTPS Port. Category: Service. Host: 10.0.50.2. Port: 443. Maximum Acceptable Response Time: 0 initially, or a value established after observing normal operation.

Interpretation: Online means TCP port 443 accepted a connection. This check does not perform an HTTPS request, validate a certificate, authenticate, or prove that the management interface returns usable content. Use an HTTPS monitor when those additional layers matter.

HTTP Monitor Example

Example purpose: validate a local device or server webpage that does not use TLS.

Monitor Name: Equipment Web Status. Category: Service. Host: 10.0.50.40. Port: 80. Path: /. Method: GET. Expected Status: 200. Body Contains: use one stable, case-sensitive product or page identifier observed in the actual response, or leave blank to validate status only. Maximum Acceptable Response Time: 0 initially.

Body Contains is literal text, not a regular expression. Do not escape angle brackets or enter HTML markup unless those exact characters must occur in the returned body. Prefer a stable visible word over fragile surrounding HTML.

HTTPS Monitor Example

Example purpose: commission outbound HTTPS monitoring with a known public webpage before configuring the customer's actual service.

Monitor Name: Public HTTPS Test. Category: Service. Host: www.google.com. Port: 443. Path: /. Method: GET. Expected Status: 200. Body Contains: About. Maximum Acceptable Response Time: 0 initially.

DNS Monitor Example

Example purpose: distinguish DNS failure from a broader Internet or HTTPS failure.

Monitor Name: Public DNS Resolution. Category: Service. DNS Server: 8.8.8.8 or the customer's approved resolver. Port: 53. Hostname to Resolve: www.google.com. Expected IPv4 Address: leave blank because public service addresses can change. Maximum Acceptable Response Time: 0 initially.

Interpretation: Online means the selected DNS server returned at least one IPv4 A record. It does not prove that the returned service is reachable, that other record types resolve, or that every client uses the same resolver. For local-name testing, query the customer's actual router or internal DNS server rather than a public resolver.

SNMP Monitor Setup

SNMP monitors issue one read-only GET request for one numeric scalar OID. Enter the device hostname or IPv4 address, normally leave Port at 161, select SNMPv2c when the equipment supports it, enter the configured read-only Community, and enter a numeric OID. A leading period is optional. Symbolic MIB names are not supported. SNMPv3 authentication and encryption are not supported in v1.1.

Successful Response reports Online when the device returns the requested value without an SNMP protocol error. Numeric Comparison compares a numeric returned value with Expected Numeric Value using the selected operator. Numeric Range requires the value to be within the inclusive Minimum and Maximum values. Exact Value performs a case-sensitive comparison with the rendered returned value.

Value Changed uses the first successful response as an Online baseline. Later polls are Online only when the value differs from the preceding successful response. Use this only for counters or values that should change every monitoring cycle; an idle interface or other legitimate unchanged value will report a failed evaluation. Counter rollover still counts as a change.

Integer, Counter32, Gauge32, TimeTicks, and safely representable Counter64 values can be evaluated numerically. Large Counter64 values are retained exactly as text but are not accepted for numeric comparison because JavaScript cannot represent them without precision loss.

Use a dedicated, non-default, read-only community wherever the device permits it. The community is case-sensitive, is stored in the Integration Designer project, and is intentionally omitted from TraceViewer output.

SNMP Managed Switch Availability Example

Enable SNMP Monitor Type and allocate one monitor. Set Host to the switch management address, Port to 161, select the version enabled on the switch, and enter its read-only community. Set Object Identifier to 1.3.6.1.2.1.1.3.0 for sysUpTime and set Evaluation Type to Successful Response.

This verifies that the SNMP agent answered the requested OID. It does not prove that every switching function is healthy.

SNMP Temperature Threshold Example

Use the manufacturer-documented scalar temperature OID and set Evaluation Type to Numeric Range. Enter the acceptable inclusive Minimum and Maximum values in the units returned by that OID. Confirm whether the device reports whole degrees, tenths of a degree, or another scale before setting limits.

SNMP Counter Activity Example

Use a manufacturer-documented counter OID that should advance during every configured cycle and select Value Changed. Do not use this evaluation for an idle interface or a counter that can legitimately remain constant.

SNMP Feedback

Returned Value and TimeTicks Duration are normally visible. TimeTicks Duration renders an SNMP TimeTicks value as Xd HH:MM:SS.hh while preserving the exact raw Returned Value. It represents uptime only when the selected OID measures uptime, such as sysUpTime.0 or hrSystemUptime.0, and reports Not applicable for other SNMP data types.

When Expose Advanced Diagnostic Variables is enabled, the driver also exposes Returned OID, Returned Data Type, Numeric Value Valid, and Numeric Value. Value Changed is shown only when the monitor uses the Value Changed evaluation type. SNMP monitors retain the ordinary Name, Probe Method, Enabled/Disabled, state, response-time, statistics, maintenance, dependency, and event behavior described for other monitors.

SNMP Limitations and Security

SNMPv1 and SNMPv2c community strings are not encrypted on the network. Restrict SNMP to trusted management networks, use a dedicated read-only community and access-control list where supported, and do not expose UDP 161 to the public Internet. The driver does not load MIB files, resolve symbolic OIDs, walk tables, perform discovery, issue SET operations, or support SNMPv3.

Routers, Firewalls, Switches, and Access Points

For a router or firewall, use one monitor for the local management address and a separate remote HTTP or HTTPS monitor when Internet reachability matters. A successful check of the router's LAN address proves only that the local interface responded; it does not prove DNS resolution, WAN service, or general Internet access.

For a managed switch, ICMP is appropriate for basic management-plane reachability. Add TCP or HTTP/HTTPS only when the corresponding management or control service is expected to remain enabled. Use the actual configured service port rather than assuming that every switch exposes ports 22, 80, or 443.

An unmanaged switch normally has no IP endpoint and cannot be monitored directly. Monitoring a downstream device can reveal a path failure but cannot uniquely identify the unmanaged switch as the cause.

For a wireless access point, ICMP can monitor its management address and TCP or HTTPS can monitor an enabled management service. Neither check proves client association, RF coverage, roaming, channel quality, or Internet access through that access point.

Use DHCP reservations or static management addresses for local infrastructure. Use DNS hostnames for certificate-based remote HTTPS services. Do not create multiple monitors that test the same layer unless each has a documented diagnostic or automation purpose.

HTTP and HTTPS Limitations

The current build requires one exact status code and does not follow redirects. Configure the final host and path when possible. Monitoring a 301 or 302 response proves only that the redirect response was returned, not that its destination is healthy.

Body Contains is optional, case-sensitive, and literal. It is evaluated only for GET. Dynamic values, timestamps, localization, advertising, personalization, and frequently changing HTML make poor assertions.

Authenticated HTTP endpoints are not supported in the current build. Do not place usernames, passwords, bearer tokens, or other secrets in Host, Path, or Body Contains.

A server may reject HEAD even though GET works. If HEAD returns an unexpected status, use GET with no body assertion or a stable literal assertion.

Scheduling and Capacity

Each type supports 0 through 32 monitors for flexible installation design. Startup validation rejects a combined enabled-type count above 32 before any checks are scheduled. Each individually enabled configured monitor is queued exactly once per cycle.

The 32-check ceiling is based on the completed XP-8v physical feasibility test. Large HTTPS-heavy or timeout-heavy configurations may require a 120- or 300-second Cycle Interval because the queue intentionally serializes transports.

Choose a Cycle Interval longer than the normal serialized cycle duration. As a conservative example, thirty-two probes that each consume a 3-second timeout plus 250 milliseconds of spacing can require approximately 104 seconds plus processing overhead. Use a 120- or 300-second interval for that failure-heavy condition.

Configured and Enabled monitor counts are normally visible read-only variables. ICMP, TCP, HTTP, HTTPS, DNS, and SNMP counts are read-only variables available when Expose Advanced Diagnostic Variables is enabled.

The queue permits one active transport. Request Spacing separates completed checks. Probe Timeout advances the queue after a stalled check.

Failure Recheck Interval shortens the next cycle after any probe is Degraded or Offline but continues to use the same bounded queue.

Maximum Acceptable Response Time is optional. Leave it at zero until normal response behavior has been observed. Zero disables slow-response classification but does not disable response-time statistics. With a nonzero threshold, three slow results among the latest five successful checks confirm Degraded; one or two isolated slow results leave the monitor Online. Three consecutive acceptable successful checks restore Online. Failed checks remain governed by Failure Confirmation and are not counted as slow samples.

Response Time is the latest completed check's measured duration; a failed check can therefore replace it. Rolling Average Response Time uses no more than the latest ten successful checks. Minimum and Maximum Response Time cover successful checks since the applicable statistics reset. Slow Response Count is cumulative since reset; Recent Slow Responses reports how many of the latest five successful checks exceeded the configured threshold.

Performance samples and accumulated statistics are held in processor memory and are not written to persistent storage after every check. They initialize when the driver starts or programming reloads and can also be cleared with Reset Monitoring Statistics.

Use a longer Cycle Interval for customer equipment that rate-limits probes, for remote Internet services, and for installations with many HTTPS checks. Obtain permission before repeatedly monitoring a third-party public service.

Commands and Events

Set Monitoring provides Stop, Start, and Toggle choices and persists the resulting monitoring state. Validate Runtime Configuration reports whether the configured monitor set is valid. Monitoring checks run automatically; no manual Check commands are exposed.

Set Global Maintenance provides Enable, Disable, and Toggle choices for every configured monitor.

Set Monitor Maintenance selects one configured monitor by its dealer-entered name and provides the same choices. Global and per-monitor maintenance selections persist through processor reboot, programming reload, and power cycle.

Maintenance changes effective Status to Maintenance and suppresses Online, Degraded, and Offline transition events, but it does not stop checks. Underlying Status, counters, timestamps, response times, Last Result, and Last Error continue updating. Disabling maintenance silently establishes the current underlying result before later genuine transitions can fire events.

Reset Monitoring Statistics provides one Monitor dropdown. All Monitors appears first, followed by configured monitors displayed with their dealer-entered names. Selecting All Monitors resets aggregate cycle statistics plus every monitor's accumulated attempts, successes, failures, rolling response-time samples, response-time minimum and maximum, and slow-response counts. Selecting one monitor resets only that monitor's corresponding statistics.

Statistics reset never changes confirmed health, failure/recovery confirmation state, Last Degraded Time, timestamps, or the current Online, Degraded, or Offline result. A monitor already Degraded for performance still requires three consecutive acceptable successful checks to recover after a reset. Internally, every choice retains its stable method-specific slot even when two monitors have the same displayed name.

The first confirmed state is silent. Later accepted transitions can fire Online, Degraded, or Offline for the applicable monitor. A slow-result event is not exposed; Degraded fires only after performance confirmation or the existing availability-health logic accepts Degraded. Monitoring Cycle Complete fires after each full cycle.

Failure Confirmation and Recovery Confirmation apply globally. Program customer notifications from confirmed events rather than raw diagnostic text, and avoid automatically rebooting or power-cycling equipment from a single monitoring event without additional safeguards.

Monitor Dependencies

Enable Dependency is the Driver Property gate for each monitor. When checked, Dependency Monitor appears directly below it. Select one configured and individually enabled earlier monitor by its stable type-and-number label. The selected parent monitor's dealer-entered name appears later in the monitor's read-only Dependency feedback.

The dropdown contains None plus every earlier stable slot because Integration Designer can condition the visibility of a whole Driver Property but cannot individually filter its choices or substitute dealer-entered names in those choices. Some listed slots may therefore be unavailable. Startup validation rejects None while dependency handling is enabled and rejects disabled, unconfigured, self, and forward dependencies before monitoring begins.

Dependency selection is stored as part of the Integration Designer project and is reapplied on processor load, programming reload, and power cycle. No commissioning macro or dealer settings page is required. Clearing Enable Dependency makes the monitor independent while retaining the hidden property selection in the project for later re-enabling.

When a dependency is Offline, Unknown, unavailable, or itself Suppressed, the dependent monitor reports effective Status Suppressed and identifies the parent condition in Suppression Reason. A Degraded dependency does not suppress its children. Suppression propagates through a dependency chain.

Suppressed monitors continue checking their actual target. Underlying Status and diagnostic variables retain those real results, but the monitor does not fire Online, Degraded, or Offline events while suppressed. When the dependency recovers, the dependent silently establishes its current underlying state before later transitions are allowed to fire.

Use dependencies for actual upstream relationships, such as an access point depending on its switch, an application depending on its server, or a remote service depending on the monitored Internet path. Do not use dependencies merely to group unrelated equipment.

Status and Aggregate Feedback

Status is the effective dealer-facing state. Its priority is Disabled, Maintenance, Suppressed, then the confirmed underlying state of Unknown, Offline, Degraded, or Online. Underlying Status reports the confirmed probe result independently of maintenance or dependency suppression.

Enabled and Disabled Boolean variables are complementary and can control GUI layers. Online, Degraded, Offline, Unknown, Suppressed, and Maintenance Boolean variables correspond to effective Status. Maintenance is the authoritative Boolean indicating that global or selected-monitor maintenance currently applies.

Aggregate Health variables count enabled monitors by effective state. Any Monitor Offline is true only when at least one enabled monitor has effective Status Offline. All Monitors Online is true only when at least one monitor is enabled and every enabled monitor has effective Status Online.

Composite Statuses

Enable Composite Statuses and select from zero through eight Composite Statuses. Each composite has its own Enable Composite Status property, Composite Name, Evaluation Basis, Evaluation Mode, Number of Members, and one through eight Member Monitor selections. Each Member Monitor dropdown begins with Select Monitor and then lists every stable slot from ICMP Monitor 01 through ICMP Monitor 32, TCP Monitor 01 through TCP Monitor 32, HTTP Monitor 01 through HTTP Monitor 32, HTTPS Monitor 01 through HTTPS Monitor 32, DNS Monitor 01 through DNS Monitor 32, and SNMP Monitor 01 through SNMP Monitor 32. Composite evaluation uses existing monitor results, creates no additional probes, and does not consume the thirty-two-monitor capacity.

Health - Online Only treats Online as passing and both Degraded and Offline as failing. Availability - Online or Degraded treats Online and Degraded as passing while Offline is failing. Unknown, Disabled, Suppressed, Maintenance, missing, or invalid remains Indeterminate under either basis.

All (AND) requires every selected member to pass. Any (OR) requires at least one selected member to pass. Quorum requires the selected Required Passing Members count to pass; this value cannot exceed Number of Members. Do not select the same monitor more than once in one composite. Startup validation rejects incomplete, disabled, unconfigured, duplicate, and invalid-quorum selections.

Use Result only when Evaluation Valid is True. When evidence is Indeterminate, Evaluation Valid is False, Evaluation Status is Indeterminate, and Result is held False so the Boolean output remains deterministic without representing a confirmed outage.

Composite Status Summary reports configured, enabled, True, False, and Indeterminate counts together with Any Composite False and All Composites True. Each composite reports Result, Evaluation Valid, Evaluation Status, Evaluation Basis, Evaluation Mode, member counts, Required Passing Members, Passing Member Count, Member Summary, Last Evaluation, and Last Change.

Each enabled composite provides Became True, Became False, and Became Indeterminate events. The first complete result after startup is established silently, and repeated same-state evaluations do not retrigger events. Entering Maintenance makes an affected composite Indeterminate without manufacturing an outage event; leaving Maintenance silently establishes a new baseline before later genuine transitions can fire.

Internet Availability

Use Composite Statuses to combine separate Internet observations. For a strict two-member Internet Status, configure an HTTPS monitor for a stable Internet endpoint and a DNS monitor that resolves a hostname through the desired resolver, select Availability - Online or Degraded, and then select All (AND). Internet Status is True only when both monitors pass the selected basis.

For a more resilient result, configure three independent monitors, such as DNS through the customer's resolver, HTTPS to a stable endpoint from another provider, and ICMP or TCP to a permitted third endpoint. Select Availability - Online or Degraded and Quorum with Required Passing Members set to 2. This avoids declaring Internet service unavailable solely because one public endpoint or protocol is unavailable.

Recommended Internet Available Composite Example

Configure HTTP Monitor 01 as Microsoft Connectivity. Enable Monitor: selected. Category: Service. Host: www.msftconnecttest.com. Port: 80. Path: /connecttest.txt. Method: GET. Expected Status: 200. Body Contains: Microsoft Connect Test. Maximum Acceptable Response Time: 0. Enable Dependency: cleared.

Configure HTTPS Monitor 01 as Google Web. Enable Monitor: selected. Category: Service. Host: www.google.com. Port: 443. Path: /. Method: GET. Expected Status: 200. Body Contains: blank. Maximum Acceptable Response Time: 0. Enable Dependency: cleared.

Configure DNS Monitor 01 as Public DNS. Enable Monitor: selected. Category: Service. DNS Server: 8.8.8.8. Port: 53. Hostname to Resolve: www.google.com. Expected IPv4 Address: blank. Maximum Acceptable Response Time: 0. Enable Dependency: cleared.

Create a composite named Internet Available. Select Availability - Online or Degraded, select Quorum, set Number of Members to 3, set Required Passing Members to 2, and select HTTP Monitor 01, HTTPS Monitor 01, and DNS Monitor 01 as its three members.

Availability - Online or Degraded prevents a slow but functioning endpoint from being treated as an outage. Leave Maximum Acceptable Response Time at zero unless the separate Degraded state is useful for diagnostics. Do not create dependencies among the three monitors. On a GUI, use Evaluation Valid with Result so Indeterminate is not presented as a confirmed outage. Use Became False for an Internet-down notification and Became True for service restoration.

Using www.google.com and 8.8.8.8 is valid for commissioning, but both rely on Google infrastructure and do not provide provider diversity. Obtain permission before monitoring third-party endpoints and do not use one composite as the sole evidence for contractual service-level or consequential automation.

Troubleshooting

If Configuration Valid is false, confirm that every enabled configured monitor has a host, every port is within range, every HTTP/HTTPS path begins with a slash, every SNMP monitor has a numeric scalar OID and community, the combined enabled-type count does not exceed 32, and every dependency-enabled monitor selects a configured and enabled earlier Dependency Monitor rather than None. For Composite Statuses, confirm that every active member has a Member Monitor selection other than Select Monitor, refers to a configured and individually enabled monitor, is not duplicated within the same composite, and does not require a quorum greater than Number of Members.

If ICMP fails while TCP or HTTPS succeeds, the endpoint or an intervening firewall probably blocks or rate-limits ICMP. Select the probe that represents the service you actually need to verify.

If TCP succeeds but HTTP or HTTPS fails, inspect the configured port, path, expected status, TLS certificate reason, and body assertion. TCP success alone is not contradictory because it validates only connection acceptance.

If ICMP to a public IP succeeds but DNS fails, confirm the DNS Server address, UDP port 53 access, and Hostname to Resolve. A DNS Name does not exist result can be valid evidence that the queried name is absent; a timeout can indicate filtering or an unavailable resolver.

If DNS succeeds but HTTPS fails, inspect TCP port 443, TLS, certificate naming, the request path, expected status, and body assertion. DNS success proves name resolution only.

If HTTP or HTTPS returns a status mismatch, check for a redirect, authentication requirement, maintenance response, or a server that rejects HEAD. The driver does not follow redirects or authenticate in this build.

If Body Contains fails, copy a short stable literal directly from the actual response body and match its capitalization. About works for the commissioning example; About</a>, escaped HTML, or browser-rendered text may not match the bytes returned to the driver.

If SNMP times out, verify that SNMP is enabled on the target, the configured version and case-sensitive read-only community match, UDP 161 is permitted from the RTI processor, and any device access-control list includes the processor address. If the agent reports an OID error, confirm the numeric scalar OID against the manufacturer's documentation. If a numeric evaluation is invalid, inspect Returned Data Type, Numeric Value Valid, and Numeric Value with Advanced Diagnostic Variables enabled.

If the effective interval grows, compare Cycle Duration with Cycle Interval and inspect timeout and queue-depth variables. Increase the interval or reduce slow and redundant monitors instead of shortening Request Spacing aggressively.

Diagnostics

Normal Trace reports startup, validation, synchronization, confirmed states, cycle summaries, failures, and recovery. Verbose Trace adds every queue and transport operation and can be high volume with many monitors.

Expose Advanced Diagnostic Variables defaults to disabled. Enable it before sending programming only when the project requires detailed scheduler, queue, response-history, confirmation-progress, composite-evaluation, or SNMP protocol variables for an advanced service interface or troubleshooting. Name, Probe Method, Enabled, Disabled, effective-state, dependency, suppression, slow-response, composite-result, and practical protocol-specific feedback remain available for normal GUI and notification programming. SNMP Returned Value and TimeTicks Duration remain normally visible; Returned OID, Returned Data Type, Numeric Value Valid, and Numeric Value are advanced variables.

Build Identification is not exposed as a System Variable. The driver prints its version, DEV, RC, or RELEASE label, and Buttonwood Runtime version once at startup in TraceViewer.

Cycle Duration and network Response Time use System.GetTickCount for millisecond measurement. Timestamps, Last Degraded Time, and Degraded Duration use RTI-authoritative System.GetUTCTimeInSeconds.

Degraded Duration is reported in seconds, refreshes when probe feedback is published after a completed check, and returns to zero when the monitor is no longer Degraded.

Disable Verbose Trace after collecting the required evidence.

Developed & Supported By

Buttonwood Technologies, LLC

rti@buttonwoodtechnologies.com

https://www.buttonwoodtechnologies.com

Version History

v1.1 - Added read-only SNMPv1 and SNMPv2c single-OID GET monitoring with successful-response, numeric-comparison, inclusive-range, exact-value, and value-changed evaluation; returned-value and TimeTicks duration feedback; dependency, maintenance, composite, statistics, and event integration; large Counter64 precision protection; community-string log redaction; and updated composite Evaluation Basis behavior.

v1.0 - Initial release.

Product Specific Warning

This driver reports network and service observations from the RTI processor's perspective. A successful probe does not prove that an entire device, application, Internet service, security control, or customer workflow is healthy, and a failed probe can result from transient congestion, filtering, maintenance, name-resolution failure, or an intentionally disabled service. Do not use this driver as the sole monitor for life-safety, security, regulatory, contractual service-level, or emergency-response obligations. The dealer must validate every target, timeout, failure threshold, and notification path and provide an independent method to confirm consequential outages.

Third-Party Driver Notice and Disclaimer

This driver is independently developed by Buttonwood Technologies, LLC and is not developed, endorsed, supported, or certified by the manufacturers or service providers with which it interoperates, unless expressly stated otherwise. The driver is provided “AS IS” and “WITH ALL FAULTS,” without warranties of any kind, express or implied, including warranties of merchantability, fitness for a particular purpose, and noninfringement. To the maximum extent permitted by applicable law, Buttonwood Technologies, LLC shall not be liable for indirect, incidental, special, consequential, exemplary, or punitive damages, loss of data, loss of use, service interruption, or lost profits arising from installation or use of the driver. Nothing in this notice excludes or limits liability that cannot lawfully be excluded or limited.