[ST Edge] Davis AirLink Air Quality Sensor LAN Driver

This driver started with the request in the SmartThings Community thread Edge Driver for Davis AirLink?.

The Davis AirLink turned out to be a very suitable device for a SmartThings LAN Edge driver. It exposes a documented local HTTP API, advertises itself through mDNS, and provides a compact JSON payload with current particulate matter, temperature and humidity readings. That makes it possible to integrate the device locally with SmartThings without using the WeatherLink cloud API, without account credentials and without API keys.


Device overview

The Davis AirLink is a Wi-Fi air quality sensor from Davis Instruments / WeatherLink. It is intended for indoor use or protected outdoor installations and measures particulate matter and basic environmental conditions.

The device reports:

  • PM1.0
  • PM2.5
  • PM10
  • temperature
  • relative humidity

The AirLink is normally used together with WeatherLink, where Davis provides dashboards, historical data and air-quality views. For SmartThings integration, the important part is the local API. The AirLink exposes current readings on the local network through:

GET http://<airlink-ip-address>/v1/current_conditions

The endpoint returns JSON and does not require authentication on the local network.

The driver has been developed for the Davis AirLink family, including the following variants:

Model Description
7210 Davis AirLink
7210EU EU variant
7210UK UK variant
7210USB USB-powered variant

The driver relies on the documented local AirLink API and the _airlink._tcp.local. mDNS service. It should therefore work with devices that expose the same local API and discovery behavior.


Driver overview

This is a SmartThings Edge LAN driver. It runs locally on the SmartThings hub and communicates directly with the AirLink on the local network.

The driver handles:

  • mDNS discovery using the AirLink _airlink._tcp service
  • validation of discovered devices through /v1/current_conditions
  • stable SmartThings device identity based on the Davis device serial number (did)
  • local polling of the AirLink API
  • temperature and humidity reporting
  • PM1.0, PM2.5 and PM10 reporting
  • particulate health concern calculation
  • manual refresh
  • hub reboot recovery
  • rediscovery after temporary connection failures
  • optional static host/IP override

The implementation uses standard SmartThings capabilities only. No custom capabilities are required for the current release.


Exposed SmartThings capabilities

The driver exposes the AirLink through the following standard SmartThings capabilities:

temperatureMeasurement
relativeHumidityMeasurement
veryFineDustSensor
fineDustSensor
dustSensor
veryFineDustHealthConcern
fineDustHealthConcern
dustHealthConcern
airQualityHealthConcern
refresh

Sensor values

The SmartThings device card displays:

AirLink data SmartThings capability
Temperature temperatureMeasurement.temperature
Relative humidity relativeHumidityMeasurement.humidity
PM1.0 veryFineDustSensor.veryFineDustLevel
PM2.5 fineDustSensor.fineDustLevel
PM10 dustSensor.dustLevel

Particulate values are shown in µg/m³.

The driver prefers the AirLink’s one-minute PM average values where available and falls back to the most recent valid readings if needed. This is useful after device startup or restart, when some rolling average fields may not yet be populated.

Health concern states

The driver also exposes health concern states:

SmartThings capability Meaning
veryFineDustHealthConcern PM1.0 health category
fineDustHealthConcern PM2.5 health category
dustHealthConcern PM10 health category
airQualityHealthConcern Overall particulate health category

Possible values are the standard SmartThings health concern states, such as:

  • good
  • moderate
  • slightlyUnhealthy
  • unhealthy
  • veryUnhealthy
  • hazardous

The AirLink local API does not return a local AQI value. Davis explains that AQI calculation depends on the selected regional/national AQI model and may require additional context. For that reason, the driver does not expose a numeric airQualitySensor.airQuality value. Instead, it calculates SmartThings health concern categories from the particulate readings.

This keeps the integration explicit: the raw PM values come from the AirLink, while the health concern categories are derived by the driver.


Driver settings

The driver includes the following settings.

Poll interval

Default: 60 seconds

The AirLink updates particulate matter values approximately once per minute. The default polling interval therefore matches the device’s natural update rhythm and avoids unnecessary requests to the embedded web server.

Static host / IP override

Optional.

Normally the driver discovers the AirLink through mDNS. If mDNS is unreliable on a particular network, a static host or IP address can be entered manually.

Accepted examples:

192.168.1.123
airlink-100008.local
192.168.1.123:80
http://192.168.1.123

This is mainly intended as a fallback for networks where mDNS/Bonjour/Zeroconf is filtered, not forwarded correctly, or otherwise unreliable.

Health concern basis

The driver can prefer NowCast-style AirLink PM fields where available, or use the one-minute PM values.

The default is intended to provide stable health concern states while still falling back safely when longer rolling windows are not available.

Debug logging

Debug logging is disabled by default.

When enabled, the driver logs additional information about discovery, polling, parsed values and health concern calculation. This is useful for testing and troubleshooting but should normally remain off in daily use.


Installation

A SmartThings hub with Edge driver support is required.

1. Enroll the hub in the driver channel

Open the driver channel invitation link and enroll the SmartThings hub.

Then install the driver from the channel. The driver name may appear as something similar to:

Davis AirLink LAN

2. Make sure the AirLink is already configured

The AirLink must already be connected to the local Wi-Fi network through the normal WeatherLink setup process.

The SmartThings hub and the AirLink must be able to reach each other on the local network. mDNS/Bonjour/Zeroconf traffic should not be blocked between them.

3. Add the device in the SmartThings app

In the SmartThings app:

  1. Open Add device.
  2. Start the normal hub-based discovery flow / scan nearby.
  3. Wait for the AirLink to be discovered.
  4. Add the discovered device.

After installation, the device should start reporting values within approximately one minute.

4. Verify operation

After pairing, check that the following values are shown:

  • temperature
  • humidity
  • PM10
  • PM2.5
  • PM1.0
  • dust / fine dust / very fine dust health concern states
  • overall air quality health concern state

Manual refresh should trigger an immediate poll of the local API.


Tested behavior

The driver has been tested with real Davis AirLink hardware.

Confirmed working:

  • mDNS discovery
  • SmartThings device creation
  • local polling of /v1/current_conditions
  • minute-by-minute updates
  • manual refresh
  • hub reboot recovery
  • temperature reporting
  • humidity reporting
  • PM10 reporting
  • PM2.5 reporting
  • PM1.0 reporting
  • particulate health concern states

The tested device continued updating after a SmartThings hub reboot.


Technical details

Discovery

The driver uses SmartThings Edge mDNS discovery for:

_airlink._tcp.local.

The official AirLink documentation describes the hostname pattern as:

airlink-<last-six-digits>.local

During discovery, the driver validates candidates by requesting /v1/current_conditions and reading the Davis device serial number from the did field.

Device Network ID

The SmartThings Device Network ID is based on the Davis serial number rather than the current IP address.

Conceptually:

davis-airlink:<did>

This avoids duplicate SmartThings devices when the AirLink receives a different DHCP address.

Local API handling

The driver polls:

GET /v1/current_conditions

The response contains a top-level data object and an error object. The AirLink readings are located inside data.conditions[0].

The current documented AirLink data structure is data_structure_type: 6. The driver also includes defensive fallback handling for older data_structure_type: 5 PM10 field names.

Parsed fields include, among others:

  • did
  • name
  • ts
  • lsid
  • data_structure_type
  • temp
  • hum
  • pm_1_last
  • pm_2p5_last
  • pm_10_last
  • pm_1
  • pm_2p5
  • pm_10
  • pm_2p5_nowcast
  • pm_10_nowcast
  • PM rolling averages
  • PM data completeness percentages
  • last_report_time

Not all parsed fields are exposed in the SmartThings UI. Several are retained internally or used for defensive fallback and diagnostics.

Polling model

The default polling interval is 60 seconds.

The driver performs one request at a time per device and avoids aggressive retry loops. If polling fails repeatedly, the driver can mark the device offline and later recover when communication succeeds again.

Recovery behavior

The driver is designed to handle:

  • SmartThings hub reboot
  • temporary HTTP failures
  • AirLink restart
  • AirLink IP address changes
  • incomplete PM rolling averages after AirLink restart
  • null or missing fields in the API response

If discovery fails on a particular network, the static host/IP override can be used as a fallback.

Why no custom capabilities?

The current release intentionally uses only standard SmartThings capabilities.

This keeps the device presentation clean, avoids additional presentation metadata and makes the integration easier to install and maintain. A future version could expose additional AirLink-specific diagnostic or rolling-average values through custom capabilities, but they are not required for normal SmartThings use.

Possible future additions could include:

  • PM2.5 NowCast
  • PM10 NowCast
  • 1-hour / 3-hour / 24-hour PM averages
  • PM data completeness percentages
  • last AirLink report timestamp
  • dew point
  • wet bulb
  • heat index

For the release version, the focus is reliable local integration and useful SmartThings automation values.


Notes and limitations

Local API only

The driver does not use the WeatherLink cloud API.

It does not require:

  • WeatherLink account credentials
  • WeatherLink API keys
  • WeatherLink cloud polling
  • WeatherLink subscriptions

No historical WeatherLink data

The driver exposes current local readings to SmartThings. Long-term charts, historical data and Davis-specific dashboards remain part of WeatherLink.

No numeric AQI capability

The local API does not provide AQI.

The driver exposes SmartThings health concern states derived from particulate readings, but does not expose a numeric AQI value as if it were supplied by the AirLink itself.

Network requirements

The SmartThings hub must be able to reach the AirLink locally.

Networks with client isolation, separated VLANs or blocked mDNS may require additional network configuration or use of the static host/IP override.


Sources

Davis / WeatherLink

SmartThings documentation

SmartThings Community


Closing note

The Davis AirLink is a good example of a device where a local SmartThings Edge driver makes sense. It already provides useful local measurements, and SmartThings can use those values for routines, automations and local context.

The goal of this driver is therefore straightforward: expose the AirLink’s current local air-quality data reliably in SmartThings, using standard capabilities, with minimal cloud dependency and without unnecessary device-specific complexity in the SmartThings app.

Fantastic work Andreas with this Edge driver. I appreciate you creating it so quickly for users like me who have the Davis AirLink device. The integration with SmartThings is incredibly helpful for users who need to keep track of outdoor air quality for members of their household who have asthma or other sensitivities.