IoT Integration Guides Step-by-step guides for integrating LoRa mesh with sensors, home automation, and asset tracking systems. Environmental Monitoring with Meshtastic Use Case Overview LoRa mesh networking enables remote environmental monitoring in locations without cellular coverage or WiFi infrastructure. A solar-powered Meshtastic node with an attached sensor can transmit temperature, humidity, air quality, soil moisture, and other telemetry data across the mesh to a gateway, which forwards it to a database or home automation system. Common applications include: Weather station on a remote property or off-grid cabin Soil moisture monitoring for irrigation management across a farm Air quality monitoring at a remote site or community location Freezer/cold storage temperature monitoring with alerts Supported Sensor Modules Meshtastic's Telemetry module supports a range of sensor types natively: BME280 / BME680 - temperature, relative humidity, barometric pressure; BME680 also provides a gas resistance reading useful for air quality estimates INA219 / INA260 - DC voltage and current monitoring; useful for monitoring solar panel output, battery charge state, or load current MQ-series gas sensors (MQ-2, MQ-135, etc.) - analog output sensors readable via ADC; useful for smoke, CO, or general air quality detection Hardware Setup: BME280 Wiring The BME280 is the most commonly used environmental sensor with Meshtastic. It connects via I2C: VCC → 3.3V GND → GND SDA → GPIO21 (T-Beam, Heltec V2/V3 - verify your specific board pinout) SCL → GPIO22 (T-Beam, Heltec V2/V3 - verify your specific board pinout) After wiring, enable the sensor in the Meshtastic app or CLI: navigate to Telemetry → Environment and enable the module. The node will begin broadcasting environment telemetry on the mesh. Reading Sensor Data Telemetry data is accessible through multiple paths: Meshtastic app (phone): telemetry appears in the node info panel when you tap on a node - shows last-received temperature, humidity, pressure, and other available metrics MQTT gateway: a Meshtastic node with WiFi or a gateway device forwards telemetry packets as JSON to an MQTT broker. This enables integration with databases and dashboards. Sample MQTT Telemetry JSON Structure When a telemetry packet is forwarded via MQTT, the JSON payload contains: from - the node number (integer) of the sending device to - the destination node number (usually the broadcast address) decoded.telemetry.environmentMetrics - the environment data object, containing: temperature - degrees Celsius (float) relativeHumidity - percentage (float, 0 - 100) barometricPressure - hPa (float) gasResistance - ohms (float; BME680 only, correlates with VOC concentration) This JSON structure can be consumed directly by InfluxDB (via Telegraf or a Node-RED flow), Home Assistant MQTT sensors, or any custom application that subscribes to the MQTT topic. Integration Targets InfluxDB + Grafana: store time-series telemetry and visualize on dashboards; well-suited for long-term environmental data logging Home Assistant: configure MQTT sensors using the telemetry JSON structure; trigger automations on temperature or humidity thresholds Node-RED: flexible pipeline for transforming, filtering, and routing telemetry data to multiple destinations simultaneously Deployment Considerations Enclosure: use a weatherproof IP65+ enclosure for outdoor deployments; mount the sensor in a vented radiation shield for accurate temperature readings - direct sunlight on the enclosure will give artificially high temperature readings Solar power: a small 1 - 5W solar panel with a LiPo battery and a TP4056-based charge controller is sufficient for most sensor nodes; the low duty cycle of LoRa transmission makes solar viable even in partial sun Sensor venting: drill small holes or use a membrane vent in the enclosure so humidity and temperature readings reflect ambient conditions, not the trapped air inside the box Power Impact of Environmental Sensors The BME280 draws approximately 1 - 3 mA average, which is negligible relative to the LoRa radio and microcontroller. At a 10-minute telemetry interval on a T-Beam or similar device, sensor power consumption has minimal impact on overall battery life. The dominant power draw remains the ESP32 or nRF52840 idle current and LoRa transmit bursts. Home Assistant and Node-RED Integration Integration Architecture The standard integration path from a Meshtastic mesh to Home Assistant or Node-RED is: Meshtastic MQTT gateway - a mesh node with WiFi (or a dedicated gateway device) publishes all received mesh packets to an MQTT broker as JSON MQTT broker (Mosquitto) - runs on the local network (often on the same machine as Home Assistant); receives all packets from the gateway Home Assistant or Node-RED - subscribes to the MQTT topics and processes the incoming data Home Assistant Setup via HACS The Meshtastic integration for Home Assistant is available through HACS (Home Assistant Community Store): Install HACS in Home Assistant if not already present Search for "Meshtastic" in HACS integrations and install Add the integration in Home Assistant Settings → Integrations → Add Integration → Meshtastic Configure with your MQTT broker address, port, and topic prefix (default: msh ) Nodes appear as Home Assistant devices with individual sensors for position, battery level, and telemetry values What You Can Do in Home Assistant Geofencing automations: trigger actions when a node's GPS position enters or leaves a defined zone - useful for "person arriving home" automations using a mesh device as a low-cost tracker Telemetry alerts: send a notification when a remote temperature sensor exceeds a threshold (e.g., greenhouse overheating, freezer failure) Battery low notifications: alert when a field node's battery level drops below a set percentage Dashboard visualization: display node positions on a map card alongside other Home Assistant entities Node-RED Alternative Node-RED provides more flexibility for complex processing pipelines than the Home Assistant integration: Use the node-red-contrib-meshtastic node for direct serial/TCP connection to a Meshtastic device, or process raw MQTT JSON from the broker with standard MQTT nodes Build custom routing logic: filter messages by node ID, apply transformations, forward to multiple destinations simultaneously Suitable for multi-destination forwarding - e.g., send alerts to both Home Assistant and a Telegram bot at the same time Example Node-RED Flow A typical data logging flow: MQTT In node - subscribes to the Meshtastic MQTT topic JSON parse node - parses the raw MQTT payload Switch node - filters for a specific node ID (e.g., only process packets from your sensor node) Function node - extracts the desired telemetry fields and formats a row Google Sheets node - appends the row to a Google Sheet for long-term logging MeshCore and Home Assistant MeshCore does not have a native MQTT gateway equivalent to Meshtastic's built-in WiFi gateway. Integration options include: Serial/USB bridge script: connect a MeshCore node to a Raspberry Pi or other Linux machine via USB, use the MeshCore Python library to read incoming data, and publish it to an MQTT broker with a custom script Custom Home Assistant integration: a community-developed integration using the Python library can expose MeshCore nodes as HA devices This approach requires more custom development compared to the plug-and-play Meshtastic HACS integration Privacy Considerations Position and telemetry data from your nodes is visible to anyone who has access to your mesh channel. By default, Meshtastic devices transmit on the public LongFast channel, meaning nearby nodes operated by others can receive your telemetry. Configure a private channel with a unique name and PSK for nodes you don't want public network participants to observe Consider whether you want GPS position data from home-based sensor nodes to be visible on public MQTT bridges (e.g., MQTT.meshdev.in) Disable MQTT uplink on nodes with sensitive data if you use the public broker Remote Asset Tracking Use Case Overview LoRa mesh networking provides a cost-effective solution for tracking assets in areas with no cellular coverage: vehicles, heavy equipment, livestock, shipping containers, or packages moving through rural or remote areas. Unlike cellular asset trackers that require ongoing SIM and data plan costs, LoRa-based trackers operate over your own mesh infrastructure. How It Works The asset carries a LoRa node configured to broadcast GPS position packets at regular intervals Any mesh node or gateway within range receives the position packet and propagates it through the mesh via multi-hop routing A gateway node with internet access (WiFi or cellular backhaul) forwards the position via MQTT to a server The server stores the position in a database and displays it on a web map or dashboard Meshtastic MQTT + Cloud Visualization Position packets forwarded via Meshtastic's MQTT gateway can be ingested by a variety of tools: Grafana map panel: InfluxDB stores the time-series position data; Grafana's Geomap panel displays asset trails and current positions Custom Leaflet application: a lightweight web app using the Leaflet.js mapping library can display live asset positions from a database backend Home Assistant: device tracker entities can be updated from MQTT position packets, integrating asset positions into your existing HA setup MeshCore Asset Tracking MeshCore advertisement packets include the sending node's GPS position. Repeaters that receive an advertisement log the contact - making it possible to reconstruct asset movement through a coverage area by analyzing which repeaters logged contact with a given node ID and at what time. This is useful for: Understanding which parts of a property or trail system an asset has visited Detecting when an asset enters or leaves a coverage zone Post-event reconstruction of movement without requiring a centralized database during the event Update Interval Trade-off Position update frequency involves a trade-off between tracking resolution, battery life, and mesh traffic: Every 1 minute: good resolution for fast-moving vehicles; significantly higher battery drain and adds substantial mesh traffic across the network Every 10 - 30 minutes: appropriate for most slow-moving assets (livestock, equipment); much better battery life Motion-triggered: the most power-efficient approach - configure the node to transmit on movement detected via accelerometer, and go silent when the asset is stationary. Ideal for parked equipment or containers that move infrequently. Hardware Options RAK4631 + RAK1910 GPS module: excellent for asset tracking - the RAK4631's nRF52840 has very low sleep current, and the modular WisBlock system allows GPS to be powered down when not sampling. Best-in-class for long-term battery-powered deployments. T-Echo: integrated GPS and ePaper screen for field checking the last known position; good for assets that someone will physically inspect periodically (e.g., a piece of equipment on a large property) T-Beam: has built-in GPS and is popular for vehicle tracking; higher power consumption than the RAK solution but easier to integrate with vehicle 12V power Coverage Considerations Asset tracking over LoRa mesh requires mesh coverage in the asset's operating area. Without a mesh node or gateway within range, the asset simply does not report until it re-enters coverage: For wide-area tracking across a large property, plan repeater placement to ensure continuous coverage of the operating area A gateway with cellular backhaul at the edge of coverage can ensure position data reaches a server even if the local mesh is isolated Assets that travel outside the mesh coverage area will have gaps in their track - store the last known position and timestamp so the system can show "last seen at X location at Y time" Regulatory and Privacy Considerations Transmitting GPS coordinates of people or assets has legal and ethical implications: Consent: ensure anyone being tracked (employees, family members) is aware of and consents to the tracking. In many jurisdictions, covert GPS tracking of individuals is illegal. Employees: employer tracking of company vehicles during work hours is generally permissible but varies by jurisdiction; consult applicable employment law Livestock and equipment: tracking your own property is generally straightforward; tracking assets on shared or public land may have additional considerations Channel access: as with all mesh data, position packets are visible to anyone with access to the same channel. Use a private channel with a unique PSK for asset tracking deployments to prevent third parties from observing your assets' movements.