Remote-Readable Meters by 31 December 2026: What German Law Requires and Where LoRaWAN Fits

WZ-IT operates chirphost. Current hosting starts from €129.90 net/month; setup and service level follow the proposal. Former package prices, location lists and cost comparisons in this dated article describe the previous offer, not current WZ-IT terms. View current service scope.

A deadline that affects many German building owners expires on 31 December 2026, and it cannot be moved: meters and heat cost allocators that are not remote-readable must be retrofitted or replaced by then. Missing it hands tenants a statutory right of deduction. This article quotes what the Heating Cost Ordinance actually requires, explains the frequently overlooked interoperability obligation, and sets out where LoRaWAN with your own network server fits into this picture and where it does not.

Also of interest: Building a private LoRaWAN network · ChirpStack: managed or self-hosted? · The EU Data Act and LoRaWAN

Table of Contents

• The deadline, verbatim
• What happens when the deadline passes
• The duty that arrives with the retrofit
• Where LoRaWAN fits
  • How this differs from wM-Bus
• Why the network server becomes a compliance question
• What the timeline still allows
• chirphost: managed ChirpStack from Germany
• Conclusion
• Sources

The deadline, verbatim

It is worth reading the official text [4] itself, because public discussion tends to abbreviate it.

Section 5 paragraph 3 of the Heating Cost Ordinance states that consumption measurement equipment which is not remote-readable must meet the requirements of paragraphs 2 and 5 by 31 December 2026, through retrofitting or replacement [1].

The reference to two paragraphs is the decisive point. This is not only about remote readability.

Paragraph 2 requires that consumption measurement equipment installed after 1 December 2021 must be remote-readable [1]. An exception applies where a single device within a system is replaced while the remaining devices stay non-remote-readable [1].

Paragraph 5 states that since 1 December 2022 only such remote-readable equipment may be installed as is interoperable, including its interfaces, with equipment of the same kind from other manufacturers [1].

At the deadline, therefore, both requirements apply together: remote-readable and interoperable.

What happens when the deadline passes

Section 12 paragraph 1 governs the consequence, and it is felt immediately [3]:

The right of deduction belongs to the user; no authority has to establish it. Missing the deadline therefore brings no fine, but a bill that may be reduced by three per cent, by every tenant who knows about it.

The duty that arrives with the retrofit

One point regularly overlooked in planning: the retrofit triggers a second obligation.

Section 6a requires that where remote-readable equipment is installed, information must be provided monthly from 1 January 2022 [2]. The content includes the user's consumption in the previous month in kilowatt hours, comparisons with the previous month and with the same month of the previous year, and a comparison with a normalised or benchmark-derived average user of the same user category [2].

This duty is tied to remote readability. Retrofitting triggers it, and breaching it carries the same three per cent deduction [3].

That matters technically. An annual reading no longer suffices. It takes a data flow that arrives reliably every month, gets processed and reaches the user. This is where it is decided whether the chosen technology carries, or whether somebody reworks it twelve times a year.

Where LoRaWAN fits

The requirement profile for meter reading is unusual, and it suits LoRaWAN better than most other radio technologies:

• Tiny payloads. A meter reading is a few bytes. Bandwidth is irrelevant.
• No real time. Monthly is the legal requirement; daily is already comfortable.
• Difficult radio conditions. Meters sit in basements, shafts and service rooms. Range and penetration matter more than throughput.
• Long service life. One battery change per device is an appointment in every flat. Years, not months, is the benchmark.
• Licence-free band. No mobile contract per meter.

That is essentially a description of LoRaWAN. Conversely: for applications with high data rates or genuine real-time requirements it is the wrong technology, and a looming deadline does not change that.

How this differs from wM-Bus

Honestly, LoRaWAN is not the established standard in German submetering. That is wM-Bus, designed for reading inside the building, often via walk-by or a collector in the house.

The difference lies in range and operating model. wM-Bus solves the problem within the building; LoRaWAN can cover several properties from one gateway and needs no reading trip, but requires a gateway and a network server. In practice both exist side by side, and the decision depends on the installed base, building structure and existing infrastructure, not on general superiority.

Why the network server becomes a compliance question

This is where the circle closes back to the interoperability obligation in section 5 paragraph 5 [1].

The provision requires interoperability including interfaces with equipment of the same kind from other manufacturers. It addresses the equipment, not the network server. But it shows the direction the legislator is thinking in: away from closed systems where one vendor supplies device, transmission and evaluation together, and where switching means replacing every meter.

Your own network server carries that line through consistently:

• Device management and keys stay with you, not in a vendor account.
• Meters from different manufacturers land in the same network, provided they speak LoRaWAN.
• The raw data feeds into your billing, through an interface of your choosing.
• Changing operators is a server configuration question, not a device swap.

We covered data sovereignty in IoT in more depth in our article on the EU Data Act and LoRaWAN; in submetering it is not an abstract principle but the question of who owns your tenants' consumption data.

What the timeline still allows

It is early September 2026. Just under four months remain until the deadline. That is workable, but not with a run-up.

Setting up a LoRaWAN network is the smaller part: place the gateway, connect it to the network server, create device profiles, register the meters [5]. How that works in detail is in our article Building a private LoRaWAN network.

The effort sits elsewhere:

1. Take stock. Which devices are not remote-readable? Without that list every plan is guesswork.
2. Check exceptions. Section 5 paragraph 3 knows narrowly defined cases. Whether one applies is a legal question, not a technical one.
3. Procure meters. Lead times in the fourth quarter of 2026 are the real risk, because everyone shares the same deadline.
4. Survey coverage. Gateway locations, penetration in basements and shafts. This does not belong in December.
5. Build the data flow that carries the monthly information under section 6a [2].
6. Install and commission.

Starting step 1 in September leaves room. Starting in November means depending on lead times you do not control.

chirphost: managed ChirpStack from Germany

We run ChirpStack as a dedicated instance, in Germany by default, with a data processing agreement. For submetering projects that means: you get your own network server with your own device management without having to operate it, and your data flows into your billing through an interface of your choosing.

The Startup plan costs EUR 99.90 net per month, the Business plan EUR 199.90, Enterprise is quoted individually. Gateways are not billed by count, which makes the difference across a property portfolio with many sites.

What we do not supply and do not claim to: meters, their metrological approval, and the assessment of whether an exception under section 5 paragraph 3 applies in your case. The first belongs to the meter manufacturer, the second in legal advice.

The trial runs 7 days. A credit card is required to sign up, and after it expires the trial converts automatically into the chosen paid subscription.

See pricing · Get in touch

Conclusion

The 31 December 2026 deadline is unambiguous, and the consequence of missing it is written into the law: a three per cent deduction right per user, plus another three per cent if the monthly information under section 6a fails to arrive.

Two things are regularly underestimated in preparation. First, the deadline requires not only remote readability but, through the reference to paragraph 5, interoperability as well. Second, the retrofit itself creates a new standing obligation, namely the monthly data flow to the user.

Planning for both from the start pushes you almost automatically away from closed systems. LoRaWAN with your own network server is one answer to that, not the only one, but one where devices, data and vendor choice stay separable.

chirphost is an independent managed hosting provider. "LoRaWAN" is a trademark of the LoRa Alliance, "LoRa" a trademark of Semtech. Quotations from the Heating Cost Ordinance follow the official text at gesetze-im-internet.de. This article provides technical context and does not constitute legal advice; for exceptions, individual cases and metrology questions, please seek professional advice.

Sources

• [[1]] Section 5 HeizkostenV – consumption measurement equipment: paragraph 2 (remote readability from 1 Dec 2021), paragraph 3 (retrofit by 31 Dec 2026), paragraph 5 (interoperability from 1 Dec 2022)
• [[2]] Section 6a HeizkostenV – monthly consumption information where remote-readable equipment is installed, from 1 Jan 2022, and its content
• [[3]] Section 12 HeizkostenV – right of deduction: 3 per cent for missing remote-readable equipment and for missing information under section 6a, 15 per cent where costs are not billed by consumption
• [[4]] Heating Cost Ordinance – official full text
• [[5]] ChirpStack – open LoRaWAN network server documentation
• chirphost.de – managed ChirpStack hosting