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

[tp1de]

@mango1402 Danke für Dein Feedback Manfred. Dann werde ich mich mal mit dem ioBroker repository auseinandersetzen. Kann sein, dass ich dann ggfs. die Versionsnummer erhöhen muss. Mal sehen ob ich alles richtig verstanden habe ...

Grüße Thomas

[mpenno]

@tp1de Du fragtest mich, welche Datenbankversion ich benutze. Ich verwende die InfluxDB2.0.

Ich habe mal Deinen Adapter und den Influx-Adapter auf "Debug" gestellt, um vielleicht etwas mehr zu den immer wiederkehrenden Error-Meldungen herauszubekommen.

Ich meine diese hier (Log-Modus: Info)

2022-01-05 17:27:47.585 - info: influxdb.0 (4003) Connected!
2022-01-05 17:28:13.673 - info: ems-esp.0 (3975) End reading km200 data-structure: 117 fields found
2022-01-05 17:28:13.675 - info: ems-esp.0 (3975) write km200 file:/opt/iobroker/iobroker-data//ems-esp/km200.csv
2022-01-05 17:28:13.700 - info: ems-esp.0 (3975) start initializing km200 states
2022-01-05 17:28:38.725 - info: ems-esp.0 (3975) end of initializing km200 states
2022-01-05 17:28:43.824 - info: ems-esp.0 (3975) km200:true 300 secs
2022-01-05 17:28:43.825 - info: ems-esp.0 (3975) recordings:true hour
2022-01-05 17:28:44.385 - warn: influxdb.0 (4003) Error in received multiQuery: Exception: Array element #2: Query messing
2022-01-05 17:28:51.072 - warn: influxdb.0 (4003) Error in received multiQuery: Exception: Array element #2: Query messing
2022-01-05 17:28:58.167 - warn: influxdb.0 (4003) Error in received multiQuery: Exception: Array element #2: Query messing
2022-01-05 17:29:06.478 - warn: influxdb.0 (4003) Error in received multiQuery: Exception: Array element #2: Query messing
2022-01-05 17:29:14.518 - warn: influxdb.0 (4003) Error in received multiQuery: Exception: Array element #2: Query messing
2022-01-05 17:29:19.238 - warn: influxdb.0 (4003) Error in received multiQuery: Exception: Array element #2: Query messing
2022-01-05 17:32:11.293 - info: smartmeter.0 (550) Received 7 values, 3 updated
2022-01-05 17:37:13.154 - info: smartmeter.0 (550) Received 7 values, 3 updated

Wenn beide Adapter auf Debug stehen, hagelt es natürlich nur so von Meldungen, wenn ich aber den wesentlichen Teil herauskopiere, scheint er die "Query" nicht zu mögen:

2022-01-05 17:26:24.470  - debug: ems-esp.0 (3803) sendTo "query" to system.adapter.influxdb.0 from system.adapter.ems-esp.0: drop series from "ems-esp.0.recordings.actualDHWPower._Months";
2022-01-05 17:26:24.472  - debug: influxdb.0 (3263) Incoming message query from system.adapter.ems-esp.0
2022-01-05 17:26:24.473  - warn: influxdb.0 (3263) Error in received multiQuery: Exception: Array element #2: Query messing

Hier mit einem größerem Log-Ausschnitt:

2022-01-05 17:26:24.289  - debug: influxdb.0 (3263) init timed Relog: getState ems-esp.0.heatSources.hs1.flameStatus:  Value=0, ack=true, ts=1641399519190, lc=1641399519190
2022-01-05 17:26:24.290  - debug: influxdb.0 (3263) timed-relog ems-esp.0.heatSources.hs1.flameStatus, value=0, lastLogTime=1641399969289, ts=1641399984290
2022-01-05 17:26:24.290  - debug: influxdb.0 (3263) Datatype ems-esp.0.heatSources.hs1.flameStatus: Currently: number, StorageType: false
2022-01-05 17:26:24.290  - debug: influxdb.0 (3263) Write Point: ems-esp.0.heatSources.hs1.flameStatus values:{"value":0,"time":"2022-01-05T16:26:24.290Z","from":"system.adapter.influxdb.0","q":0,"ack":true} options: null
2022-01-05 17:26:24.328  - debug: influxdb.0 (3263) Point written to iobroker
2022-01-05 17:26:24.470  - debug: ems-esp.0 (3803) sendTo "query" to system.adapter.influxdb.0 from system.adapter.ems-esp.0: drop series from "ems-esp.0.recordings.actualDHWPower._Months";
2022-01-05 17:26:24.472  - debug: influxdb.0 (3263) Incoming message query from system.adapter.ems-esp.0
2022-01-05 17:26:24.473  - warn: influxdb.0 (3263) Error in received multiQuery: Exception: Array element #2: Query messing
2022-01-05 17:26:24.473  - debug: influxdb.0 (3263) sendTo "query" to system.adapter.ems-esp.0 from system.adapter.influxdb.0
2022-01-05 17:26:26.476  - debug: ems-esp.0 (3803) sendTo "storeState" to system.adapter.influxdb.0 from system.adapter.ems-esp.0
2022-01-05 17:26:26.478  - debug: influxdb.0 (3263) Incoming message storeState from system.adapter.ems-esp.0
2022-01-05 17:26:26.478  - debug: influxdb.0 (3263) storeState: store 1 state for ems-esp.0.recordings.actualDHWPower._Months
2022-01-05 17:26:26.479  - debug: influxdb.0 (3263) Write Point: ems-esp.0.recordings.actualDHWPower._Months values:{"value":0,"time":"2022-01-14T23:00:00.000Z","from":"","q":0,"ack":true} options: null
2022-01-05 17:26:26.479  - debug: influxdb.0 (3263) sendTo "storeState" to system.adapter.ems-esp.0 from system.adapter.influxdb.0
2022-01-05 17:26:26.529  - debug: influxdb.0 (3263) Point written to iobroker

Ich könnte auch ein größeres Log zur Verfügung stellen.

Viele Grüße (und ein frohes Neues!)

[tp1de]

@mpenno Influxdb 2.0 habe ich nicht installiert und kann ich deshalb nicht testen.
Unterstützt wird aktuell nur Version 1.8. Die Query Syntax hat sich geändert.

Ich versuche den Adapter ins offizielle ioBroker-Repository zu kommen.
Das ist bisher sehr viel Aufwand gewesen. Danach kann ich ggfs. Influxdb 2.0 testen .... musst also etwas warten oder mySQL bzw. die Version 1.8 verwenden.

[mpenno]

@tp1de Alles klar und viel Erfolg! Funktioniert ja so weit sehr gut.
VG

[tp1de]

@mpenno Ich habe gerade eine neue Version 1.0.1 ins Github hochgeladen.
Auch habe ich bei mir mal Influxdb 2.1 im Docker installiert und wie es aussieht sollte es jetzt funktionieren.

Kannst Du vielleicht mal testen?

Auf welcher Hardware läuft bei Dir Influxdb 2.x?
(Ich suche noch nach einer Anleitung für den Raspi 4 - Raspberry PI OS 64 bit läuft seit einiger Zeit )

[mpenno]

@tp1de

Bei mir läuft alles in eigenen Docker-Containern auf der Synology (ds415+). Den Arbeitsspeicher habe ich mal auf 8G erhöht. Unteranderem laufen dort folgende Container:

• ioBroker
• influx
• grafana

Somit war der Wechsel von InfluxDB1.8 auf 2.1 gar nicht so schwierig. Der Migrations-Assistent war ganz gut und ich musste keine Angst vor den Verlust der "alten" Daten in der DB 1.8 haben, da diese automatisch nach 2.1 in ein neues Docker-Volume "migriert" wurden.

Viele Grüße

[tp1de]

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

Bei mir läuft alles in eigenen Docker-Containern auf der Synology (ds415+)

Ja meine bisherige ioBroker Installation läuft seit 3 Jahren auf einer DS716+ mit 8GB in 7 Docker-Containern. Influxdb 2.1 habe ich mal parallel im Container installiert zum Testen.

Bisher hatte ich zusätzlich 2 Raspi's im Multihost Modus. Den habe ich aber aufgelöst und habe einen Raspi4 als neues System parallel am laufen. Mit nur 4 GB ist der deutlich performanter als die DS. (OS auf SSD Stick).

Schreib mal, ob bei Dir Influxdb 2.1 mit dem Adapter auch funktioniert.

[mpenno]

@tp1de
Die Installation ist gerade fertig. Vorher habe ich Instanz und Adapter brav gelöscht und dann neu installiert.

Das sind die bisherigen Meldungen:

2022-01-07 17:55:54.601 - info: host.iobroker instance system.adapter.ems-esp.0 started with pid 19029
2022-01-07 17:55:56.333 - info: ems-esp.0 (19029) starting. Version 1.0.1 in /opt/iobroker/node_modules/iobroker.ems-esp, node: v12.22.6, js-controller: 3.3.22
2022-01-07 17:55:56.411 - info: ems-esp.0 (19029) start reading km200 data-structure
2022-01-07 17:56:39.354 - info: ems-esp.0 (19029) End reading km200 data-structure: 117 fields found
2022-01-07 17:56:39.355 - info: ems-esp.0 (19029) write km200 file:/opt/iobroker/iobroker-data//ems-esp/0/km200.csv
2022-01-07 17:56:39.358 - info: ems-esp.0 (19029) start initializing km200 states
2022-01-07 17:57:05.676 - info: ems-esp.0 (19029) end of initializing km200 states
2022-01-07 17:57:05.677 - info: ems-esp.0 (19029) km200:true 300 secs
2022-01-07 17:57:05.797 - info: influxdb.0 (4003) enabled logging of ems-esp.0.recordings.actualPower._Hours, Alias=false
2022-01-07 17:57:05.802 - info: influxdb.0 (4003) enabled logging of ems-esp.0.recordings.actualDHWPower._Hours, Alias=false
2022-01-07 17:57:05.805 - info: influxdb.0 (4003) {"common":{"custom":{"influxdb.0":{"changesOnly":false,"debounce":0,"retention":0,"changesRelogInterval":0,"maxLength":3,"changesMinDelta":0,"aliasId":"","enabled":true}}},"from":"system.adapter.influxdb.0","user":"system.user.admin","ts":1641574625788}
2022-01-07 17:57:05.807 - info: influxdb.0 (4003) enabled logging of ems-esp.0.recordings.actualPower._Days, Alias=false
2022-01-07 17:57:05.810 - info: influxdb.0 (4003) enabled logging of ems-esp.0.recordings.actualDHWPower._Days, Alias=false
2022-01-07 17:57:05.811 - info: influxdb.0 (4003) enabled logging of ems-esp.0.recordings.actualPower._Months, Alias=false
2022-01-07 17:57:05.812 - info: influxdb.0 (4003) {"common":{"custom":{"influxdb.0":{"changesOnly":false,"debounce":0,"retention":0,"changesRelogInterval":0,"maxLength":3,"changesMinDelta":0,"aliasId":"","enabled":true}}},"from":"system.adapter.influxdb.0","user":"system.user.admin","ts":1641574625790}
2022-01-07 17:57:05.814 - info: influxdb.0 (4003) enabled logging of ems-esp.0.recordings.actualDHWPower._Months, Alias=false
2022-01-07 17:57:05.815 - info: influxdb.0 (4003) {"common":{"custom":{"influxdb.0":{"changesOnly":false,"debounce":0,"retention":0,"changesRelogInterval":0,"maxLength":3,"changesMinDelta":0,"aliasId":"","enabled":true}}},"from":"system.adapter.influxdb.0","user":"system.user.admin","ts":1641574625790}
2022-01-07 17:57:05.851 - info: influxdb.0 (4003) {"common":{"custom":{"influxdb.0":{"changesOnly":false,"debounce":0,"retention":0,"maxLength":3,"changesMinDelta":0,"aliasId":"","enabled":true}}},"from":"system.adapter.influxdb.0","user":"system.user.admin","ts":1641574625790}
2022-01-07 17:57:05.852 - info: influxdb.0 (4003) {"common":{"custom":{"influxdb.0":{"changesOnly":false,"debounce":0,"retention":0,"changesRelogInterval":0,"maxLength":3,"changesMinDelta":0,"aliasId":"","enabled":true}}},"from":"system.adapter.influxdb.0","user":"system.user.admin","ts":1641574625790}
2022-01-07 17:57:05.852 - info: influxdb.0 (4003) {"common":{"custom":{"influxdb.0":{"changesOnly":false,"debounce":0,"retention":0,"changesRelogInterval":0,"maxLength":3,"changesMinDelta":0,"aliasId":"","enabled":true}}},"from":"system.adapter.influxdb.0","user":"system.user.admin","ts":1641574625793}
2022-01-07 17:57:10.748 - info: ems-esp.0 (19029) recordings:true hour

Bis jetzt nichts auffälliges :-)

Das mit den neuen Raspi merke ich mir mal. Bestimmt etwas energieeffizienter als die DS.

VG Michael

[tp1de]

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

Die Installation ist gerade fertig. Vorher habe ich Instanz und Adapter brav gelöscht und dann neu installiert.

Das ist nun wirklich unnötiger Aufwand - einfach von Github neu installieren reicht.

Super, dass auch bei Dir alles erst mal funktioniert. Dann schau ich mal, dass ich den Adapter ins offizielle Repository bekomme.

P.S.: Bei mir sind die Monats-Verbrauchswerte für 11.2021 und 09. - 11.2020 falsch. Letztere sind auf einmal 0. Waren bis November noch vorhanden !
Wie sieht die Monats-Verbrauchsstatistik bei Dir aus? Sinnvolle Werte?

[mpenno]

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

Das ist nun wirklich unnötiger Aufwand - einfach von Github neu installieren reicht.

Ach, das wusste ich nicht.

Wie sieht die Monats-Verbrauchsstatistik bei Dir aus? Sinnvolle Werte?

Na da sprichst Du bei mir ein Thema an. Aus den Werten versuche ich mir schon lange einen Reim zu machen und bin deshalb vom km200 Adapter zu diesem hier gewechselt.
Ich würde gerne einen Bezug zu den Verbrauchswerten herstellen, die mir am RC300-Bedienpanel angezeigt werden.
Da zeigt mir das Bedienpanel folgende 24h Werte (scheinen vom letzten Kalendertag (sprich 6.1.) zu sein, da sich alle Werte erst beim Tageswechsel ändern) gerade an:

... und die 30d Durchschnittswerte auf Seite 2:

Wenn ich mir die Datenpunktaufzeichnung mit Grafana darstelle:

Steht da

• 49 kWh für gesamt Gas-Verbrauch und
• 7 kWh für Warmwasser

Passen aber nicht zum Panel mit:

• 54,9kWh und
• 16,1kWh

Was bei den Datenpunkten gut passt: Bilde ich eine Tagessumme aus den einzelnen Stunden-Werten, entspricht diese auch dem Datenpunkt des Tageswertes.

Die Monatswerte checke ich gleich mal.

[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