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._tcpservice - 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:
goodmoderateslightlyUnhealthyunhealthyveryUnhealthyhazardous
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:
- Open Add device.
- Start the normal hub-based discovery flow / scan nearby.
- Wait for the AirLink to be discovered.
- 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:
didnametslsiddata_structure_typetemphumpm_1_lastpm_2p5_lastpm_10_lastpm_1pm_2p5pm_10pm_2p5_nowcastpm_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
-
AirLink Local API
Introduction | AirLink Local API -
Davis AirLink product information
Davis Instruments AirLink Air Quality Monitor -
WeatherLink Developer Portal
https://weatherlink.github.io/
SmartThings documentation
-
SmartThings LAN Edge Device Driver Development Guide
LAN Edge Device Driver Development Guide | Developer Documentation | SmartThings -
SmartThings mDNS Service Discovery documentation
mDNS Service Discovery -
SmartThings Edge Driver Components and Structure
Driver Components and Structure | Developer Documentation | SmartThings -
SmartThings Production Capabilities Reference
Production Capabilities | Developer Documentation | SmartThings
SmartThings Community
- Original request thread: “Edge Driver for Davis AirLink?”
Edge Driver for Davis AirLink?
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.




