Professional weather hardware. Open by design.
Build WeatherXM into your product, private IoT network or local automation system. Start with field-ready hardware, then keep control of the network, backend and firmware path your application needs.
Build your solution, not your weather station.
WeatherXM takes care of the physical layer: weather sensing, enclosure, power, radio hardware, manufacturing and a reference software path. You decide what sits above it.
Built for system integrators · product companies · LoRaWAN operators · energy and infrastructure teams · researchers · open-source developers.
Three Open paths. One job: fit into your architecture.
Choose by connectivity first. The exact firmware, source and flashing capabilities are tracked per model and release rather than implied by the Open label.
Local and private-backend weather.
For sites with Wi-Fi where local access or a customer-controlled backend matters more than participation in the WeatherXM Network.
- • Local HTTP access on supported gateway firmware
- • Independent backend path for Open operation
- • Model-specific firmware and flashing releases
A weather station for your LoRaWAN network.
For integrators and network operators that want WeatherXM hardware on compatible third-party or private LoRaWAN infrastructure.
- • Customer-controlled LoRaWAN credentials
- • TTN / The Things Stack, ChirpStack and compatible networks
- • No requirement to make WeatherXM Cloud the application layer
Independent weather where infrastructure is sparse.
Mesh-native weather hardware for local and remote deployments, with local services and the D2 publication program leading firmware, design and integration releases.
- • Local LoRa mesh between field devices and gateway
- • Local REST / MQTT path on supported gateway software
- • Source and design releases tracked by the D2 campaign
H2-LEO / Lacuna: testing weather beyond terrestrial coverage.
WeatherXM is evaluating an H2-based direct-to-satellite path with Lacuna Space for remote deployments where terrestrial LoRaWAN or cellular backhaul is unavailable. This is a pilot, not a generally shipping retail product.
The pilot is a practical example of why an open connectivity path matters: the sensing hardware can be adapted to a different network without redesigning the weather station from scratch.
Your network. Your backend. Your firmware path. Your product.
Open is useful when it removes real integration constraints. These are the four freedoms that matter commercially.
Use infrastructure you control.
Choose supported private or third-party connectivity rather than making WeatherXM Network participation mandatory.
Keep your application architecture yours.
Use supported local interfaces or independent backend paths so your solution does not depend on a separate WeatherXM dashboard.
Use the reference path or replace it.
Open Editions are the route for replaceable firmware and documented recovery, with public source and flashing tooling released model by model.
Make it part of the solution you sell.
Build your own workflows, service and customer experience above the hardware instead of inheriting ours.
Open when you need it. Finished when you don't.
WeatherXM Open is designed to sit between a DIY hardware project and a closed consumer weather station: a finished field product that can still become part of somebody else's system.
| Capability | DIY hardware | Consumer station | WeatherXM Open | Traditional industrial |
|---|---|---|---|---|
| Outdoor-ready product | Build it | Usually | Yes | Yes |
| Production repeatability | Limited | Yes | Yes | Yes |
| Your backend / application | Yes | Limited | Yes | Usually |
| Your network | Yes | Limited | Model-specific | Usually |
| Replaceable firmware path | Yes | Rarely | Open Edition path | Varies |
| Fast path to field deployment | No | Yes | Yes | Yes |
Inspect the integration path before you design around it.
“Open” is not a blanket claim that every firmware and design file is already public. This matrix separates operating capability from source-publication status. Product pages and repositories remain the source of truth as releases land.
| Capability | D1 Open | H2 Open | D2 Open |
|---|---|---|---|
| Independent operating path | Private backend / local path | Third-party or private LoRaWAN | Local-first mesh |
| Local device access | HTTP on supported gateway firmware | BLE diagnostics | REST / MQTT on supported gateway software |
| Customer network credentials | Backend-specific | Yes | Mesh / gateway configuration |
| Replaceable firmware tooling | Planned / check current release | Planned / check current release | Tracked by D2 releases |
| Public station firmware source | Published per release | Published per release | Tracked by D2 campaign |
| Hardware design files | Check model release | Check model release | Planned publication program |
Evaluate one unit before you design around it.
The goal is a low-friction engineering funnel: public documentation and examples, an evaluation unit you can test, then integration and volume support once the architecture is proven.
Does Open mean open-source hardware?
Not automatically. We distinguish independent operation, documented interfaces, replaceable firmware, public source and hardware design files. Exact licenses and files are stated per model and release.
Do I need Open to access my own station?
No. Supported local access to your own observations is not intended to be an Open-edition surcharge. Open is for independent operation, customer-controlled infrastructure and replaceable firmware paths.
Use our hardware. Keep your architecture.
Start with a field-ready station instead of a hardware project, then connect it to the network, backend and product your customer already needs.