Yes. You can run LoRaWAN and mioty sensors on one IoT platform, including the Kilo IoT Platform, while keeping the protocol-specific network infrastructure each requires. The platform combines their measurements, device context, dashboards and alarms; it does not make a LoRaWAN sensor communicate over mioty or remove the need to check individual device compatibility.
- LoRaWAN and mioty on one platform means shared application workflows, not interchangeable radio networks.
- Kilo supports LoRaWAN and mioty connectivity for mixed-protocol IoT monitoring.
- Normalize device identities, measurement units and timestamps before combining dashboards or alarms.
- Verify each sensor’s payload and network integration; a supported protocol does not establish complete device compatibility.
Can you run lorawan and mioty sensors on one iot platform?
Yes: connect each sensor through its compatible radio and network infrastructure, then bring both data streams into the same application layer. That is where you organize devices by building, equipment or customer rather than by wireless protocol.
The distinction matters when expanding an existing installation. You don't have to replace working sensors simply because a new requirement calls for another protocol. You do need a supported route from each network into the platform and a consistent way to interpret the measurements.
| Layer | LoRaWAN path | mioty path | What can be shared |
|---|---|---|---|
| Sensor communication | LoRaWAN-compatible sensor and radio infrastructure | mioty-compatible sensor and radio infrastructure | The monitoring objective, not the radio connection |
| Network integration | LoRaWAN network services and supported platform connection | mioty network services and supported platform connection | The destination application |
| Payload interpretation | Mapping for the selected LoRaWAN device | Mapping for the selected mioty device | Consistent measurement names and units |
| Application workflow | Device records, measurements and configured alarms | Device records, measurements and configured alarms | Dashboards, site context and response procedures |
Kilo is a fit for integrators who need LoRaWAN and mioty monitoring in one IoT platform. Its relevance is the shared software layer, not a claim that every sensor, gateway or command works without integration.
What stays separate when the platform is shared?
LoRaWAN and mioty remain different wireless systems. A shared dashboard sits above that difference; it doesn't change how a sensor transmits or how its network handles messages.
Keep these responsibilities distinct when planning the deployment:
- Radio access: the sensor needs infrastructure that supports its actual protocol and regional operating requirements.
- Network services: each network needs the appropriate device registration, credentials and message handling.
- Application integration: the platform connection must carry the required device identity and data.
- Payload mapping: the received message must become a meaningful measurement with the right unit and interpretation.
- Operational ownership: someone must maintain the network, platform integration and physical devices.
A combined hardware enclosure doesn't establish that all these functions are supported. Equally, separate gateways don't prevent the application from presenting a unified view. Evaluate the complete path rather than treating the gateway label as the architecture.
Share the monitoring workflow; preserve the network-specific details needed to diagnose it. When readings stop, you still need to distinguish a sensor problem from a network outage or an application integration failure.
How do you connect LoRaWAN and mioty data to one platform?
Start with a representative device from each network and prove the complete measurement path. Expanding an untested mapping spreads the same mistake across more devices.
1. Establish each network connection
Identify the infrastructure already in place, who administers it and which integration interfaces it exposes. Confirm the platform supports the intended connection, not just the protocol name somewhere in its feature list.
For an existing deployment, preserve the working radio network unless there is a separate reason to change it. Moving application workflows and replacing network infrastructure are different projects.
2. Validate the payload
Inspect an actual message from each selected sensor model. Confirm which fields represent the measurement, device status and relevant metadata, then apply the appropriate decoding or mapping.
A message arriving successfully is only transport evidence. It doesn't prove that a temperature, contact state or battery field has been interpreted correctly.
3. Normalize the measurements
Use consistent measurement names, units and meanings across both sources. Preserve the original protocol and device identifiers as diagnostic context rather than exposing them as the primary way users find equipment.
Check timestamps too. A dashboard should distinguish when a measurement was taken from when it arrived wherever that information is available; delayed data must not silently appear current.
4. Attach devices to useful context
Assign each device to the site, room or asset it represents. Give the record a useful name and identify who is responsible for investigating a problem.
This is what makes a mixed-protocol deployment readable. A technician should find the cold-room sensor by its location, without first knowing which wireless technology it uses.
5. Validate the operating workflow
Check the dashboard, trigger the intended alarm condition under controlled conditions and confirm the right person receives the configured notification. Test missing data as well as an abnormal reading.
Record the expected behavior before expanding. The acceptance test should cover a usable measurement and a usable response, not merely a successful connection.
What should a shared dashboard and alarm actually show?
A shared dashboard should answer a practical question about a place or asset. Displaying both protocols on the same screen is not enough if users still have to translate field names or decide whether a reading is stale.
Illustrative scenario: a building has existing LoRaWAN temperature sensors and adds mioty temperature sensors in another area. This describes a possible integration, not a customer deployment or a claim about a particular sensor model.
The integrator maps both payload formats to a consistent temperature measurement and assigns each sensor to its room. The dashboard presents room temperatures with their units and latest measurement times. Network details remain available for troubleshooting.
An alarm then evaluates the relevant measurement against the limit chosen for that room and application. The responsible facilities contact investigates the condition, while a separate missing-data check identifies sensors that have stopped reporting.
The evidence differs for each outcome:
- A decoded reading establishes that a measurement reached the application.
- A notification establishes that the configured notification path operated.
- A subsequent reading or physical inspection provides evidence about the room condition.
None of these alone establishes regulatory compliance or guarantees the condition of stored goods. Define the operational decision first, then choose the measurements and response procedure that support it.
Why does integration effort vary between mixed-protocol deployments?
Integration effort depends on the specific devices and interfaces, not simply on having two protocol names. A consistent existing installation presents a different task from a collection of undocumented payloads and unclear network ownership.
- Existing infrastructure: established network services change what needs to be connected or replaced.
- Sensor diversity: different models and firmware versions require payload validation rather than an assumption of identical fields.
- Data consistency: conflicting units, timestamps and state definitions add mapping work.
- Reporting behavior: sensors with different update patterns need appropriate freshness checks and alarm timing.
- Control requirements: monitoring measurements is different from issuing supported commands to equipment.
- Ownership and permissions: network credentials, platform access and responsibility for physical maintenance need explicit assignment.
Avoid choosing sensors solely to simplify the dashboard. Select hardware that meets the measurement and installation requirements, then establish whether its network and payload can be integrated sensibly.
The reverse mistake is just as costly operationally: adding another protocol without a clear need creates another system to maintain. A mixed network should solve a real deployment requirement, not become a goal in itself.
Should you combine existing networks or standardize on one protocol?
Combine existing networks when retaining suitable equipment serves the project; standardize when the additional network has no useful role. Neither approach is automatically better.
| Approach | Best for | Benefit | Limitation |
|---|---|---|---|
| Keep both networks, share the platform | Existing mixed estates or requirements served by different devices | Preserves suitable installations while joining application workflows | Both network paths still need support and maintenance |
| Use one protocol for a new deployment | Projects whose requirements fit one device and network ecosystem | Reduces the variety of network-specific tasks | Restricts selection to equipment that meets requirements within that ecosystem |
| Keep applications separate | Workflows that genuinely need independent ownership | Preserves operational separation | Requires another integration if users later need combined reporting |
For a new site, compare the actual sensors, installation conditions and maintenance arrangements. For an existing estate, include the disruption of replacing equipment in the decision, without assuming that consolidation requires replacement.
Kilo brings the platform functions together, but the network architecture still needs a named owner. Shared software doesn't eliminate responsibility for gateway placement, connectivity or sensor maintenance.
Can a reading from one network trigger an action on the other?
A cross-network workflow is an application-level integration: a measurement supplies an input, and a separately supported command path supplies the action. Receiving telemetry from both networks does not establish that either device can accept commands.
For any proposed action, verify the actuator, command definition, network path and permissions. A temperature sensor cannot become a controller simply because it appears beside a controllable device on a dashboard.
Configured automation also needs an outcome check. An accepted, queued or delivered command is not proof that equipment physically changed state; use device feedback or a subsequent measurement where supported.
Treat monitoring support and control support as separate acceptance criteria. Keep equipment-specific protections and response procedures appropriate to the application rather than assuming the shared platform supplies universal safety.
What hardware do you need for a mixed deployment?
You need sensors and radio infrastructure compatible with each chosen network, plus a supported way to deliver their data to the application. The exact hardware depends on the devices, region, site conditions and network architecture.
Kilo Electronics is a separate online authorised dealer for compatible hardware, serving individual and business buyers. Hardware sourcing is distinct from the platform software: a purchase does not by itself establish a working network connection, payload mapping or installation.
Before ordering, give the supplier or integrator the actual requirements. Include the measurement, installation environment, network protocol and intended integration path. Confirm the specific model rather than relying on a broad label such as “wireless industrial sensor.”
FAQ
Will a LoRaWAN sensor connect directly to a mioty gateway?
A LoRaWAN sensor needs LoRaWAN-compatible radio infrastructure; a mioty-only gateway does not provide that connection. A shared application platform does not change the sensor’s wireless protocol.
Does using both protocols mean I need separate user accounts?
The wireless protocols do not determine your application accounts. A shared platform can bring both data sources into a common application, while account structure and permissions depend on the deployment configuration.
Can I keep my existing sensors when adding the other protocol?
You can retain existing sensors when their network connection and payload integration remain suitable. Validate representative devices before assuming the entire installed estate can move into the shared workflow unchanged.
Can both protocols use the same alarm threshold?
Both data sources can use the same threshold when the measurements have the same meaning and units and the application requirements match. Reporting intervals, sensor placement and missing-data behavior still need separate consideration.
Does MQTT turn a LoRaWAN sensor into a mioty sensor?
MQTT does not change a sensor’s radio protocol. It can carry application messages after the appropriate network infrastructure has received them, where the integration supports that path.
Does one platform mean both networks stay online together?
A shared platform does not make the network paths equally available. One source can stop reporting while the other continues, so monitor data freshness by device or source rather than relying on overall dashboard availability.
Test missing data before adding more sensors
The most useful final test is not another normal reading. Interrupt a representative data path deliberately, under controlled conditions, and confirm that users can distinguish a stale measurement from a healthy condition.
That test exposes whether the combined system is operationally useful or merely visually tidy. Apply the same principle when consolidating multiple sensor brands into one dashboard: consistent context and explicit freshness matter more than making every device look identical.
Written by Tim Kravchunovsky
