HmIP-ESI und Tageswerte

[Prof. Dr. Peter Henning]

Ich habe seit heute zwei HmIP-ESI in Betrieb, Interfaces zu meinen Smartmetern. Die Teile haben 4 Kanäle: Leistung, Bezug Haupttarif, Bezug Nebentarif und Einspeisung.

In den Kanälen 2-4 werden im WebUI der RaspberryMatic neben der Gesamtenergie auch die Bezüge/Einspeisungen am heutigen und gestrigen Tag sowie in den letzten 7 und 30 Tagen angezeigt. Diese werden aber bisher in FHEM nicht ausgelesen.

Kann man die ggf. irgendwie noch herausbekommen? In den VALUES sind sie bisher nicht enthalten, da gibt es (siehe nachstehend) nur den Gesamtwert ENERGY_COUNTER.

LG

pah

Code Auswählen Erweitern

Channel 0
Channel 2

Device 003FA0C9B1C5D4
  Paramset SERVICE
    APPLICATION_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
    BOOTLOADER_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
    HARDWARE_VERSION: INTEGER [R] [Visible,Sticky] RANGE=0...65535 DFLT=0
    OS_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
    TEST_STATUS: INTEGER [R] [Visible,Sticky] RANGE=0...255 DFLT=0

Top

Channel 003FA0C9B1C5D4 0
  Paramset MASTER
    ARR_TIMEOUT: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=10
    CYCLIC_BIDI_INFO_MSG_DISCARD_FACTOR: INTEGER [R,W] [Visible,Sticky] RANGE=0...3 DFLT=1
    CYCLIC_BIDI_INFO_MSG_DISCARD_VALUE: INTEGER [R,W] [Visible,Sticky] RANGE=0...63 DFLT=50
    CYCLIC_INFO_MSG: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=1
    CYCLIC_INFO_MSG_DIS: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=1
    CYCLIC_INFO_MSG_DIS_UNCHANGED: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=20
    CYCLIC_INFO_MSG_OVERDUE_THRESHOLD: INTEGER [R,W] [Visible,Sticky] RANGE=0...2147483647 DFLT=2
    DUTYCYCLE_LIMIT: INTEGER [R,W] [Visible,Sticky] RANGE=0...255 DFLT=180
    ENABLE_ROUTING: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=1
    LOCAL_RESET_DISABLED: BOOL [R,W] [Visible,Sticky] RANGE=0...1 DFLT=0
    LOW_BAT_LIMIT: FLOAT [R,W] [Visible,Sticky] RANGE=0...25.2 DFLT=2.2 UNIT=V
    SUPPORTING_BACKBONE_OPERATION_MODE: BOOL [R,W] [Visible,Sticky] RANGE=1...1 DFLT=1
    SUPPORTING_WIRED_OPERATION_MODE: BOOL [R,W] [Visible,Sticky] RANGE=1...1 DFLT=1
  Paramset SERVICE
    APPLICATION_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
    BOOTLOADER_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
    HARDWARE_VERSION: INTEGER [R] [Visible,Sticky] RANGE=0...65535 DFLT=0
    OS_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
    TEST_STATUS: INTEGER [R] [Visible,Sticky] RANGE=0...255 DFLT=0
  Paramset VALUES
    CONFIG_PENDING: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
    DUTY_CYCLE: BOOL [R,E] [Visible,Sticky] RANGE=0...1 DFLT=0
    ERROR_CODE: INTEGER [R,E] [Visible,Sticky,Service] RANGE=0...255 DFLT=0
    ERROR_COMMUNICATION_SENSOR: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
    INSTALL_TEST: BOOL [R,W] [Internal] RANGE=0...1 DFLT=0
    LOW_BAT: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
    OPERATING_VOLTAGE: FLOAT [R,E] [Visible,Sticky] RANGE=0...25.2 DFLT=0
    OPERATING_VOLTAGE_STATUS: ENUM [R,E] [Visible,Sticky] RANGE=NORMAL...EXTERNAL DFLT=NORMAL VALUES=NORMAL,UNKNOWN,OVERFLOW,EXTERNAL
    RSSI_DEVICE: INTEGER [R,E] [Visible,Sticky] RANGE=-128...127 DFLT=0
    RSSI_PEER: INTEGER [R,E] [Visible,Sticky] RANGE=-128...127 DFLT=0
    SENSOR_ERROR: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0
    UNREACH: BOOL [R,E] [Sticky,Internal] RANGE=0...1 DFLT=0
    UPDATE_PENDING: BOOL [R,E] [Visible,Sticky,Service] RANGE=0...1 DFLT=0

Top

Channel 003FA0C9B1C5D4 2
  Paramset MASTER
    METER_OBIS_SEARCH_STRING: STRING [R,W] [Visible,Sticky] RANGE=...[0x20-0x7E]{16} DFLT=
  Paramset SERVICE
    APPLICATION_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
    BOOTLOADER_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
    HARDWARE_VERSION: INTEGER [R] [Visible,Sticky] RANGE=0...65535 DFLT=0
    OS_VERSION: STRING [R] [Visible,Sticky] RANGE=0.0.0...255.255.255 DFLT=0.0.0
    TEST_STATUS: INTEGER [R] [Visible,Sticky] RANGE=0...255 DFLT=0
  Paramset VALUES
    ENERGY_COUNTER: FLOAT [R,E] [Visible,Sticky] RANGE=0...1.09951e+11 DFLT=0 UNIT=Wh
    ENERGY_COUNTER_STATUS: ENUM [R,E] [Visible,Sticky] RANGE=NORMAL...OVERFLOW DFLT=NORMAL VALUES=NORMAL,UNKNOWN,OVERFLOW
    GAS_VOLUME: FLOAT [R,E] [Visible,Sticky] RANGE=0...1.09951e+10 DFLT=0 UNIT=m3
    GAS_VOLUME_STATUS: ENUM [R,E] [Visible,Sticky] RANGE=NORMAL...OVERFLOW DFLT=NORMAL VALUES=NORMAL,UNKNOWN,OVERFLOW

Top


[zap]

Da hat sich EQ-3 ein interessantes Konstrukt ausgedacht. Diese Werte werden in internen Systemvariablen der CCU gespeichert, die mit den eigentlichen Devices verknüpft sind (man kann tatsächlich Variablen mit Kanälen verknüpfen).

Leider werden diese Systemvariablen nicht automatisch von der CCU an FHEM über die RPC-Schnittstelle übermittelt, da Systemvariablen in der Rega-Schicht der CCU abgebildet sind, also oberhalb der RPC-Schicht. Die RPC-Schicht weiß nichts von ihrer Existenz.

In der CCU sieht man die Variablen unter Einstellungen > Systemvariable, unten den Button "systeminterne Variablen" anklicken (nur bei RaspberryMatic möglich). Wenn man  in FHEM die Systemvariablen von der CCU per "get vars .*" abholt, tauchen sie als Reading im I/O Device auf, z.B.

Code Auswählen Erweitern

svEnergyCounter_1742_00085BE9A56DEC:7=440.500000
svEnergyCounterOldVal_1742=8.500000

In den FHEM Devices kann man verknüpfte Systemvariablen mit dem Befehl "get extValues [optional_Regexp]" abholen. Dann sollten sie als Reading im Device auftauchen (evtl. gesetzte Readingfilter beachten).

Ich finde diese Art der Implementierung nicht so toll, da es bei mir immer wieder Werte durch CCU Firmware Updates verloren gehen.

[Prof. Dr. Peter Henning]

OK, Danke. das geht sogar periodisch, indem man das svEnergyCounter in das Attribut ccuGetVars einträgt.

Allerdings habe ich es bisher nicht geschafft, in den FHEM_Device mit "get extValues" irgendetwas anzuzeigen - auch ganz ohne readingfilter.

Ich finde das auch eher unwitzig, Tages- und Monatswerte lassen sich einfacher im Device selber mit dem statistics-Modul erstellen. Möglicherweise mache ich einmal täglich einen Abgleich.

LG

pah

Edit: Da muss ich jetzt mal zurückrudern. Denn keiner der Datenwerte svEnergyCounter... stimmt mit einem der Werte für den Tagesverbrauch, dem der letzten 7 Tage oder die 30 Tagesmarke überein, auch der Messwert von gestern ist nicht dabei.

Es ist lediglich

svEnergyCounter_2987_003FA0C9B1C5B9.4  748126.8

der Wert für die Gesamteinspeisung seit Zähleraktivierung (748 kWh). Das ist aber auch der Wert, den das FHEM-Device regulär liefert. Und erstaunlicherweise hat

svEnergyCounterOldVal_2987 748126.8

denselben Wert.

Endziffer .1: Immer Null. Endziffer .2: Strombezug Haupttarif. Auch hier ist der Oldval immer gleich dem aktuellen Wert. Endziffer .3: Strombezug Nebentarif, bei mir Null.

In _diesen_ Systemvariablen steckt das also nicht nicht drin, andere werden aber auch in der RaspberryMatic nicht angezeigt.

[zap]

mm, eine Idee hätte ich noch: Device-Metadaten. Muss ich aber erst mal testen.

[zap]

Die Werte sind tatsächlich in den Metadaten gespeichert. Gibt auch einen RPC Call "getMetadata" um die auszulesen. Braucht aber 2 Parameter: Eine Geräte oder Kanaladresse => ist bekannt und eine DataId => ist leider nicht bekannt.
Keine Ahnung, wie man die DataId bekommt

[Prof. Dr. Peter Henning]

Wenn ich irgendwie unterstützen kann, bitte schreiben. Fände ich nämlich höchst interessant, an die Daten dranzukommen.

LG

pah

Edit: Hat jemand soviel Erfahrung mit der RaspberryMatic Software, dass er mir sagen kann, wie diese intern die Daten der bekannten Geräte ablegt?

[zap]

Bitte morgen mal ein Update machen. Dann sollte ein Befehl "get metaData" verfügbar sein. Da es nicht dokumentiert ist, in welchem Kanal eines Gerätes die Energiewerte (oder andere Metadaten) liegen, würde ich zunächst mal bei einem HMCCUDEV alle Metadaten abfragen:

get myDev metaData

Basierend auf der Ausgabe kann man dann entweder bei einem HMCCUDEV die Werte einschränken, z.B.:

get myDev metaData energy.*

und/oder man definiert ein HMCCUCHN für den Kanal, in dem die gewünschten Metadaten gespeichert sind. Das wird vermutlich ein Kanal vom Typ ENERGIE_METER_... sein (den Schreibfehler "IE" statt "Y" hat EQ-3 schon länger drin )

[Prof. Dr. Peter Henning]

Erstmal herzlichen Dank, das klappt wunderbar (natürlich habe ich nicht bis morgen warten können, sondern das Zeug aus dem SVN geholt):

devEnergyCounter=0
devGasVolume=0
energy0=12186.400000
energy1=14519.600000
energy30=49583.800000
energy7=49583.800000
energyCounter30Days=14519.6,14143.6,16341.4,4579.2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
firstStart=0
iecPrgFirstStart=0
sensor=SENSOR_ES_IEC_SML
startValA=345252300

Heute, gestern, letzte 7 Tage und alle 30 letzten Tageswerte 

Jetzt muss ich nur noch in Ruhe überlegen, wie ich das am Besten einbauen - ich denke, ich werde den Kram jeweils kurz vor Mitternacht holen.

LG

pah

[Prof. Dr. Peter Henning]

Kleiner Nachtrag noch: Erstaunlicherweise liefern die Zähler nicht dieselben Metadaten. Ich habe zwei "moderne Messeinrichtungen", die eine ist nur für die Einspeisung meiner älteren PV-Anlage zuständig und wurde in Polen hergestellt, die zweite misst Verbrauch und Einspeisung meiner 2. PV-Anlage und wurde in Slowenien hergestellt. Eine Bemerkung darüber, warum so etwas nicht mehr aus Deutschland kommt, verkneife ich mir mal für den Moment.

Beim erstgenannten Zähler werden die Daten der vorherigen Tages nicht gespeichert. Mal sehen ob ich da am Zähler selber noch etwas umkonfigurieren kann.

Prinzipiell ist das Herankommen an die Daten schon sehr gut. Wenn ich das komplett gelöst habe, werde ich einen Wiki-Artikel dazu schreiben.

LG

pah

[zap]

Wenn es hilft: die Funktion set metaData ist in Arbeit. Damit kann man dann eigene Daten speichern oder bestehende ändern.

Angeblich werden bei allen Homematic Geräten, die man neu anlernt und die Energiemesswerte erheben, solche Metadaten angelegt. Werde das mal mit einer Steckdose vom Typ HmIp-PSM probieren. Die hat bisher keine 7 oder 30 Tagezähler

[Prof. Dr. Peter Henning]

Ich habe es allerdings anders gemeint. So ganz traue ich den Dingen nämlich noch nicht, nachstehend erkläre ich mal den Grund.

Für meinen Einspeisezähler ergibt sich im Verbrauchskanal bei get metaData

devEnergyCounter=0
devGasVolume=0
energy0=2.700000
energy1=1.900000
energy30=10.700000
energy7=10.700000
energyCounter30Days=1.9,2.7,1.9,1.6,2.6,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
firstStart=0
iecPrgFirstStart=0
sensor=SENSOR_ES_IEC_SML
startValA=0

Die Werte sind etwas seltsam, das sieht so aus, als ob Wechselrichter einen Eigenverbrauch von ein paar Wattstunden hat. Allerdings ist der Zähler seit Oktober in Betrieb - also warum sind die Datenwerte vor dem 13.März leer?

Im Einspeisekanal des Einspeisezählers bekomme ich

devEnergyCounter=0
energy0=58762.300000
energyCounter30Days=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
firstStart=0
iecPrgFirstStart=0
sensor=SENSOR_ES_IEC_SML
startValC=726771300

.
Diese Werte sind absurd: Heute war die Einspeisung 6,5 kWh (bedeckter Himmel...) energy0 im Einspeisekanal ist also _nicht_ die Energie des Tages. Und warum energyCounter30Days komplett leer ist, kann ich auch nicht erklären, denn natürlich war die Einspeisung in den vergangenen Tagen nicht Null. Es fehlen die Werte energy1 und energy7.

Witzigerweise ist das in der RaspberryMatic gerade andersherum: Dort fehlen für diesen Einspeisekanal die "Lieferung gestern" und "Lieferung heute" (das wären energy1 und energy0), aber "Lieferung 7 Tage" und "Lieferung 30 Tage" werden angezeigt, sind aber Null.

Mit anderen Worten: Der Sensor am Einspeisezähler liefert Schrott bei den Metadaten.


Für den zweiten Zähler, E.Kombi genannt, ergibt sich im Verbrauchskanal

devEnergyCounter=0
devGasVolume=0
energy0=12290.100000
energy1=15922.100000
energy30=65505.900000
energy7=65505.900000
energyCounter30Days=15922.1,14519.6,14143.6,16341.4,4579.2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
firstStart=0
iecPrgFirstStart=0
sensor=SENSOR_ES_IEC_SML
startValA=345252300

Diese Werte sind teilweise ok: Heute 12,290 kWh verbraucht, gestern 15,922 kWh. Der Zähler allerdings läuft schon seit dem 14.Februar - also warum sind die Werte im "energyCounter30Days" vor dem 13. März leer??

Im Einspeisekanal des Kombizählers erhalte ich

devEnergyCounter=0
energy0=0.000000
energy1=0.000000
energy30=0.000000
energy7=0.000000
energyCounter30Days=0.0,0.0,0.0,0.0,0.0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
firstStart=0
iecPrgFirstStart=1
sensor=SENSOR_ES_IEC_SML

Diese Werte sind vollkommen ok, weil die zweite PV-Anlage noch nicht fertig ist.

Ich werde als nächstes mal versuchen, die beiden Zählersensoren zu vertauschen.

LG

pah

[zap]

Vielleicht wäre es sinnvoll, alle Werte mal zu nullen.

Ich habs nicht so genau verstanden: sind die in der CCU angezeigten Werte identisch mit denen, die in FHEM ankommen?

[Prof. Dr. Peter Henning]

Ich habs nicht so genau verstanden: sind die in der CCU angezeigten Werte identisch mit denen, die in FHEM ankommen?

Bei dem einen Zähler (dem "Einspeisezähler") eben nicht. In der CCU fehlen energy0 und energy1, angezeigt werden in der CCU energy7 und energy30. In FHEM kommen hingegen an energy1 (mit absurdem Wert) und das Array mit den (leeren) Tageswerten.

Dennoch lichtet sich der Dschungel etwas, denn nachdem ich gestern kurz mal die beiden Sensoren vertauscht habe, ist der Wert von energy1 beim anderen Zähler heute vollkommen absurd. Schlussfolgerung: Die beiden Sensoren holen sich keineswegs die im Zähler gespeicherten Daten (dort werden alle Werte 2 Jahre lang gespeichert). Sondern berechnen die Tages-, Wochen- und Monatswerte aus den abgefragten Zählerständen.

Ich denke, ich werde mindestens einen Sensor mal auf die Werkseinstellungen zurücksetzen.

LG

pah

Edit: Sensor für den Einspeisezähler auf Werkseinstellungen zurückgesetzt, neu angelernt. Et voilà: Die Kiste kennt jetzt sowohl in der CCU, als auch in FHEM alle Metadaten energy0, energy1, energy7 und energy30 sowie das Array mit den letzten 30 Tageswerten. Die jetzt, natürlich, alle leer sind. Das Ding hat also beim ersten Anlernen einen Fehler erzeugt...

[zap]

Vielleicht hilft ein Blick in den Code der CCU weiter bei der Analyse.

Aufruf der Funktion zum Erstellen der Counter: https://github.com/eq-3/occu/blob/master/WebUI/www/rega/pages/tabs/admin/views/newdevices.htm#L1801-L1819

Die Funktion selbst: https://github.com/eq-3/occu/blob/master/WebUI/www/rega/pages/tabs/admin/views/newdevices.htm#L1233-L1338
Da scheint neben den Metadaten auch mit systeminternen Programmen und internen Systemvariablen gearbeitet zu werden (Namen siehe Code).

Um Mitternacht werden dann anscheinend die Daten aktualisiert: https://github.com/eq-3/occu/blob/master/WebUI/www/rega/pages/tabs/admin/views/newdevices.htm#L1944C3-L2057