Neuer Adapter EMS-ESP für Bosch Heizungen

[yafbu]

@yafbu said in Neuer Adapter EMS-ESP für Bosch Heizungen:

Die EMS Statistiken, die vorher nichts anzeigten, liefern jetzt Werte, genau wie "ems-read"
allerdings steht jetzt der parameter "km200-read" auf "null". Bei der 1.0.2 waren das immer um die 15-20 Sekunden. Der KM200 Zugriff funktioniert allerdings.

update: nach einem Tag (habe gestern nicht mehr nachgesehen) sind auch die Werte für km200-read da.
Viele Grüße
Fabian

[tp1de]

@yafbu sagte in Neuer Adapter EMS-ESP für Bosch Heizungen:

update: nach einem Tag (habe gestern nicht mehr nachgesehen) sind auch die Werte für km200-read da.

Ja das habe ich mir gedacht. Wenn der Adapter startet wird erst EMS-ESP initialisiert und dann asynchron bereits der Daten-Poll fürs EMS-ESP Gateway gestartet.
Erst danach ist der KM200 init dran und der kann etwas dauern - siehe Log.
Danach wir der Poll für KM200 gestartet - standardmäßig 300 Sekunden Poll-Zeit.
Erst wenn der erste Poll-Durchlauf erfolgt ist, wird die Lesezeit eingetragen. Das kann nach dem Start ca. 4-5 Minuten dauern.

[mpenno]

@tp1de Hallo.
Danke für Deine gute Erklärung. Ich musste erst einmal etwas Zeit finden, um die Daten vom RC300 zusammenzusammeln und gegenüberzustellen:

(links die Werte von der Heizung, rechts von der Warmwasseraufbereitung)

• Alle y-Werte passen zum Datenbankwert des EMS-Plugins und zum Wert im Portal.
• Die Warmwasseraufbereitungswerte zwischen RC300 und EMS-Plugin weichen um 1-2kW ab,

Aber der 24h Gas Heizungswert vom RC300 ist mal höher und mal tiefer. Ich sehe da interessanter Weise nur einen Zusammenhang (siehe fett gedruckte Werte). Der RC300-Wert ist nur dann kleiner als der EMS bzw. Portal-Wert, wenn wir einen höheren Warmwasserverbrauchswert (nämlich zwei Ladungen am Tag) haben.

Anbei ein Bild vom RC300 (Datum 20.1.2022, 24h-Werte gelten für den 19.1.2022)

Im Portal wird kein Wert für den Warmwasserverbrauch angegeben, sondern nur Heizung. Ich nehme jetzt auch mal an, das der Warmwasserverbrauchswert exklusive ist, oder?

Genau so interpretiere ich diese Werte:
/heatSources/actualPower = ausschließlich für die Heizung und
/heatSources/actualDHWPower = ausschließlich für Warmwasseraufbereitung

Oder beinhaltet erstgenannter den gesamten Gasverbrauch?
(Ich könnte das nur testen, wenn ich meiner Familie das Warmwasser abdrehe, aber das lasse ich lieber )

Viele Grüße
file:///home/michael/Grundstück/Modernisierung/Haustechnik/Automation/ioBroker/Fragen/km200-Tests/2022-01-20_Verbrauch_24h.jpg

[tp1de]

@mpenno sagte in Neuer Adapter EMS-ESP für Bosch Heizungen:

heatSources/actualPower

Ist der Gesamtverbrauch in kWh für Gas und WW-Aufbereitung.

Vielen Dank für Deine Auswertung. Ich schaue sie mir Morgen mal genauer an.
Inzwischen ist der Adapter in der Version 1.0.5 im offiziellen ioBroker Repository.

Das war eine Menge Arbeit (hat einen Monat gebraucht), da inzwischen ein offizielles "Review" stattfindet und vieles zum Ändern angemerkt wurde.
(Der km200 Adapter hätte heute so wie er ist auch keine Freigabe bekommen).

Januar 2022 ist bei mir wieder mal ein Monat, wo bei den Monatswerten viele Samples fehlen.
Der Monatswert weicht deshalb erheblich von der Summe der Tageswerte ab (ca. 20%).
In der aktuellen Version 1.0.5 habe ich deshalb den aktuellen Monatswert durch die Summe der Tageswerte (korrigiert um Faktor Soll / Ist - Samples) ersetzt.

Ich habe einen Impulssensor am Gaszähler. Gaszähler und der berechnete Monatswert weichen aktuell bei mir am 20.1.22 um 2 kWh (< 0,1 %) ab. Das ist für mich ok. Mal sehen wie sich das weiter entwickelt.

Viele Grüße
Thomas

[mpenno]

@tp1de
Gratulation für die erste offizielle Version! Die Installation hat gut über die Oberfläche geklappt. Wurde bei mir als Update von 1.0.4 auf 1.0.5 ausgeführt.

Die Tagessample-Werte für Januar waren vollständig (von möglichen 1440 waren es immer 1339 oder 1338).

Meine Monatswerte vom letzten Jahr sind:

{"id":"/recordings/heatSources/actualPower?interval=2021","type":"yRecording","writeable":0,"recordable":0,"recordedResource":{"id":"/heatSources/actualPower","uri":"http://10.0.0.48/heatSources/actualPower"},"interval":"2021","sampleRate":"P31D","recording-type":"actual","recording":[
{"y":133140,"c":44594},
{"y":376800,"c":42495},
{"y":339420,"c":42876},
{"y": 58020,"c":43156},
{"y": 30780,"c":44593},
{"y":  3960,"c":43155},
{"y":  4140,"c":43831},
{"y":  8340,"c":43566},
{"y": 13920,"c":33085},
{"y": 41220,"c":44653},
{"y": 59160,"c":33086},
{"y":111720,"c":44587}]}

Viele Grüße

[tp1de]

*** Mein Buderus-Gateway (IP-Inside) hat am 2.2.22 (Schnapszahl) ein Firmware-Update auf 04.08.02 bekommen. ***

Seitdem existiert die Rücklauf-Temperatur auch wieder. Andere Änderungen habe ich bisher noch nicht registriert.

[yafbu]

@tp1de @tp1de
04.08.02 läuft bei mir seit kurzem auch (internal IP Gateway KM100), und bisher sind mir keine fehlenden Daten aufgefallen.

Ich habe dafür noch Probleme mit der Energieaufzeichnung. Im Log kommen regelmäßig Duplicate Meldungen von meinem SQL Adapter, über die Zeit sowohl für ems-esp.0.recordings.actualDHWPower._Months als auch für _Days und _Hours. ER_LOCK_DEADLOCK scheint nicht regelmäßig zu sein.

sql.0
2022-02-07 05:15:12.405	error	Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(80, 1597442400000, 60.2, 1, 0, 0);: Error: ER_LOCK_DEADLOCK: Deadlock found when trying to get lock; try restarting transaction (id: ems-esp.0.recordings.actualDHWPower._Months)

sql.0
2022-02-07 05:15:12.402	error	Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(80, 1592172000000, 62.1, 1, 0, 0);: Error: ER_LOCK_DEADLOCK: Deadlock found when trying to get lock; try restarting transaction (id: ems-esp.0.recordings.actualDHWPower._Months)

sql.0
2022-02-07 05:15:12.400	error	Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(80, 1584226800000, 99.6, 1, 0, 0);: Error: ER_LOCK_DEADLOCK: Deadlock found when trying to get lock; try restarting transaction (id: ems-esp.0.recordings.actualDHWPower._Months)

sql.0
2022-02-07 05:15:12.397	error	Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(80, 1594764000000, 0, 1, 0, 0);: Error: ER_LOCK_DEADLOCK: Deadlock found when trying to get lock; try restarting transaction (id: ems-esp.0.recordings.actualDHWPower._Months)

sql.0
2022-02-07 05:15:12.329	error	Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(80, 1623708000000, 11.2, 1, 0, 0);: Error: ER_DUP_ENTRY: Duplicate entry '80-1623708000000' for key 'PRIMARY' (id: ems-esp.0.recordings.actualDHWPower._Months)

sql.0
2022-02-07 05:15:12.327	error	Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(80, 1621029600000, 94.3, 1, 0, 0);: Error: ER_DUP_ENTRY: Duplicate entry '80-1621029600000' for key 'PRIMARY' (id: ems-esp.0.recordings.actualDHWPower._Months)

sql.0
2022-02-07 05:15:12.325	error	Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(80, 1618437600000, 47, 1, 0, 0);: Error: ER_DUP_ENTRY: Duplicate entry '80-1618437600000' for key 'PRIMARY' (id: ems-esp.0.recordings.actualDHWPower._Months)

sql.0
2022-02-07 05:15:12.322	error	Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(80, 1631656800000, 100.4, 1, 0, 0);: Error: ER_DUP_ENTRY: Duplicate entry '80-1631656800000' for key 'PRIMARY' (id: ems-esp.0.recordings.actualDHWPower._Months)

In Grafana sieht es bei mir so aus:
Jahresauswertung:

Das letzte Jahr passt, das wird so auch in der Bosch App angezeigt. Der Januar 22 ist hier dafür (noch?) falsch, und der Energieverlauf 2020 macht auch keinen Sinn, der sollte genauso U-förmig sein wie 2021.

Außerdem enthält die DB für Stundenwerte nur die letzten 2 Tage, und die der Tage nur die Werte der letzten ~60 Tage bzw. ein 2-Monats-Fenster.

Btw. Die Warmwasserhistorie scheint schon im original nur teilweise brauchbar zu sein. Diese hohen Ausreißer in 2 Monaten, hier in grün, zeigt auch die Bosch App

[tp1de]

@yafbu Danke für die Rückmeldung.

Die SQL-Fehlermeldungen sollten mit der Version 1.0.9 beseitigt sein. Welche Version hast Du installiert?
Aktuelle Version ist 1.0.12. Nimm mal diese und berichte, ob noch die SQL-Fehlermeldungen auftauchen.

Diese SQL-Meldungen hatten aber keinen Einfluss auf die Verbrauchsdaten. War ein Timing-Issue mit den ioBroker-internen storeState Funktionen. Benutze nun SQL-Statements.

Die Zeiträume, die Du ansprichst entsprechen den gespeicherten Daten im km200:

• Stundenwerte für den aktuellen Tag und 2 Tage zurück.
• Tageswerte für den aktuellen Monat und 2 Monate zurück.
• Monatswerte für das aktuelle Jahr und 2 Jahre zurück.

Auch ich hatte seit November 2021 für September-Dezember 2020 auf einmal Nullwerte nach dem Firmware-Update auf 04.07.07. Nun mit 04.08.02 ist das noch nicht korrigiert. Beschwerden bei Bosch/Buderus werden ignoriert.

Die Verbrauchsdaten werden jede Minute gespeichert (Anzahl der Samples). Stundenwerte sollte also 60 Samples haben, Tageswerte 1440 und Monatswerte 1440 x Anzahl der Tage. Es gibt aber einzelne Monate, wo bei mir 30-40% der Monats-Samples fehlen. Die App's rechnen dann hoch, das Portal nicht. Ich hatte dann mal die Tageswerte des Monats genommen und diese fortgeschrieben. Das Ergebnis war aber intransparent und so habe ich das wieder geändert. Bedenke bitte, dass alle Monatswerte auf den 15. gespeichert werden, auch für den aktuellen Monat.
Musst also in Grafana / Flot bis zum Ende des aktuellen Monats darstellen.

Nimm bitte die aktuelle Version 1.0.12 und gib bitte noch einmal ein Feedback.

P.S.: DHW-Werte setzen Voraus, dass WW-Vorrang eingestellt ist. D.h. Heizkreise werden abgeschaltet. Dann stimmen bei mir die Werte in etwa.

[tp1de]

Ich habe gerade die Version 1.1.0 ins stable ioBroker Repository eingestellt.
Dazu habe ich noch einmal unter der alten ESP8266 Version des EMS-ESP getestet.
V 1.1.0 funktioniert mit dem ESP8266 wird aber die letzte Version sein, in der der "alte" ESP8266 unterstützt wird.
Bitte auf den ESP32 "upgraden" wenn ihr neue Funktionen nutzen wollt.

[yafbu]

@tp1de
DHW ist auf Vorrang eingestellt, ich nehme einfach mal an das bei einem update oder sonst irgendwann im Buderus Adapter Historywerte überschrieben oder gelöscht wurden. Und die sind dann halt einfach weg Wie gesagt, es gibt auch in der App die Werte die einfach nicht Stimmen können, das hätte ich am Gaszählerstand gemerkt, wenn ich im Juli z. B. soviel Gas verbraucht hätte wie im Januar
Bei den Tages- und Monatsverbräuchen dachte ich der Adapter füllt die DB einfach auf, damit die alten Daten eben nicht verloren gehen

Die Version war die alte aus dem Stable, habe jetzt auf 1.1.0 aktualisiert und melde mich wieder.

VG
Fabian

[yafbu]

@tp1de
Manchmal gibt es auf negative Werte nach, zB nach einem Neustart der Heizung, dann rennt er in die Variablengrenzen:

Ein Energieverbrauch von -800 MWh oder tiefstnegative Temperaturen sind doch eher unwahrscheinlich ...

[tp1de]

@yafbu Im Adapter lese ich 1:1 die Werte aus der km200. Mir ist nur aufgefallen, dass bei Monaten mit vielen fehlenden Samples die Korrektur in den App's von denen im Portal abweicht. Bei mir stimmen nun die App-Werte mit denen überein, die ich im Adapter berechne.

Übrigens fehlten vor ca. 12 Monaten schon mal Monatswerte, die später aber wieder auftauchten.
Der Januar 2022 hat bei mir 34.458 Samples sollte aber 31 x 24 x 60 = 44.640 haben. Daraus ergibt sich dann ein Korrekturfaktor von 1,295 - d.h. fast 30% der Samples fehlen. Warum auch immer. Das betrifft aber nur ab und zu einzelne Monate.

Um das nachvollziehbar zu machen, habe ich die km200 JSON-Werte in States abgespeichert:

y-Wert /60 = kWh
c-Wert = Anzahl der Samples

[yafbu]

@tp1de
Ich glaube dir, dass du 1:1 die Werte aus dem km200 adapter ausließt. Ich sehe die ja auch genau so in der Bosch App - mit allen Anomalien. Das bestärkt mich nur in meiner Meinung, dass unsere großen, alteingesessenen Marktführer einfach keine gut nutzbaren smarten Anwendungen auf die Reihe bekommen

[tp1de]

Es gibt eine neue Version 1.3.1 im Beta-Repository. Dort ist die Auswertung der "recordings" so angepasst, dass alle Recordings nun gefunden und ausgewertet werden. Zusätzlich ist die Logamatic HMC300 IP-Inside und das km200HRV Lüftungssystem nun auswertbar.

Die Recordings-Strukturen sind etwas geändert. Ggfs. müsst Ihr Auswertungen / Grafiken leicht anpassen.
Die vom km200 gelesenen Werte werden zur Kontrolle 1:1 dargestellt und auf Anwenderwunsch sind nun auch die Werte ohne Datenbank in States als Werte-Array verfügbar.

[gjo]

@tp1de
Hi,
erstmal vielen Dank für den top Adapter! Aktuell nutze ich ihn um mir die Werte nur anzuschauen aber daraus soll nun mehrentstehen.
Ich hatte hier oder im Thread vom KM200 einen Beitrag über den Ersatz des RC300 bzw. RC35 durch den Einsatz vom KM200 bzw. EMS-ESP Adapter gelesen. Idee war damals die Raumtemperatur nicht über den RC sondern über andere eingebundene Raumthermometer zu übergeben.

Leider kann ich den Beitrag nicht mehr finden aber evtl. hat das ja schon jemand in Angriff genommen und davon berichten.

Mein primäres Interesse besteht darin die Raumtemperatur dynamisch zu übergeben. Sprich: der RC hängt in Raum A - bei bestimmten Konstellationen macht eine Raumtemperatur aus Raum B aber viel mehr Sinn bei der Errechnung der VL-Temp. Wenn ich die Variablen richtig verstanden habe kann ich die Raumtemperatur aber nicht überschreiben.

Stimmt das so?

Gruß

[tp1de]

@gjo
Ich wundere mich immer wieder über diese Fragestellung. Diese habe ich inzwischen mehrfach in diversen Foren gelesen.
Lass mich kurz mein Verständnis zur Heizungsregelung erklären:

1. Eine Brennwertheizung (Gas oder Öl) bzw. eine Wärmepumpe sollte mit möglichst niedrigen Systemtemperaturen laufen. D.h. alle Thermostate / Stellantriebe offen und dann mit hydraulischem Abgleich die gewünschte Raumtemperatur erreichen.
   Unterschied im Wirkungsgrad sind bei 10-12% bei fossilen Kesseln und bis zu 25% bei WP gegenüber hohen Temperaturen.
2. Vorlauftemperaturen sind dann Außentemperatur-abhängig zu regeln und die Heizkurven entsprechend einzustellen.
3. Der Thermostat (RC30/35 bzw. RC300/310 regelt dann entsprechend die Systemparameter (Vorlauftemperatur mit/ohne Mischer, Modulation, Taktung etc)
4. Raumtemperaturabhängige Regelung macht für mich nur bei kleinen Wohnungen Sinn, wo praktisch nur ein Wohn/Essbereich die Temperatur vorgibt.
5. Viele Anwender (ich auch) haben intelligente Thermostate. Die übersteuern das Regelverhalten der Anlage und im Extremfall regelt die Anlage nicht mehr vernünftig.
6. Sehr niedrige Systemtemperaturen machen die Heizungsregelung bei Heizkörpern sehr träge. Deshalb werden häufig höhere Temperaturen vom Installateur vorgegeben (Heizkurve) zu Lasten des Wirkungsgrades.

Also meine generelle Empfehlung: Außentemperatur-abhängige Steuerung.

Welche Möglichkeiten zum "Übersteuern" der Regelung gibt es?

1. KM200: Den .heatingCircuits.hcx.temporaryRoomSetpoint anpassen. Gilt dann bis zum nächsten Schaltzeitpunkt. Vorteil: stellt sich automatisch wieder zurück ! (Temperaturanpassung oder Heizkreis temporär ausschalten). Je nach eingestellten Regelungsparametern wird dann die Vorlauftemperatur entsprechend geändert.

2. ems-esp: De entsprechende Datenpunkt ist tempautotemp (neueste Firmware notwendig)
   Im ems-esp sind auch die Heizkurven veränderbar. Ich würde dass aber nicht programmatisch verwenden, da ggfs. bei Absturz / Neustart dann falsche Parameter gesetzt sind.

Ich hoffe, dass meine Ausführungen verständlich sind.

[manrum1]

@tp1de Danke, dass Du meine Anregung umgesetzt hast und die Werte auch ohne DB zur Verfügung stellst!

[gjo]

@tp1de
Bin bei dir und stimme dir auch für 95% der Anwendungsfälle zu. Bei einer offenen Bauweise und RC35 im Wohn-/Ess- Bereich ist eine Außentemperatrur gesteuerte Regelung mit Raumeinfluss 2-3K hingegen eine erweiterte Regelmöglichkeit.

Sprich die Thermostate im Referenzraum sind immer offen und der Brenner heizt nur was im Referenzraum notwendig ist um die eingestellte Raumtemperatur zu erreichen. Verhindert wird damit, dass im System viel zu warmes Wasser zirkuliert ohne tatsächlich Abnehmer zu finden. Für welchen Bautyp das sinnvoll ist muss hier jeder selber rausfinden.

Bei mir geht auch so lange gut bis ... im Referenzraum aufgrund von Frühlingsgefühlen die Fenster und Türen aufgerissen werden, die smarten HK Thermostate schließen und die eingestellte Raumtemp. nicht erreichbar ist. Dann heizt der Kessel eben deutlich hoch.

In dem Fall könnte man:

• die Raumtemp. dynamisch von einem anderen Referenzraum an die EMS Steuerung schicken
• die Heizart auf rein Außentemp. geführt ändern
• den Raumeinfluss auf 0K ändern

Problem ist bei mir noch, dass egal was ich im Adapter an den Datenpunkten ändere nicht in der Steuerung ankommt. Verändere ich aber die Datenpunkte in der EMS-ESP Steuerung klappt das. Was mache ich da falsch?

[tp1de]

@gjo sagte in Neuer Adapter EMS-ESP für Bosch Heizungen:

Problem ist bei mir noch, dass egal was ich im Adapter an den Datenpunkten ändere nicht in der Steuerung ankommt. Verändere ich aber die Datenpunkte in der EMS-ESP Steuerung klappt das. Was mache ich da falsch?

Welche Datenpunkte meinst Du denn?
Und welche EMS-ESP Firmware Version hast Du?

Hast den Access Token im Adapter-Parameter gesetzt oder im EMS-ESP Setup Bypass Access Token authorization on API calls eingeschaltet?

[tp1de]

@gjo
Ich versuche es noch einmal ..... Du hast einen "Denkfehler":

• Der Thermostat regelt das gesamte Heizsystem - d.h. die "Steuerung" ist der Thermostat
• Bei Raumtemperatur-abhängige Regelung wird das gesamte Regelverhalten von dieser einen Raumtemperatur abhängig geregelt
• einen anderen Raum als Referenz zu nehmen geht nicht

Aber warum nicht andersrum:

• Außentemperatur-abhängige Regelung
• Den Raumeinfluß kannst Du auch dabei setzen
• smarte HK Thermostate sollten per Temperatursturz offene Türen / Fenster erkennen und Solltemperatur runterregeln. Ansonsten Tür-/Fenster Sensoren einsetzen (mach ich mit Homematic)
• ggfs. den Heizbedarf per Raum berechnen und wenn dieser vorhanden ist Heizkreis einschalten, oder wenn kein Heizbedarf da ist, den Heizkreis temporär ausschalten.

Die Heizbedarfs-abhängige Regelung baue ich übrigens gerade in den Adapter ein. Noch bin ich ich aber bei mir am testen ....