# Neuer Controller: bis zu 30 1w Thermometer über Modbus **URL:** \ **Category:** Deutsches Forum\ **Created:** [January 21, 2025, 6:03am UTC](https://community.openems.io/t/neuer-controller-bis-zu-30-1w-thermometer-uber-modbus/5607 "2025-01-21T06:03:01Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![klinki](https://community.openems.io/letter_avatar_proxy/v4/letter/k/858c86/32.png) [@klinki](https://community.openems.io/u/klinki)\ **Post date:** [January 21, 2025, 6:03am UTC](https://community.openems.io/t/neuer-controller-bis-zu-30-1w-thermometer-uber-modbus/5607/1 "2025-01-21T06:03:01Z")
Hallo Forum, Ich habe einen neuen Controller erstellt, über den bis zu 30 OneWire Thermometer erfasst werden können. Das Ganze läuft über ein [Esera Eco 501](https://esera.de/Produkte/11607-24/ECO-501-Pro-Zentraleinheit-Industrial?srsltid=AfmBOorBWvvSWgQ5pagn6FsmXRxPnXqzujLVIY8aVBN2krUNlXlFkBtq) 1w ↔ Modbus-Gateway. Aktuell mit “nur” 10, in OpenEMS, konfigurierbaren Sensoren. In den nächsten Tagen geht es in den Dauertest. In der UI gibt es m.W. noch kein Widget für Thermometer - daher sieht man noch nicht viel. Mein UseCase ist die Erfassung von Temperaturen für die hydraulische Einbindung eines BHKWs in das bestehende Heizungssystem. Somit kann ich dann sehr schnell und einfach viele Datenpunkte installieren und hab die Daten in Influx 😁 Für einen PR ist Code noch nicht sauber genug, aber wer Interesse hat: [Mein Repo](https://github.com/DerWahreKlinki/openemsForkKlinki/tree/develop/io.openems.edge.modbus.thermometer) Gruß, Klinki ---
**Author:** ![energiejang](https://community.openems.io/letter_avatar_proxy/v4/letter/e/a87d85/32.png) [@energiejang](https://community.openems.io/u/energiejang)\ **Post date:** [January 21, 2025, 2:47pm UTC](https://community.openems.io/t/neuer-controller-bis-zu-30-1w-thermometer-uber-modbus/5607/2 "2025-01-21T14:47:06Z")
Hallo @klinki, da wir drei BHKWs betreiben, haben wir da großes Interesse! Da ich mich mit Java nicht auch noch beschäftigen möchte, hatte ich bereits über eine Lösung mit OpenPLC nachgedacht: ich lese mehrere Wärmemengenzähler aus, rechne auf “Wärmeleistung” um (damit man eine bessere Vorstellung hat, ein Wert in MWh sagt ja erst mal nicht viel) und möchte natürlich auch eine Außentemperatur haben. Und das alles dann in InfluxDB. Dazu hätte ich dann Node-RED zu Hilfe genommen. Bitte bleibt dran, hört sich sehr gut an! Ich wäre aber immer noch für einen Wärme-Fork. Oder ein Tab in der UI und man sieht “Wärmeleistungen” (Beispiel: BHKWs liefern 67 kW thermisch, Schwimmbad nimmt gerade 34 kW thermisch auf). Viele Grüße Andreas 🙂 ---
**Author:** ![klinki](https://community.openems.io/letter_avatar_proxy/v4/letter/k/858c86/32.png) [@klinki](https://community.openems.io/u/klinki)\ **Post date:** [January 21, 2025, 6:33pm UTC](https://community.openems.io/t/neuer-controller-bis-zu-30-1w-thermometer-uber-modbus/5607/3 "2025-01-21T18:33:52Z")
Also, ich kann über das 1Wire/Modbus-GW schon sagen, dass ich es seit ca. 2 Jahren in einer Heizungsanlage in Betrieb habe. Erfolgreich. Mit 18 Sensoren (aus China). Allerdings direkt von Eco 501 zur Logo. Das OpenEMS-Modul ist heute erstmal mit 2 Sensoren in Betrieb gegangen (vielleicht auch, weil mein Elektriker nicht aus dem Quark kommt und ich dann doch alles selbst machen muss). Funktioniert! Temperatur-Werte werden jeden Zyklus erfasst. Die Daten landen dann halt direkt über OpenEMS in Influx und werden mit Grafana ausgewertet. Ist ne schicke Kombination… Wir hatten das mit dem Fork für Wärme schon vor einiger Zeit mal im Forum diskutiert. Heizungssteuerung ist aber noch ein ganz anderes Paar Schuhe und die Meinung (auch meine) war, dass OpenEMS sich mit Strom beschäftigen sollte. Ich finde die aktuelle Entwicklung bzgl. SGready und halt das mit dem Heizstab aber schon sehr gut. Das Interesse an der Sektoren-Kopplung ist hier im Forum jedenfalls nicht klein. 67kW thermisch…das ist schon ein Wort. Zur Einordnung: wir haben im Winter eine Anforderung für ca. 200kW thermisch…der elektrische Output ist ein nettes “Zubrot”. Die BHKWs werden einen Output von 40/80 haben. Allerdings hängt jetzt viel an der hydraulischen Planung. Vielleicht können wir uns mal in einer Web-Konferenz austauschen? Gruß, Klinki ---
**Author:** ![klinki](https://community.openems.io/letter_avatar_proxy/v4/letter/k/858c86/32.png) [@klinki](https://community.openems.io/u/klinki)\ **Post date:** [January 27, 2025, 5:55am UTC](https://community.openems.io/t/neuer-controller-bis-zu-30-1w-thermometer-uber-modbus/5607/4 "2025-01-27T05:55:39Z")
![grafik](https://community.openems.io/uploads/default/original/2X/3/3cbf95110d9841b9c7fe355dbec8394e03aae80e.png) Hier eine erste Auswertung mit Grafana. Die Auflösung ist 5 Minuten - deshalb ein sehr “zittriges” Bild. Passt aber. Auch die heftigen negativen Ausschläge. An dem Tag war Reinigung. ---
**Author:** ![stefan.feilmeier](https://community.openems.io/user_avatar/community.openems.io/stefan.feilmeier/32/2585_2.png) [@stefan.feilmeier](https://community.openems.io/u/stefan.feilmeier)\ **Post date:** [March 4, 2025, 2:32pm UTC](https://community.openems.io/t/neuer-controller-bis-zu-30-1w-thermometer-uber-modbus/5607/5 "2025-03-04T14:32:04Z")
Hallo Klinki, der Esera Eco 502 ist interessant. Bei mir zu Hause reicht noch der USB-OneWire-Adapter, aber wenns mal mehr werden… Wenn ich das richtig sehe, haben die Modbus-Register jeweils einen Offset von 200. Da wir eine `Thermometer` Nature haben, wäre der “saubere” Weg eigentlich, dass es je Thermometer eine eigene Komponente gibt und alle gemeinsam eine Modbus-Bridge verwenden. Netter Nebeneffekt: man kann dann auch für jedes Thermometer ein Alias vergeben. Da diese Adressierung spezifisch für den Esera Eco 501 ist, könnten wir also ein Bundle dafür machen, mit einer “Esera OneWire Thermometer”-Komponente. Diese hätte dann eine Enum-Property, mit dem einstellbar ist, das wievielte Thermometer ausgelesen werden soll. Sowas würde ich dir gerne reviewen und mergen. 😉 Gruß, Stefan ---
**Author:** ![klinki](https://community.openems.io/letter_avatar_proxy/v4/letter/k/858c86/32.png) [@klinki](https://community.openems.io/u/klinki)\ **Post date:** [March 10, 2025, 1:06pm UTC](https://community.openems.io/t/neuer-controller-bis-zu-30-1w-thermometer-uber-modbus/5607/6 "2025-03-10T13:06:00Z")
Hi Stefan, Ich hab das Bundle [io.openems.edge.thermometer.esera.onewire](https://github.com/DerWahreKlinki/openemsForkKlinki/tree/develop/io.openems.edge.thermometer.esera.onewire) zunächst einmal in meinem Repo erstellt. Die Idee alles zu vereinzeln, gefällt mir gut. So wird es modularer. Für die Validierung der Werte ziehe ich nun die internen Modbus-Register für den Lese-Status pro Sensor zu Rate. Ich lasse es mal ein paar Tage laufen und schau’ mir mal an wie stabil es ist. Gruß, klinki ---
**Author:** ![stefan.feilmeier](https://community.openems.io/user_avatar/community.openems.io/stefan.feilmeier/32/2585_2.png) [@stefan.feilmeier](https://community.openems.io/u/stefan.feilmeier)\ **Post date:** [March 13, 2025, 9:48am UTC](https://community.openems.io/t/neuer-controller-bis-zu-30-1w-thermometer-uber-modbus/5607/7 "2025-03-13T09:48:12Z")
Hallo, ich habe einen ganz kurzen Blick auf den Code geworfen und der war erfreulich positiv! 🙂 Kleine Anmerkungen - `OneWireDevice` muss kein `OptionsEnum` sein, sondern es reicht ein normales `enum`. Damit sparst du dir den `UNDEFINED`, der ja in der Config keinen Sinn macht. - Es fehlen noch einige allgemeine Punkte aus der Coding Guideline ([Coding Guidelines :: Open Energy Management System](https://openems.github.io/openems.io/openems/latest/contribute/coding-guidelines.html)) - `webconsole_configurationFactory_nameHint` ist nicht gesetzt - Eclipse Autoformat, Organize Imports, allgemeine Formatierung und Zeilenlänge, Leerzeilen, etc. - Statt `debugMode` nutze ich mittlerweile oft ein `LogVerbosity` enum in der Config. Und kann damit z. B. sekündliche Logs in `debugLog()` aktivieren. Das verbessert die Übersichtlichkeit des Logs - Um Channels zu setzen ist `TOPIC_CYCLE_BEFORE_CONTROLLERS` nicht optimal, weil man einen Cycle verliert. Besser wäre `BEFORE_PROCESS_IMAGE`. In `validateAndSetTemperatures()` müsstest du dann mit dem `nextValue()` von OwdStatus arbeiten. - Alternativ könnte man das auch mit einem `ElementToChannelConverter` lösen der den Wert für `TEMPERATURE` nur setzt, wenn `OWD_STATUS` ok ist. - Beim `handleEvent()` muss man leider `isEnabled()` separat abfangen, weil das direkt vom OSGI EventManager kommt. - `defineModbusProtocol()` wird durch `super.activate()` aufgerufen. Wenn du also vorher die `config` lokal ablegst, kannst du in `defineModbusProtocol` darauf zugreifen und sparst dir das Konstrukt mit `addModbusTask()`. - `EseraOneWireThermometer` sollte die `Thermometer`-Api implementieren (/io.openems.edge.thermometer.api/src/io/openems/edge/thermometer/api/Thermometer.java). Dann kannst du damit auch meine Heizungssteuerung verwenden 😉 Gruß, Stefan ---
**Author:** ![klinki](https://community.openems.io/letter_avatar_proxy/v4/letter/k/858c86/32.png) [@klinki](https://community.openems.io/u/klinki)\ **Post date:** [March 14, 2025, 7:45am UTC](https://community.openems.io/t/neuer-controller-bis-zu-30-1w-thermometer-uber-modbus/5607/8 "2025-03-14T07:45:49Z")
Moin Stefan, - Checkstyle angewendet. - LogVerbosity eingeführt. Bisher aber noch nicht intensiv genutzt - EventListener auf `BEFORE_PROCESS_IMAGE` umgestellt - `defineModbusProtocol` umgesetzt. Mein Problem war die Config nicht früh genug abzulegen. Somit fiel mir nichts besseres ein als den Umweg über den separaten ModbusTask zu gehen. Mein altes Wald/Bäume-Problem - Ich beschreibe jetzt den Channel aus der `Thermometer` API. Allerdings hat diese keine explizite `persistencePriority`. Da für mich aktuell nur die Aufzeichnungen in Influx relevant sind, habe ich die Priorität in der API geändert. Das wollte ich eigentlich nicht, da es sich um ein bestehendes Modul handelt. Kann ich die Persistenz “nachträglich” noch ändern/überladen? Der Code enthält aber noch einige unnötige Kommentare und auskommentierte Zeilen. Wenn Du mit der aktuellen Entwicklung einverstanden bist, werden diese noch entfernt und ich mache nen PR. Gruß, klinki ---
**Author:** ![stefan.feilmeier](https://community.openems.io/user_avatar/community.openems.io/stefan.feilmeier/32/2585_2.png) [@stefan.feilmeier](https://community.openems.io/u/stefan.feilmeier)\ **Post date:** [March 14, 2025, 7:53am UTC](https://community.openems.io/t/neuer-controller-bis-zu-30-1w-thermometer-uber-modbus/5607/9 "2025-03-14T07:53:26Z")
> Ich beschreibe jetzt den Channel aus der `Thermometer` API. Allerdings hat diese keine explizite `persistencePriority`. Da für mich aktuell nur die Aufzeichnungen in Influx relevant sind, habe ich die Priorität in der API geändert. Das wollte ich eigentlich nicht, da es sich um ein bestehendes Modul handelt. Ja, das ist sinnvoll. > Der Code enthält aber noch einige unnötige Kommentare und auskommentierte Zeilen. Wenn Du mit der aktuellen Entwicklung einverstanden bist, werden diese noch entfernt und ich mache nen PR. Habs nicht nochmal im Detail angeschaut, aber ich finde es grundsätzlich gut. Sinnvoll wäre eine aussagekräfte README, die z. B. die Frage beantwortet, wie man das Esera-Gerät konfigurieren muss. Danke dir! Gruß, Stefan ---
**Author:** ![klinki](https://community.openems.io/letter_avatar_proxy/v4/letter/k/858c86/32.png) [@klinki](https://community.openems.io/u/klinki)\ **Post date:** [March 20, 2025, 6:36am UTC](https://community.openems.io/t/neuer-controller-bis-zu-30-1w-thermometer-uber-modbus/5607/10 "2025-03-20T06:36:11Z")
Moin Stefan, Ich habe im adoc eine entsprechende Anleitung hinterlegt. Gestern mit Herrn Geisler (Geschäftsführer Esera) telefoniert und ihm von der Entwicklung erzählt. Er schaut sich die Readme noch an. Wir wollen in den nächsten Tagen noch ein WebMeeting machen um ihm die Details etwas näher zu bringen. Die Meinung des Herstellers ist an dieser Stelle sicherlich nicht uninteressant. Denen fehlen aktuell die Ressourcen um sich in das Thema OpenEMS einzuarbeiten, aber es besteht Hoffnung das in den nächsten Wochen nachholen zu können. > [@stefan.feilmeier](#): > > Dann kannst du damit auch meine Heizungssteuerung verwenden Was genau hast Du denn da gemacht? Ist eigentlich ein UI-Widget für Thermometer angedacht? Gruß, Klinki ---
**Author:** ![s\_h](https://community.openems.io/letter_avatar_proxy/v4/letter/s/85e7bf/32.png) [@s\_h](https://community.openems.io/u/s_h)\ **Post date:** [March 20, 2025, 9:55am UTC](https://community.openems.io/t/neuer-controller-bis-zu-30-1w-thermometer-uber-modbus/5607/11 "2025-03-20T09:55:18Z")
> [@klinki](#): > > > [@stefan.feilmeier](#): > > > > Dann kannst du damit auch meine Heizungssteuerung verwenden > > Was genau hast Du denn da gemacht? > > Ist eigentlich ein UI-Widget für Thermometer angedacht? Das wäre für mich auch sehr interessant, dann könnte mal versuchen, die Steuerung vom Pellet-Primärofen und der zugehörigen Pumpe (7 Thermometer und 8 Relais) ins OpenEMS zu übertragen. Damit könnten sicher Abhängigkeiten mit zukünftigem Heizstab und zukünftiger Wärmepumpe realisiert werden, so dass immer die gerade optimale Wärmequelle aktiv ist. Und wenn dann noch die Solarthermie eingebunden werden könnte… Stefan ---
**Author:** ![stefan.feilmeier](https://community.openems.io/user_avatar/community.openems.io/stefan.feilmeier/32/2585_2.png) [@stefan.feilmeier](https://community.openems.io/u/stefan.feilmeier)\ **Post date:** [March 28, 2025, 8:14am UTC](https://community.openems.io/t/neuer-controller-bis-zu-30-1w-thermometer-uber-modbus/5607/12 "2025-03-28T08:14:13Z")
> [@klinki](#): > > > [@stefan.feilmeier](#): > > > > Dann kannst du damit auch meine Heizungssteuerung verwenden > > Was genau hast Du denn da gemacht? Ich habe damit ein paar Einzelraumheizungen mit Infrarot-Deckenheizung und Elektrofußbodenheizung umgesetzt. Siehe: [openems/io.openems.edge.controller.io.heating.room at develop · OpenEMS/openems · GitHub](https://github.com/OpenEMS/openems/tree/develop/io.openems.edge.controller.io.heating.room) > [@klinki](#): > > Ist eigentlich ein UI-Widget für Thermometer angedacht? Da bin ich mir unschlüssig. Für FEMS wird es sowas erstmal nicht geben. Wir entwickeln zwar auch gerade eine historische Darstellung für Temperatur, aber das ist dann in eine Heizstab-App eingebaut. Gruß, Stefan ---
**Author:** ![klinki](https://community.openems.io/letter_avatar_proxy/v4/letter/k/858c86/32.png) [@klinki](https://community.openems.io/u/klinki)\ **Post date:** [March 28, 2025, 8:56am UTC](https://community.openems.io/t/neuer-controller-bis-zu-30-1w-thermometer-uber-modbus/5607/13 "2025-03-28T08:56:56Z")
> [@stefan.feilmeier](#): > > Da bin ich mir unschlüssig. Für FEMS wird es sowas erstmal nicht geben. Wir entwickeln zwar auch gerade eine historische Darstellung für Temperatur, aber das ist dann in eine Heizstab-App eingebaut. Ebenfalls unschlüssig. OpenEMS beschäftigt sich mit Strom 😉 Bei Geräten die Temperaturen für die Steuerung nutzen, fände ich das aber sinnvoll. Wie bei anderen Controller auch, will man später ja auch wissen warum welche Entscheidung getroffen wurde. Leider bekam ich mit Esera noch kein WebMeeting hin - bleibe aber dran. Andererseits hindert uns aber auch niemand den Controller schon mal als PR zu veröffentlichen. Gruß, klinki ---
**Author:** ![stefan.feilmeier](https://community.openems.io/user_avatar/community.openems.io/stefan.feilmeier/32/2585_2.png) [@stefan.feilmeier](https://community.openems.io/u/stefan.feilmeier)\ **Post date:** [March 28, 2025, 9:09am UTC](https://community.openems.io/t/neuer-controller-bis-zu-30-1w-thermometer-uber-modbus/5607/14 "2025-03-28T09:09:40Z")
Genau. Die Temperatur ist meistens nur im Kontext eines Controllers sinnvoll. Deshalb möchte ich z.B. die Pufferspeicher-Temperatur bei der Visualisierung des Heizstab-Controllers mit anzeigen. Bei einem Relais ist das m.E. übrigens das Gleiche. ---
**Author:** ![bearfoo](https://community.openems.io/user_avatar/community.openems.io/bearfoo/32/2155_2.png) [@bearfoo](https://community.openems.io/u/bearfoo)\ **Post date:** [May 16, 2025, 5:15pm UTC](https://community.openems.io/t/neuer-controller-bis-zu-30-1w-thermometer-uber-modbus/5607/15 "2025-05-16T17:15:52Z")
ich habe einen Esera ECO 501 pro abzugeben