Set Up EMS-ESP and Access It Remotely with Localtonet

What EMS-ESP does and how remote access fits

EMS-ESP is firmware for the Espressif ESP32 microcontroller. It communicates with compatible heating equipment over the EMS bus and presents supported information and controls through a browser-based interface. The project documents compatibility with EMS, EMS+, EMS2, EMS Plus, Logamatic EMS, Junkers 2-wire, and Heatronic 3 and 4 equipment.

Supported device categories include boilers, thermostats, heat pumps, mixing units, solar modules, connect modules, ventilation units, switches, and related components. Compatibility must still be checked for the exact model and bus arrangement. A manufacturer name by itself does not prove that every product from that manufacturer uses a compatible bus or exposes the same data.

A normal installation has three distinct layers. First, the heating equipment communicates over its EMS bus. Second, a suitable gateway containing an ESP32 and the necessary interface circuit runs EMS-ESP. Third, computers and other devices on the local network reach the EMS-ESP web interface. Localtonet adds a fourth layer by forwarding HTTP requests from a public HTTPS address to that verified local web service.

The tunnel does not replace the EMS gateway, install firmware, interpret the heating bus, or repair local connectivity. It only exposes the HTTP service that EMS-ESP already provides. This distinction is important because it gives you a clear order for installation and troubleshooting: establish bus communication, establish local browser access, and only then establish remote access.

Prerequisites, compatibility, and electrical boundaries

Start by identifying the exact boiler, thermostat, heat pump, controller, and other modules you intend to monitor. Compare those models and their control-bus family with the compatibility information on the official EMS-ESP website. Similar-looking systems can use different control buses, so do not choose hardware based only on the brand printed on the enclosure.

EMS-ESP requires more than a bare ESP32. The project states that a small additional circuit is required between the microcontroller and the EMS bus. Prebuilt gateway hardware from BBQKees Electronics is identified by the project as tested for use with EMS-ESP. If you use a different gateway, verify electrical compatibility and obtain wiring, flashing, and hardware support from that gateway’s manufacturer.

You also need normal local-network access. EMS-ESP must join a network that is reachable by the device that will run the Localtonet client. That client device must remain powered on and connected whenever remote access is required. It can be a supported computer or another supported device on the same reachable network, but this guide does not assume that the Localtonet client runs on the EMS-ESP microcontroller itself.

Check the official project material before installation

The EMS-ESP32 repository is the canonical source-code repository and links to the project’s installation, building, support, and troubleshooting material. The repository’s installation section directs users to the current Installation Guide. Use that route because the supported preparation and flashing procedure depends on the gateway and firmware packaging.

This article does not provide a universal flashing command, serial-device name, binary filename, default address, or default credential. Those values are not consistently established by the supplied project evidence, and guessing them could result in an incorrect installation. The self-contained workflow below tells you what must be completed and verified at each stage while leaving hardware-specific flashing operations to the instructions supplied for the actual gateway.

Be careful with firmware version labels

There is a current version-label discrepancy in the project’s public material. During this 2026 review, the EMS-ESP website displayed version 3.8.1 as stable, while the GitHub repository identified version 3.8.4 as the latest release. Because those two first-party pages were not synchronized, this article does not label either value as the definitive current stable version.

Before installing or updating, compare the version offered by the official installation workflow with the repository’s release page and release notes. If your gateway manufacturer supplies a managed or preinstalled image, also confirm which releases that hardware supports. Do not install a build solely because its numeric version appears higher.

Install, onboard, and configure EMS-ESP

EMS-ESP distinguishes installing released firmware from building the firmware from source. For a normal gateway deployment, use the installation route linked by the project and intended for your hardware. Building from source is an advanced development path documented separately in the repository and is not required merely to operate the web interface.

Some gateways may arrive with firmware or use a manufacturer-specific preparation process, while other supported hardware may require firmware installation. The evidence available for this revision does not establish one sequence of buttons or commands that is valid for every supported gateway. Follow the route for the exact device in front of you, then use the following onboarding sequence to complete the installation safely.

Once the web interface opens, record the complete local target as observed from your own network. That means the working hostname or IP address, the port if one is explicitly required, and whether the local browser uses HTTP or HTTPS. This tutorial uses an HTTP tunnel for the evidenced EMS-ESP browser service, but the local target values must come from the installed system.

Verify EMS-ESP locally before opening remote access

Do not create the tunnel immediately after the first successful page load. A useful local verification tests the same path that Localtonet will later use. Run the test from the computer or device on which you intend to install our client, not only from a phone or from the machine used during firmware setup.

Check the web service itself

Open the complete local address and sign in using the account you intend to retain. Navigate through the pages needed for remote monitoring or administration. Reload the page, sign out and back in, and confirm that the application remains responsive. If browser warnings, redirects, or connection failures appear locally, investigate them before adding another network layer.

Check the heating-system data

Confirm that expected devices appear and that temperatures, operating states, and other reported information are plausible. An accessible web page does not prove that the EMS bus connection is correct. Missing devices or implausible data usually point to compatibility, wiring, gateway, firmware, or EMS-ESP configuration rather than a remote-access problem.

Check the network path from the future client device

From the device that will run Localtonet, open exactly the same local address. This detects guest-network isolation, VLAN boundaries, local firewall rules, or name-resolution behavior that may differ between devices. If a hostname works on one machine but not another, test the discovered IP address and investigate local DNS rather than assuming the tunnel will repair name resolution.

Check behavior after a restart

Restart the gateway only through an appropriate documented procedure, then verify that it rejoins the network and returns to normal operation. Also check whether its IP address changed. A tunnel configured with an old address will stop reaching EMS-ESP even though both EMS-ESP and Localtonet remain operational.

Local verification is also your baseline for later troubleshooting. Save the working local target without publishing it, and note what a healthy page looks like. When a remote test fails, you can repeat the same local test to determine whether the problem begins inside EMS-ESP or in the tunnel path.

Expose the EMS-ESP web interface with Localtonet

Localtonet exposes the verified service without inbound router port forwarding, firewall changes, VPN setup, or a public IP address. Our client establishes an outbound connection to a Localtonet relay server. Requests arriving at the assigned public address travel through that connection to the EMS-ESP target on your private network.

Use an HTTP tunnel for this browser-based workflow. HTTP and File Server tunnels have Process Type choices of Random Sub Domain, Custom Sub Domain, or Custom Domain, all of which serve the configured content at a public HTTPS address. Availability of options can vary, so use only the choices displayed in your current dashboard and subscription.

The sequence below follows the documented Localtonet lifecycle. Creating the configuration is not enough. You must start the tunnel, and it remains available only while the selected client is connected and the tunnel is running.

The Localtonet HTTP tunnel documentation is the companion reference for the current dashboard workflow and available fields. If you choose a custom domain, check the current documentation for its DNS requirements rather than applying instructions written for another provider or an older interface.

Secure remote access to heating controls

A public URL changes the exposure of the EMS-ESP interface. The service is no longer reachable only by devices already inside your home network. Treat it as an administrative endpoint associated with physical equipment, even if you usually use it only for viewing temperatures or status.

Retain EMS-ESP authentication

Do not remove or bypass the EMS-ESP sign-in boundary for convenience. Use strong, unique credentials where supported by the installed version, and do not reuse Wi-Fi, router, email, or Localtonet account credentials. If multiple people require access, use the project’s multi-user capability rather than broadly sharing one administrative password where the installed version permits appropriate account separation.

Apply least privilege

Give access only to people who need it and only for as long as they need it. Review which heating controls are available through the account and interface you expose. Remote monitoring may carry less operational risk than giving every user the ability to change schedules, temperatures, or system settings.

Localtonet forwards the selected service. It does not redefine the permissions inside EMS-ESP. Authorization decisions within the application remain the responsibility of the EMS-ESP configuration and its users.

Expose only the required service

This workflow publishes the web interface only. Do not expose Telnet, MQTT, a development console, or other interfaces merely because they are available locally. Each additional service creates another path that must be configured, authenticated, maintained, and monitored.

Segment devices where practical

Home automation and IoT equipment can be placed on a dedicated network segment where practical, with explicit rules allowing only required communication. Segmentation must not block the Localtonet client from reaching the EMS-ESP target. Test the intended path after changing VLAN, guest-network, or local firewall rules.

Keep firmware maintained

EMS-ESP advertises automatic update capability, but update availability and behavior should be confirmed in the installed release and official documentation. Review release information before updating, preserve relevant configuration records, and verify local operation after the update before reopening remote access.

Because the website and GitHub release information were inconsistent during this review, do not rely on a single version label. Use the release notes, the version offered through the supported installation or update workflow, and any gateway-specific compatibility guidance together.

Stop the tunnel when it is not needed

A stopped tunnel removes the Localtonet public route to the local target. For occasional maintenance, start it shortly before the remote session and stop it afterward. Delete configurations that are no longer required, and keep the selected client device and its token under your control.

Updates, address changes, restarts, and routine operation

Remote access is a chain of services rather than a permanent property of the EMS-ESP gateway. EMS-ESP must be powered and connected, its web interface must be responding, the LAN path must be available, the Localtonet client must be connected, and the tunnel must be running. A failure at any one of those points makes the public URL unavailable.

Plan for local-address changes

A network may assign a different local IP address after a gateway, router, or DHCP service restarts. If the tunnel targets the old IP address, it will continue forwarding to that outdated destination. When local access stops working, check your router’s current device list or the gateway’s documented discovery method, then compare the result with the tunnel target.

If your network supports a reliable hostname or a managed address reservation, you may use the approach appropriate to your own network. This article does not prescribe router-specific reservation steps because those controls vary by router and are not Localtonet or EMS-ESP settings.

Understand client and gateway restarts

Restarting EMS-ESP temporarily removes the target service. Restarting the device that runs our client temporarily removes the outbound tunnel connection. After either restart, verify that the relevant device has rejoined the network. Then check local EMS-ESP access, client connectivity, tunnel state, and finally the public URL in that order.

Update without confusing firmware and tunnel failures

Before an EMS-ESP update, record the current working version, local target, and essential configuration. Stop the public tunnel during maintenance when remote access is unnecessary. Apply the update through the currently supported EMS-ESP workflow, allow the gateway to restart, and validate bus communication and local browser access before restarting the tunnel.

If the local interface works after the update but the public URL does not, investigate the Localtonet client and tunnel target. If the local interface itself no longer works, focus on EMS-ESP, its network connection, the gateway, and the update outcome before changing Localtonet.

Use a repeatable session checklist

Troubleshoot the complete connection path

Troubleshooting is faster when you work from the heating system outward. Do not begin by recreating the tunnel or changing several settings at once. Test each layer, preserve known-good values, and stop at the first failure.

EMS-ESP does not start or its interface never appears

Return to the installation path for the exact gateway. Confirm that the selected firmware is intended for that hardware and that the installation process completed successfully. Recheck first-run network onboarding and use the gateway’s documented discovery procedure. Avoid reflashing repeatedly with guessed binaries or settings.

The interface loads, but heating devices are missing

This is not a Localtonet problem. Confirm the exact equipment and bus compatibility, inspect the documented gateway connection, and review EMS-ESP configuration. If the gateway is not made by BBQKees, the project notes that hardware-specific support may need to come from its manufacturer.

The repository’s getting-support section directs users to the project’s community and support guidance. Reproduce the issue locally before requesting help, and redact network information, usernames, passwords, tokens, and public URLs from logs or screenshots.

EMS-ESP works on one local device but not the Localtonet host

Test the exact hostname or IP address and port from the Localtonet host. Guest Wi-Fi isolation, VLAN policy, local firewall rules, and hostname-resolution differences can block that path. Being connected to the same internet service does not guarantee that two devices can communicate directly.

The local IP address changed

Discover the gateway’s current address and open it locally. If it works, update the tunnel target to the verified address using the current dashboard workflow. Recheck any local hostname or address-reservation strategy separately. Do not assume that restarting the tunnel will redirect it automatically to a different target.

The tunnel exists, but the public URL is unavailable

Confirm that the selected Localtonet client is connected and that the tunnel has been started. Creating a tunnel does not start it. The endpoint is available only while the selected client is connected and the tunnel is running. If both conditions are satisfied, test EMS-ESP locally from the client device.

The public URL reaches the wrong page

Compare the tunnel target with the complete local address you verified. A wrong port may point to another local web service. A stale IP address may now belong to another device. Stop the tunnel while correcting the target, then repeat the local and external tests.

The sign-in page appears, but authentication fails

Try the same credentials on the local EMS-ESP interface. If they fail locally too, investigate the EMS-ESP account configuration. If local sign-in works but remote sign-in does not, compare browser behavior and confirm that the tunnel reaches the intended service. Do not disable authentication as a diagnostic shortcut.

The public interface loads, but data is stale or implausible

Compare it with the local page. If both show the same stale or incorrect information, investigate EMS-ESP bus communication and device configuration. A tunnel transports the application response but does not create, cache, or interpret heating data.

Frequently asked questions