Demo
Demo

Back to Overview

A €180,000 Open Source HEMS Tender Is Live. Why OpenRemote Users Should Take a Look

Aug 3, 2026 Industry Insights

German energy agency dena has opened a public tender that speaks directly to anyone building open source energy management solutions. If you’re active in the OpenRemote community, this is worth five minutes of your attention.

What is the “SET Inno Tandems” Call for Solutions?

The Start-up Energy Transition (SET) Hub is a German government-backed program (funded by the Federal Ministry for Economic Affairs and Energy, BMWE) that has been supporting the energy and climate-tech start-up ecosystem since 2020. As part of its current phase, SET Hub III (2025–2027), dena is running a matchmaking format called SET Inno Tandems: mid-sized German companies (“Mittelstand”) bring concrete, unsolved energy-transition challenges, and innovative partners — start-ups, but also open-source projects and communities — bid to implement the solution over a focused six-month engagement.

Four challenges are open for bids, each run as a separate lot, each capped at €180,000, with bids due by 20 August 2026:

  1. Lot 1 — An open-source HEMS (Home Energy Management System) for small and medium municipal utilities, with Stadtwerke Quickborn
  2. Lot 2 — A fault-management tool for grid-oriented device control in the metering-point-operator’s area of responsibility, with inexogy
  3. Lot 3 — AI-driven resource-efficiency optimization for manufacturing, with fischer Hydroforming
  4. Lot 4 — A value-added Ambient Assisted Living application on a CLS adapter, with Power Plus Communications (PPC)

The lot most relevant to this community is Lot 1, possibly Lot 2 as well.

Lot 1 in a nutshell

Stadtwerke Quickborn — a municipal utility with roughly 85 employees — wants a customer platform for its residential customers that:

  • Shows consumption, tariff information, and curtailment/dimming status
  • Comes with a HEMS plug-in: local optimization logic running on an edge device physically installed in the household, plus a backend that feeds it weather forecasts and tariff data
  • Is built on an existing open-source stack rather than from scratch, evaluated against a clear set of must/should/could criteria
  • Supports interoperability with wallboxes, battery storage, heat pumps, and PV inverters via EEBUS, Modbus TCP, and OCPP
  • Meets German IT-security expectations and supports both centralized and decentralized hosting models so other utilities can adopt it later
  • Gets validated in a real field test with a small number of pilot households, and delivered with a reusable open-source handbook so other utilities can pick it up

In short: dena and Stadtwerke Quickborn are asking the market for exactly the kind of system an open source IoT platform with asset management, rules, and protocol support already exists to provide.

Why OpenRemote is a strong starting point

OpenRemote is an open-source IoT platform built around asset management, a rules engine, and broad protocol connectivity, which maps onto several of the tender’s explicit requirements almost directly:

  • Asset centric data model: households, meters, wall boxes, heat pumps, and PV inverters can all be modeled as assets with attributes, which is exactly the abstraction the tender wants for visualising consumption, tariffs, and device status.
  • Rules engine: the tender wants the platform to optimize self-consumption and respond to curtailment/dimming commands. OpenRemote’s rules engine is a natural fit for encoding the “robust process” logic, reacting to signals and adjusting flexible loads accordingly.
  • Protocol support: OpenRemote already ships with, or can be extended with, connectors for many of the protocols the tender explicitly names (Modbus TCP, MQTT, REST). EEBUS and OCPP support is a gap worth being upfront about.
  • Edge/cloud flexibility: the tender explicitly wants both a decentralized (utility-hosted or edge-hosted) and a centralized (multi-tenant) deployment model. OpenRemote’s manager can already run standalone at the edge or centrally serving multiple realms, which maps well onto exactly this “dezentral vs. zentral” split the tender asks bidders to design for.
  • Open licensing: the tender explicitly wants the result released as a reusable open-source product for other utilities, not a proprietary pilot that dies after the project ends.

Why pairing OpenRemote with Home Assistant or openHAB makes the case stronger

OpenRemote is strong on the utility-facing side: asset management, rules, multi-tenant hosting, and integration with backend data sources like tariffs and weather. It is not, by itself, a mature in home HEMS device platform with a large library of pre-built consumer-device integrations.

That’s exactly where Home Assistant or openHAB complement it:

  • Both have mature, actively maintained integrations for the long tail of consumer wallboxes, heat pumps, batteries, and smart plugs that a small pilot with only “a low single-digit number of households” will inevitably run into.
  • Both can run on the same local edge hardware the tender specifies, acting as the device-facing layer, while OpenRemote acts as the utility-facing layer: aggregating standardized asset data, applying the optimization/curtailment rules, and exposing the customer platform and utility dashboard.
  • This division of labor directly answers the tender’s own architecture question: it explicitly asks bidders to describe “which processing steps run locally on the edge component and which are cloud-based”, a HA/openHAB at the edge, OpenRemote for aggregation-and-rules split is a clean, defensible answer to that exact question, and to the centralised/decentralised hosting question right after it.
  • It also derisks the EEBUS/OCPP gap mentioned above: rather than building these protocol bridges from scratch inside OpenRemote, a bidder can lean on Home Assistant’s or openHAB’s existing bindings and let OpenRemote consume normalized data from them via MQTT or REST.

None of this is a plug-and-play answer, the tender asks for a genuine architecture decision, a real must/should/could evaluation of stacks, and hard proof in a field test. But it does mean a bidder isn’t starting from a blank page. The building blocks for a serious, defensible proposal already exist in the open-source ecosystem.

An offer to bidders

If your organisation is considering bidding on Lot 1 (or sees overlaps with Lot 2), and you’re evaluating OpenRemote, alone or paired with Home Assistant/openHAB, as part of your technical approach:

We’re happy to help with the analysis and, where needed, further development of OpenRemote to meet the tender’s specific must-criteria, architecture mapping against the “Leistungspaket” structure, protocol gap analysis (EEBUS/OCPP in particular), and scoping any OpenRemote extensions your bid would require. Reach out and let’s talk before the 20 August 2026 deadline. We realise it’s short notice!

Full tender documents and bidder Q&A are only handled through the official procurement platform (evergabe.de). This post is background context, not a substitute for the official documents. More information can be found at https://set-hub.de/