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 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:
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).
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?
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.
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.
Ich hab das Bundle 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.
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.
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
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.
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.
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.
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…
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.
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.
