MeshCore 1.18 Adds Sensor Telemetry: What the Update Enables

MeshCore 1.18 adds a more useful path from a remote sensor to the person or application watching it: permitted clients can subscribe to telemetry changes, and companion firmware can pass those pushed responses to a connected application. The important change is how measurements can be delivered, not a promise that every MeshCore radio now contains environmental sensors.

Released on 15 October 2026, version 1.18 also introduces an extensible Companion CLI and expands combined BLE/Wi-Fi support on selected hardware. For a practical project, treat sensing, radio delivery, companion firmware and application display as separate parts of the system. An update to one part does not automatically complete the others.

Telemetry existed before this update

It is misleading to read “adds sensor telemetry” as meaning that MeshCore had no telemetry beforehand. Existing request-and-response mechanisms could retrieve information. The release adds sensor-node subscription and push behaviour, together with companion handling of those responses.

Polling asks for a reading repeatedly. A subscription instead tells a sensor node what changes interest the recipient and allows the node to send relevant updates. The difference matters when a measurement changes infrequently, but you still want timely notification when it does.

For example, a proposed enclosure-temperature monitor might care about a meaningful rise rather than every tiny fluctuation. That is an application design choice. The update does not specify a universal alarm threshold, guarantee delivery by a deadline or turn a hobby sensor into a certified protection system.

Understand the complete telemetry path

A companion firmware release is not the same thing as a ready-made sensor firmware image for every supported board. Likewise, the presence of a sensor on a development board does not establish that the selected build reads it. Check the actual firmware target and sensor implementation before ordering hardware.

Subscriptions include boundaries, not just an on switch

The sensor changes introduce subscribe and unsubscribe requests. The documented design requires a permitted client, a resolvable regional scope, an expiry period and minimum changes for the telemetry channels being monitored. Those conditions are important parts of the feature, not incidental implementation details.

The threshold description is encoded using LPP-formatted data. For an application developer, that means channel identifiers, data types and values must agree between the client and sensor. A temperature value cannot safely be interpreted as humidity merely because both arrive as numbers.

Subscriptions expire and need renewal. Do not design a dashboard that assumes a successful subscription on installation day lasts indefinitely. Record renewal attempts and responses, and show a distinct state when the subscription is no longer known to be active.

Unsubscribing is also useful. Stop requesting updates that a client no longer uses. For a shared mesh, unnecessary subscriptions consume queue capacity, radio airtime and battery energy even when a phone's screen is closed.

Change-driven updates need freshness information

If nothing crosses the requested threshold, silence may be correct behaviour. The same silence can also mean a flat battery, a failed sensor, an expired subscription or a broken path. A usable monitoring application must distinguish a stable reading from an unobserved system.

Store at least the measurement value, channel, unit and time of reception. Where the payload provides a measurement timestamp, retain that separately. Display the age of the last accepted reading, and define an application-level check for overdue data instead of treating every missing update as “no change.”

Periodic health checks may still be appropriate. Their interval should follow the task and mesh capacity. Push telemetry and polling can complement each other: one reports significant changes, while another verifies that the remote equipment is still reachable.

Do not call MCU temperature the outside air temperature without evidence. A processor's thermal state, an enclosure reading and a properly exposed environmental probe are different measurements. Label them accurately and validate the sensor installation against the quantity you want to monitor.

Plan airtime before scaling the sensor count

As an illustrative comparison, three nodes polled once per minute generate 180 requests and up to 180 replies per hour before retries or relay traffic. A change-driven design may reduce that workload when measurements are stable, but it can also become busy if thresholds are too small or many values change together.

Those are message-count calculations, not a MeshCore capacity benchmark. Packet length, spreading factor, bandwidth, path length, competing users and regional operating conditions determine the actual airtime. Multi-hop delivery and retransmission add further work.

Set thresholds above meaningless sensor jitter, while keeping them sensitive enough for the application. If your proposed threshold is 0.5 degrees, document that it is your chosen reporting threshold, not proof of 0.5-degree sensor accuracy. Test both slow drift and a sudden real change.

The Companion CLI makes hardware features easier to expose

Version 1.18 introduces a text-based Companion CLI so firmware can expose commands without allocating a new binary companion-protocol command for every hardware-specific function. The release notes identify MeshCore App 1.50.0 as adding a Command Line interface for this workflow.

That helps development and configuration, but it does not mean every sensor subscription can be created by typing a command copied from an early development commit. The actual telemetry subscription payload and the current client implementation remain the authority. Use a supported application or deliberately implemented client rather than inventing a CLI syntax.

The release also adds permission-controlled remote administration of companion nodes. Grant Remote CLI permission carefully: an authorised contact can change operational settings and reboot equipment. A monitoring-only contact does not automatically need administrative control.

BLE and Wi-Fi support remains board-specific

Combined BLE/Wi-Fi companion builds expand in 1.18, but only for selected devices with sufficient resources. The release explicitly describes hardware limits and notes that the combined builds do not currently include the normal USB connection method, because USB is used for serial logging.

Do not infer combined connectivity from the ESP32 name alone. Check the exact release asset and its connection mode. A board can physically contain both radios while the selected firmware exposes only one client interface.

This distinction matters for commissioning. If a deployment plan depends on USB access after installation, test that exact path before sealing the enclosure. Keep a documented recovery method that does not depend entirely on the same wireless connection being reconfigured.

Choose hardware from the firmware target outward

The release assets include T-Beam and T-Beam S3 Supreme companion targets, with variant-specific radio choices. Our LILYGO T-Beam Supreme can therefore be considered for a matching supported MeshCore role, subject to the exact assembly and build.

Our LILYGO LoRa32 V2.1 1.6.1 listing is another board family to assess against its corresponding target. Confirm the radio chip, frequency variant and revision. Neither product link promises a prepared sensor server or a particular external sensor in the package.

For an external sensor, specify its supply, interface voltage, address, connector and driver. Include enclosure placement, cable length and weather exposure. A compatible radio and a good antenna do not resolve an incorrectly powered sensor or two devices sharing a conflicting address.

A practical acceptance test for a small deployment

1. Read the sensor locally and confirm units and plausible values.
2. Verify an ordinary telemetry request before adding subscription behaviour.
3. Create a permitted subscription and record the accepted scope and expiry.
4. Change the measured condition by less than the threshold, then by more than it.
5. Confirm the companion and application receive and interpret the pushed response.
6. Test expiry, renewal, unsubscribe and loss of the radio path.
7. Repeat through the intended relay path and on battery power.

Save a small log of the actions and observations. If local readings are correct but the app is empty, investigate payload handling and subscriptions before replacing the sensor. If ordinary messages also fail, return to radio band, modem settings, antenna and path checks.

Frequently asked questions

Does every upgraded radio gain environmental sensing?

No. Measurements require fitted sensors, suitable wiring and firmware support.

Is polling obsolete?

No. Polling can still retrieve values or verify health. Subscriptions provide another delivery method with different behaviour.

Will telemetry appear in every companion app?

Not automatically. The application must understand and display the pushed payloads supported by the firmware.

Does a subscription last forever?

No. Expiry and renewal are part of the documented mechanism.

Can MeshCore telemetry be read directly by Meshtastic nodes?

Do not assume interoperability. They are different network and software ecosystems, even when they use similar LoRa hardware.

Read our Meshtastic and MeshCore comparison before changing an established network. Use the SDRstore quote process to specify radio variants, node roles and sensor requirements as separate line items.