UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[mpenno]

Die Datenpunktwerte für den Zeitpunkt 07.01. um 00:01 Uhr haben sich gerade erhöht. Keine Ahnung warum [Edit: nun klar: diese Werte werden bis zum nächsten Tag stündlich aktualisiert].
Auf der rechten Seite einmal die Monatswerte. Hier gibt es im Zeitraum vom 14.10.2021 bis heute nur drei Datenpunkte (15.10., 15.11 und 15.12.). Am 15.1. wird es wahrscheinlich den nächsten Punkt geben.

Auf der linken Seite, mit allen Tageswerten, habe ich 0-Werte vom 1.11. bis 5.11.

VG

[tp1de]

@mpenno mein RC310 zeigt keine Verbrauchswerte an. Ich vergleich mit dem Bosch-Junkers-Portal:
https://www.junkers-homecom.de/portal
Die Werte die ich auslese und die dort angezeigt werden sind identisch. So sieht es im Bosch-Portal aus:

Wenn ich über die myBuderus App die Verbräuche ansehe sind die wieder leicht anders:

Größte Abweichung im November 2021 mit fast 1000 kWh !

Die Werte die ich von der km200 / ip-inside erhalte habe ich als separate states aufgenommen.
Die y-Werte werden durch 60 geteilt (Samplerate 1 Minute). c sind glaube ich die Anzahl der Samples.

[tp1de]

@tp1de Die recordings werden übrigens vom Adapter nur alle 60 Minuten gelesen und die Monatswerte auf den 15. eines jeden Monats in die DB eingetragen. Monatswert für den aktuellen Monat sind erst nach 8-9 Tagen verfügbar . Ich stelle diese als Balkendiagramm mit Flot dar:

[tp1de]

@tp1de Ich habe inzwischen nachvollzogen, dass die APPs (es gibt mehrere) anders rechnen:

Es wird berechnet wie viele Samples zu erwarten sind. Z.B. November 30 Tage * 24 Stunden *60 Minuten = 43.200
Die aktuellen Samples (c) waren bei mir : 31.142. Die theoretischen Samples / Ist-Samples ergibt den Faktor: 1,3872
(warum im November - und nur dort - die Abweichung so groß war weiß ich nicht. Normalerweise fehlen nur 2-3% der Samples)

Wenn ich die y-Werte mit diesem jeweiligem Monatsfaktor berechne erhalte ich die APP-Monatswerte !
Bisher hatte ich nur gegen das Portal verglichen !

Ich habe eine neue Version im Github hochgeladen (1.0.2). In dieser sind die Korrekturen des Energieverbrauches wie oben beschrieben implementiert.

[mpenno]

@tp1de
Ich bin noch bei Version 1.0.1:

Mein Vergleich der stündlichen Verbrauchswerte (welche in die Datenbank geschrieben werden) zum Diagramm im Bosch-Junkers Portal stimmen perfekt überein:

Auch die Monatswerte der Version 1.0.1 passen recht gut:

Bei mir weicht nur Oktober ab. (Am 17.12. habe ich erst mit dem Adapter angefangen, da werden sicher ein paar Werte fehlen).

Im Vergleich:

• Oktober: Portal 759kkWh zu Datenbank: 687kWh
• November: Portal 990,9kWh zu Datenbank: 986kWh
• Dezember: Portal 1.864kWh zu Datenbank: 1.860kWh

[tp1de]

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

Bei mir weicht nur Oktober ab. (Am 17.12. habe ich erst mit dem Adapter angefangen, da werden sicher ein paar Werte fehlen).

Es ist egal, wann der Adapter implementiert wird. Wenn Du im Portal Daten für 12 Monate oder länger hast, dann muss auch der Adapter diese Daten haben. Beide fragen diese ja im Moment der Auswertung per verschlüsseltem WEB-API ab. Monatswerte bis 24 Monate zurück,
Ich habe noch nicht rausgefunden, ob diese Verbrauchsdaten im km200, im RC300/310 oder im Kessel gespeichert werden.

Weichen die Portal-Daten bei Dir auch von denen in der APP (myBuderus / HomeCom) ab?
In der States-Struktur speichere ich ja inzwischen auch 1:1 die Daten ab die geliefert werden - Monatswerte je Jahr.

Zurück kommt ein JSON mit folgendem header:

und einen Eintrag je Monat (JAN-DEZ):

Y ist der Wert, c die Anzahl der Samples (alle 1 Minute).
Bei mir für Jan 2021 44.499 - theoretisch sollten es 31x24x60 = 44.640 sein - es fehlen also (nur) 141 Samples oder 0,31%.
Im November 2021 fehlten aber (warum auch immer) 38% !!! Deshalb die große Abweichung.

Ich vermute, dass bei Dir die Abweichung jeweils gering ist.

Wie gesagt, mit der aktuellen Adapterversion im Github berücksichtige ich (wie in der App) diese Abweichung und korrigiere die Werte entsprechend.

[yafbu]

@tp1de Hallo! Vielen Dank für deine Arbeit, das sieht ziemlich gut aus! Vor allem die Kombination EMS-ESP + KMxxx und die Vorauswertung der Energiedaten finde ich Klasse.
Ich habe deinen Adapter mit einem KM200 und einem Gateway E32 installiert, allerdings bekomme ich laufend
"sql.0 2022-01-10 06:40:28.418 info No Data"
Einträge im Log. Der "alte" KM200" Adapter logt zuverlässig seit über einem Jahr in die Datenbank, und Grafana wertet aus.
Außerdem erhalte unterhttp://<iobroker-ip>/#tab-ems-esp "File tab_m.html not found"
Meine iobroker intallation läuft auf eine RPi4 im Docker Container (und ist zugegeben nicht ganz aktuell, d.h. v3.2.16). Wenn ich Richtung Docker was testen kann sag gerne bescheid.
Viele Grüße
Fabian

[tp1de]

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

Außerdem erhalte unterhttp://<iobroker-ip>/#tab-ems-esp "File tab_m.html not found"

Danke für das Feedback Fabian, dieser Fehler ist mir bei all den Änderungen "reingerutscht". Der Adapter hat in der Tab-Liste nichts zu suchen.
Ich habe das inzwischen geändert. Der Adapter muss dann aber deinstalliert werden und dann neu über Github installiert werden.
(Einstellungen vorher über Aufruf der Instanz ggfs. sichern)

allerdings bekomme ich laufend
"sql.0 2022-01-10 06:40:28.418 info No Data"

Muss klären was das ist. Was heist laufend? wie häufig?

Grüße Thomas

[tp1de]

Ich habe gerade die Version 1.0.3 hochgeladen in der es einen neuen Konfigurations-Parameter "Statistik" gibt.
Standardmäßig disabled - bisher war die Funktion immer enabled.
Statistik ermittelt die Anzahl der Brennerstarts pro 24 Stunden, Brennerauslastung je Stunde etc.
Das setzt aber voraus, dass die Daten in der Datenbank vorhanden sind. Ich vermute, dass die benutzte getHistory-Funktion den Info-Eintrag erstellt, wenn keine Daten vorhanden sind.

@yafbu Kannst Du bitte mal testen Fabian?

[yafbu]

@tp1de Mit der 1.0.3 steht der Adapter nicht mehr in der Tab-Liste.
Die Logmeldungen kamen in 5er Blöcken jede Minute, mit der 1.0.3 sind sie aber noch nicht wieder aufgetaucht. Ich hatte erst den Konfigurations-Parameter "Statistik" ausgeschaltet, und erst nach dem ersten Start aktiviert.
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.

sql.0 2022-01-11 06:38:29.100	info	No Data

sql.0 2022-01-11 06:37:29.108	info	No Data
sql.0 2022-01-11 06:37:29.105	info	No Data
sql.0 2022-01-11 06:37:29.103	info	No Data
sql.0 2022-01-11 06:37:29.101	info	No Data
sql.0 2022-01-11 06:37:29.099	info	No Data

sql.0 2022-01-11 06:36:29.107	info	No Data
sql.0 2022-01-11 06:36:29.106	info	No Data
sql.0 2022-01-11 06:36:29.103	info	No Data
sql.0 2022-01-11 06:36:29.102	info	No Data
sql.0 2022-01-11 06:36:29.100	info	No Data

sql.0 2022-01-11 06:35:29.113	info	No Data
sql.0 2022-01-11 06:35:29.111	info	No Data
sql.0 2022-01-11 06:35:29.105	info	No Data
sql.0 2022-01-11 06:35:29.101	info	No Data
sql.0 2022-01-11 06:35:29.098	info	No Data

sql.0 2022-01-11 06:34:29.105	info	No Data

Viele Grüße
Fabian

[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 :face_with_rolling_eyes: 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 :blush:
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