Hallo @dibbler42,
das ist das Paket POWER_EVENT_CYCLIC. Komisch, dass da keine anderen Pakete kommen… Ich habe in meiner Kiste auch irgendwo einen HM-ES-TX-WM vergraben. Ich muss den mal rauskramen und hier einen Testaufbau machen.
Viele Grüße
Sathya
Gibts hier schon was neues? Anhand der letzten nightlies 1780 konnte ich noch keine Änderung feststellen.
Thomas
Hallo @dibbler42,
nee, leider noch nicht. wir sind spontan auf der IFA und da gerade voll im Vorbereitungsstress (https://twitter.com/search?q=%40smart_homegear). Das muss also leider noch bis nach der IFA warten. Ich habe diesen Post bereits gebookmarkt. Im Zweifel stups mich aber nach der IFA noch einmal an ;-).
Viele Grüße
Sathya
Kein Problem, baue gerade auf Stretch und latest nightly umd und verscuhe razberry auf den gleichen Pi zu bringen, eilt also nicht. Viel Spaß auf der IFA
Thomas
Hi anything new on this Topic? und wie wars auf der IFA?
Gruß
thomas
Hallo @dibbler42,
IFA war super. Tut mir leid für die späte Antwort. Jetzt bin ich aber endlich dazu gekommen, mir das Ganze anzusehen. Ich bekomme mein HM-ES-TX-WM nicht dazu, ein Paket zu senden, welches IEC_ENERGY_COUNTER beinhaltet. Hast du eine Idee? Wie dem auch sei, müsste es in OpenHAB trotzdem funktionieren. Homegear stellt die Variable als Float dar, welcher 0 zurückgibt. Die merkwürdige physikalische Seite ist für OpenHAB nicht sichtbar. Was genau war das Problem in OpenHAB? Das sollten wir jetzt schnell gelöst haben ;-).
Viele Grüße
Sathya
Also ich habe nochmal den Thread im OH Forum durchgesehen. Und laut Gerhard Riegler kommt von homegear für den IEC_ENERGY_COUNTER= kein wert und OH steigt aus. Fehler Leerer String passt nicht.
Hier mal der Trace Ausschnitt aus OH
20:48:00.313 [TRACE] [nal.communicator.client.BinRpcClient] - Client BinRpcResponse:
{
BOOT=false
ENERGY_COUNTER=0.0
GAS_ENERGY_COUNTER=0.0
GAS_POWER=0.0
IEC_ENERGY_COUNTER=
IEC_POWER=0.0
POWER=0.0
}
Oben hattest du geschrieben, dass ein String kommt. OH erwartet scheinbar einen Float, wass dann ja nicht zusammenpasst. Weiterhin hatten wir noch das Thema, dass die Konfiguration über das Homematic Tool nicht funktioniert.
Weiteres kann ich erst am Freitag rausfinden, bin gerade unterwegs.
Thomas
Hallo @dibbler42,
Oben hattest du geschrieben, dass ein String kommt.
der String ist im physikalischen Teil. Poste dann am Freitag mal, was homegear -e rc 'print_v($hg->getAllValues(<Peer ID>));' bei dir ausgibt. Bzw. im Log steht BinRpcResponse. Die Frage ist, welches der Request war. Das steht u. U. in der Logzeile darüber. Möglicherweise hilft ein Neueinlernen des Gerätes. Bei mir sieht die Ausgabe gut aus:
[IEC_ENERGY_COUNTER]
{
(Struct length=7)
{
[MAX]
{
(Float) 1.09951e+08
}
[MIN]
{
(Float) 0
}
[READABLE]
{
(Boolean) 1
}
[TYPE]
{
(String) FLOAT
}
[UNIT]
{
(String) kWh
}
[VALUE]
{
(Float) 0
}
[WRITEABLE]
{
(Boolean) 0
}
}
}
Weiterhin hatten wir noch das Thema, dass die Konfiguration über das Homematic Tool nicht funktioniert.
Ach so, das hatte ich auf die neue Firmware geschoben. Also beide Geräte haben Firmware 1.2? Das eine wird korrekt angezeigt, das andere falsch? Falls das so ist, poste die Ausgaben folgender Befehle für beide Geräte:
homegear -e rc 'print_v($hg->getParamset(<Peer ID>, 0, "MASTER"));'
homegear -e rc 'print_v($hg->getParamset(<Peer ID>, 1, "MASTER"));'
Viele Grüße
Sathya
So hier mal die Ausgabe von homegear -e rc ‘print_v($hg->getAllValues());’
(Array length=1)
{
(Struct length=7)
{
[ADDRESS]
{
(String) MEQxxxxx
}
[CHANNELS]
{
(Array length=3)
{
(Struct length=3)
{
[INDEX]
{
(Integer) 0
}
[PARAMSET]
{
(Struct length=9)
{
[CENTRAL_ADDRESS_SPOOFED]
{
(Struct length=8)
{
[MAX]
{
(Integer) 1
}
[MIN]
{
(Integer) 0
}
[READABLE]
{
(Boolean) 1
}
[TYPE]
{
(String) ENUM
}
[UNIT]
{
(String)
}
[VALUE]
{
(Integer) 0
}
[VALUE_LIST]
{
(Array length=2)
{
(String) UNSET
(String) CENTRAL_ADDRESS_SPOOFED
}
}
[WRITEABLE]
{
(Boolean) 1
}
}
}
[CONFIG_PENDING]
{
(Struct length=5)
{
[READABLE]
{
(Boolean) 1
}
[TYPE]
{
(String) BOOL
}
[UNIT]
{
(String)
}
[VALUE]
{
(Boolean) 0
}
[WRITEABLE]
{
(Boolean) 0
}
}
}
[DEVICE_IN_BOOTLOADER]
{
(Struct length=5)
{
[READABLE]
{
(Boolean) 1
}
[TYPE]
{
(String) BOOL
}
[UNIT]
{
(String)
}
[VALUE]
{
(Boolean) 0
}
[WRITEABLE]
{
(Boolean) 0
}
}
}
[LOWBAT]
{
(Struct length=5)
{
[READABLE]
{
(Boolean) 1
}
[TYPE]
{
(String) BOOL
}
[UNIT]
{
(String)
}
[VALUE]
{
(Boolean) 0
}
[WRITEABLE]
{
(Boolean) 0
}
}
}
[RSSI_DEVICE]
{
(Struct length=7)
{
[MAX]
{
(Integer) 2147483647
}
[MIN]
{
(Integer) -2147483648
}
[READABLE]
{
(Boolean) 1
}
[TYPE]
{
(String) INTEGER
}
[UNIT]
{
(String)
}
[VALUE]
{
(Integer) -59
}
[WRITEABLE]
{
(Boolean) 0
}
}
}
[RSSI_PEER]
{
(Struct length=7)
{
[MAX]
{
(Integer) 2147483647
}
[MIN]
{
(Integer) -2147483648
}
[READABLE]
{
(Boolean) 1
}
[TYPE]
{
(String) INTEGER
}
[UNIT]
{
(String)
}
[VALUE]
{
(Integer) 0
}
[WRITEABLE]
{
(Boolean) 0
}
}
}
[STICKY_UNREACH]
{
(Struct length=5)
{
[READABLE]
{
(Boolean) 1
}
[TYPE]
{
(String) BOOL
}
[UNIT]
{
(String)
}
[VALUE]
{
(Boolean) 0
}
[WRITEABLE]
{
(Boolean) 1
}
}
}
[UNREACH]
{
(Struct length=5)
{
[READABLE]
{
(Boolean) 1
}
[TYPE]
{
(String) BOOL
}
[UNIT]
{
(String)
}
[VALUE]
{
(Boolean) 0
}
[WRITEABLE]
{
(Boolean) 0
}
}
}
[UPDATE_PENDING]
{
(Struct length=5)
{
[READABLE]
{
(Boolean) 1
}
[TYPE]
{
(String) BOOL
}
[UNIT]
{
(String)
}
[VALUE]
{
(Boolean) 0
}
[WRITEABLE]
{
(Boolean) 0
}
}
}
}
}
[TYPE]
{
(String) MAINTENANCE
}
}
(Struct length=3)
{
[INDEX]
{
(Integer) 1
}
[PARAMSET]
{
(Struct length=7)
{
[BOOT]
{
(Struct length=5)
{
[READABLE]
{
(Boolean) 1
}
[TYPE]
{
(String) BOOL
}
[UNIT]
{
(String)
}
[VALUE]
{
(Boolean) 0
}
[WRITEABLE]
{
(Boolean) 0
}
}
}
[ENERGY_COUNTER]
{
(Struct length=7)
{
[MAX]
{
(Float) 838861
}
[MIN]
{
(Float) 0
}
[READABLE]
{
(Boolean) 1
}
[TYPE]
{
(String) FLOAT
}
[UNIT]
{
(String) Wh
}
[VALUE]
{
(Float) 0
}
[WRITEABLE]
{
(Boolean) 0
}
}
}
[GAS_ENERGY_COUNTER]
{
(Struct length=7)
{
[MAX]
{
(Float) 2.14748e+06
}
[MIN]
{
(Float) 0
}
[READABLE]
{
(Boolean) 1
}
[TYPE]
{
(String) FLOAT
}
[UNIT]
{
(String) m3
}
[VALUE]
{
(Float) 0
}
[WRITEABLE]
{
(Boolean) 0
}
}
}
[GAS_POWER]
{
(Struct length=7)
{
[MAX]
{
(Float) 16777.2
}
[MIN]
{
(Float) 0
}
[READABLE]
{
(Boolean) 1
}
[TYPE]
{
(String) FLOAT
}
[UNIT]
{
(String) m3
}
[VALUE]
{
(Float) 0
}
[WRITEABLE]
{
(Boolean) 0
}
}
}
[IEC_ENERGY_COUNTER]
{
(Struct length=7)
{
[MAX]
{
(Float) 1.09951e+08
}
[MIN]
{
(Float) 0
}
[READABLE]
{
(Boolean) 1
}
[TYPE]
{
(String) FLOAT
}
[UNIT]
{
(String) kWh
}
[VALUE]
{
(Float) 0
}
[WRITEABLE]
{
(Boolean) 0
}
}
}
[IEC_POWER]
{
(Struct length=7)
{
[MAX]
{
(Float) 4.29497e+07
}
[MIN]
{
(Float) 0
}
[READABLE]
{
(Boolean) 1
}
[TYPE]
{
(String) FLOAT
}
[UNIT]
{
(String) W
}
[VALUE]
{
(Float) 0
}
[WRITEABLE]
{
(Boolean) 0
}
}
}
[POWER]
{
(Struct length=7)
{
[MAX]
{
(Float) 167772
}
[MIN]
{
(Float) 0
}
[READABLE]
{
(Boolean) 1
}
[TYPE]
{
(String) FLOAT
}
[UNIT]
{
(String) W
}
[VALUE]
{
(Float) 0
}
[WRITEABLE]
{
(Boolean) 0
}
}
}
}
}
[TYPE]
{
(String) POWERMETER_IEC1
}
}
(Struct length=3)
{
[INDEX]
{
(Integer) 2
}
[PARAMSET]
{
(Struct length=2)
{
[IEC_ENERGY_COUNTER]
{
(Struct length=7)
{
[MAX]
{
(Float) 1.09951e+08
}
[MIN]
{
(Float) 0
}
[READABLE]
{
(Boolean) 1
}
[TYPE]
{
(String) FLOAT
}
[UNIT]
{
(String) kWh
}
[VALUE]
{
(Float) 0
}
[WRITEABLE]
{
(Boolean) 0
}
}
}
[IEC_POWER]
{
(Struct length=7)
{
[MAX]
{
(Float) 4.29497e+07
}
[MIN]
{
(Float) 0
}
[READABLE]
{
(Boolean) 1
}
[TYPE]
{
(String) FLOAT
}
[UNIT]
{
(String) W
}
[VALUE]
{
(Float) 0
}
[WRITEABLE]
{
(Boolean) 0
}
}
}
}
}
[TYPE]
{
(String) POWERMETER_IEC2
}
}
}
}
[FAMILY]
{
(Integer) 0
}
[ID]
{
(Integer) 104
}
[NAME]
{
(String) BM_EC_MainElectricityMeter
}
[TYPE]
{
(String) HM-ES-TX-WM
}
[TYPE_ID]
{
(Integer) 222
}
}
}
Der Request müsste der folgende n openHAB sein:
20:48:00.305 [TRACE] [nal.communicator.client.BinRpcClient] - Client BinRpcRequest:
getParamset()
MEQ0xxxxx:1
VALUES
Das eine Device hat noch die 1.0 und das andere die 1.2. Neu Pairen und ggf. auhc eine Reset machen kann ich erst am Freitag.
Thomas
Hallo @dibbler42,
Das eine Device hat noch die 1.0 und das andere die 1.2.
dann würde ich mal behaupten, dass der HomeMatic-Konfigurator die neue Firmware noch nicht unterstützt.
Der Request müsste der folgende n openHAB sein:
Ah ok. Was gibt dann Folgendes bei dir aus?
homegear -e rc 'print_v($hg->getParamset(<Peer ID>, 1, "VALUES"));'
Bei mir sieht es gut aus:
.
.
.
[IEC_ENERGY_COUNTER]
{
(Float) 0
}
.
.
.
Viele Grüße
Sathya
Das mit dem Konfigurator gehe ich sofort mit. Mal sehen, ob es einen neuen gibt. Die Abfrage gibt bei mir genau das Problem zurück:
(Struct length=7)
{
[BOOT]
{
(Boolean) 0
}
[ENERGY_COUNTER]
{
(Float) 0
}
[GAS_ENERGY_COUNTER]
{
(Float) 0
}
[GAS_POWER]
{
(Float) 0
}
[IEC_ENERGY_COUNTER]
{
(String)
}
[IEC_POWER]
{
(Float) 0
}
[POWER]
{
(Float) 0
}
}
oK, bei mir kommt ein String. D.h. ich werde wenn ich zu Hause bon mal einen Reset fahren und neu pairen und dann zurückmelden
Thomas
Hallo @dibbler42,
perfekt! Problem gefunden 
! Neu Anlernen sollte funktionieren. Falls nicht, sofort melden.
Viele Grüße
Sathya
Tip Top. Jetzt funktioniert es. Hätte ich ja auch so ausprobieren können.
Danke
Thomas
Die einzige Frage ist, ob man das Gerät irgendwie dazu überreden kann, den IEC_ENERGY_COUNTER auch zu senden? Falls du mal herausfinden solltest, wie das geht, her mit der Info ;-). Dann kann ich den Parameter korrekt implementieren.
Hallo,
ich krame dieses Thema mal aus. Ich hänge bei der Problemstellung im HM-ES-TX-WM mit Firmware 2.5 und Sensor ES-IEC einen Easymeter Q3MB1170 auslesen zu können.
System: OpenHAB2 mit Homegear (latest Stable Version: 0.7.45-3101) und einem CUL Stick auf einem Raspberry 2.
Damit habe ich aktuell zwei Probleme:
1.) Auswahl des Protokolls SML
Der HM-ES-TX-WM wurde erfolgreich mit Homegear auf Firmware 2.5 gebracht. Nun versuche ich mit dem Homematic-Manager die benötigten Werte im HM-ES-TX-WM zu setzen und scheitere beim setzen des Protokolls SML. Der Homematic-Manager bietet mir für den Parameter METER_PROTOCOLMODE nur die folgenden Einträge:
PROTOKOLL_MODE_A
PROTOKOLL_MODE_B
PROTOKOLL_MODE_C
PROTOKOLL_MODE_D
Laut der Bedienungsanleitung des ES-IEC müsste es ab Firmware >2.0 einen Eintrag SML geben. Siehe auch hier: https://files2.elv.com/public/14/1421/1 … e_data.pdf
Ein getParamsetDescription mit dem Homematic-Manager liefert mir für den Parameter auch nur das folgende:
"METER_PROTOCOLMODE": {
"DEFAULT": 3,
"FLAGS": 1,
"ID": "METER_PROTOCOLMODE",
"MAX": 3,
"MIN": 0,
"OPERATIONS": 7,
"TAB_ORDER": 4,
"TYPE": "ENUM",
"UNIT": "",
"VALUE_LIST": [
"PROTOKOLL_MODE_A",
"PROTOKOLL_MODE_B",
"PROTOKOLL_MODE_C",
"PROTOKOLL_MODE_D"
]
},
Danach kann ich SML wirklich gar nicht auswählen. Mache ich da was falsch oder fehlt da etwas in homegear?
Mit einer CCU2 konnte ich METER_PROTOCOLMODE auf SML setzen. Damit bekomme ich nun den Easymeter Q3M ausgelesen und der HM-ES-TX-WM zeigt mir Werte auf dem Display an.
Nun geht es weiter mit dem nächsten Problem:
2.) Format Datenpunkt IEC_ENERGY_COUNTER
Die aktuelle Leistung bekomme ich über den Parameter IEC_POWER problemlos übermittelt. Allerdings bekomme ich den IEC_ENERGY_COUNTER nur als String geliefert:
sudo homegear -e rc 'print_v($hg->getParamset(28, 1, "VALUES"));'
(Struct length=7)
{
[BOOT] (Boolean) 0
[ENERGY_COUNTER] (Float) 0
[GAS_ENERGY_COUNTER] (Float) 0
[GAS_POWER] (Float) 0
[IEC_ENERGY_COUNTER] (String) KP
[IEC_POWER] (Float) 0
[POWER] (Float) 0
}
Hat sonst noch jemand dieses Problem? Übersehe ich etwas?
Vielen Dank für jeglich Hilfestellung
Michael
Ich habe inzwischen etwas weiter geforscht. Den HM-ES-TX-WM mehrfach ab- und wieder angelernt. Das half auf jeden Fall nichts.
Im GitHub Repo ist in der https://github.com/Homegear/Homegear-HomeMaticBidCoS/blob/master/misc/Device%20Description%20Files/rf_es_tx_wm.xml kein Hinweis auf das “SML” Protokoll. Kann es sein, dass die Description für den HM-ES-TX-WM noch nicht der neuen Firmware entspricht, mit der SML implementiert wurde? @sathya kannst Du Dir das vielleicht mal anschauen? Vielen Dank!
Kann es weiterhin sein, dass mit der neuen Firmware der HM-ES-TX-WM den IEC_ENERGY_COUNTER wieder in einem anderen Format als String schickt? Nur muss ich zugeben, dass ich aktuell noch keine Ahnung habe wie ich diese Info zur Verfügung stellen könnte. Auch hier wieder @sathya : Ich trage sehr gerne zur Problemlösung bei, wenn Du mir einen Hinweis auf die benötigten Infos zum fixen gibts.
Viele Grüße
Michael
// UPDATE: Ich bin eben nochmal durch die homegear.log gegangen und habe folgende Einträge gefunden:
05/06/20 21:38:06.890 Module HomeMatic BidCoS: Info: IEC_ENERGY_COUNTER on channel 1 of HomeMatic BidCoS peer 28 with serial number REQ0109443 was set to 0x000013B50D.
05/06/20 21:38:06.890 Module HomeMatic BidCoS: Info: IEC_POWER on channel 1 of HomeMatic BidCoS peer 28 with serial number REQ0109443 was set to 0x00006B1B.
Zu diesem Zeitpunkt meiner Tests wurde mir IEC_POWER in OpenHAB richtig angezeigt. IEC_ENERGY_COUNTER jedoch gar nicht. Wenn ich mir 0x000013B50D konvertiere komme ich auf 1291533. Der Zählerstand zu diesem Zeitpunkt betrug 129,1533 kWh - das scheint also schon zu passen. Nur wo bleibt der Wert dann stecken?
Hallo @mok,
sorry für die späte Antwort. Falls das Problem noch aktuell ist: Es kann sein, dass es inzwischen eine neuere Gerätebeschreibung gibt, in der auch SML enthalten ist.
Dein zweites Problem ist vermutlich sehr leicht gelöst. Da ist ein Fehler in der von Homegear verwendeten Gerätebeschreibung von eQ-3. Öffne die Datei /etc/homegear/devices/0/rf_es_tx_wm.xml und suche nach <parameter id="IEC_ENERGY_COUNTER". Ersetze in diesem Block physicalString durch physicalInteger. In den properties-Block fügst du unten zudem folgendes ein:
<casts>
<decimalIntegerScale>
<factor>10000.0</factor>
</decimalIntegerScale>
</casts>
Der gesamte Block sollte also so aussehen:
<parameter id="IEC_ENERGY_COUNTER">
<properties>
<writeable>false</writeable>
<control>POWERMETER_IEC1.IEC_ENERGY_COUNTER</control>
<unit>kWh</unit>
<casts>
<decimalIntegerScale>
<factor>10000.000000</factor>
</decimalIntegerScale>
</casts>
</properties>
<logicalDecimal>
<minimumValue>0.000000</minimumValue>
<maximumValue>109951162.777500</maximumValue>
</logicalDecimal>
<physicalInteger groupId="IEC_ENERGY_COUNTER">
<size>5.0</size>
<operationType>command</operationType>
</physicalInteger>
<packets>
<packet id="IEC_POWER_EVENT_CYCLIC">
<type>event</type>
</packet>
<packet id="IEC_POWER_EVENT">
<type>event</type>
</packet>
</packets>
</parameter>
Dann sollte der Wert korrekt übertragen werden.
Viele Grüße
Sathya
Im nächsten Nightly habe ich die XML auch entsprechend korrigiert.
Hi,
ich habe einen Zweiwegezähler und brauche auch IEC_ENERGY_COUNTER Daten von Channel 2. Ich habe die XML entsprechend angepasst und bekomme nun in openhab keine Fehler mehr wie diesen:
2021-02-12 09:48:46.772 [ERROR] [ternal.handler.HomematicThingHandler] - Can’t convert FLOAT value ‘Bñ’ with DecimalTypeConverter for ‘XXXXX:2#IEC_ENERGY_COUNTER’
In HG sieht es auch ganz gut aus:
02/12/21 10:48:27.518 Module HomeMatic BidCoS: Info: IEC_ENERGY_COUNTER on channel 1 of HomeMatic BidCoS peer 30 with serial number XXXXX was set to 0x0002E3671C.
02/12/21 10:48:27.797 Module HomeMatic BidCoS: Info: IEC_ENERGY_COUNTER on channel 2 of HomeMatic BidCoS peer 30 with serial number XXXXX was set to 0x0005433BC8.
Diese Hex-Werte sind realistische Zählerwerte, wobei der Faktor zwar nicht stimmt (4.845 kWh lt Display am Zähler und 48.457.500 (kWh?) lt HG) wobei ich hoffe, dass das nicht ursächlich für folgendes Problem ist.
In openhab kommen leider nur 0-Werte an:
2021-02-12 10:52:52.664 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Double) value ‘0.0’ for ‘XXXXX:1#IEC_ENERGY_COUNTER’ from gateway with id ‘XXXXX’
2021-02-12 10:52:52.938 [DEBUG] [ommunicator.AbstractHomematicGateway] - Received new (Double) value ‘0.0’ for ‘XXXXX:2#IEC_ENERGY_COUNTER’ from gateway with id ‘XXXXX’
2021-02-12 12:07:59.962 [TRACE] [nicator.server.BinRpcResponseHandler] - Event BinRpcMessage: system.multicall()
[
{
methodName=event
params=
[
RF-XXXX
XXXX:1
IEC_ENERGY_COUNTER
0.0
]
}
Ich habe das Gerät (mit unterschiedlichen Firmwareständen) mehrfach an- und abgelernt, aber es kommt immer wieder mit der gleichen ID online. Ggf. war es nicht sauber abgelernt?
Kann ich davon ausgehen, dass seitens HG alles korrekt ist oder gäbe es noch was zum prüfen bevor ich die openhab community verrückt mache ;-)?
Da sich Channel 2 jetzt wie Channel 1 verhält habe ich das ich die og. Anpassung im XML auf Github vorgenommen. Ich hoffe ich habe es richtig gemacht. Es war meine erste Änderung in Github.
Besten Dank vorweg
Hallo,
ich erlaube mir mal, diesen alten Thread zu reaktivieren, da ich ebenfalls das Problem habe, dass IEC_ENERGY_COUNTER keine Werte überträgt, diese aber in der log-Datei angezeigt werden. Ich betreibe den HM-ES-TX-WM mit ES-IEC (Firmware 2.5) über einen CUL-Stick, homegear läuft bei mir derzeit Version 0.7.51-3497 im Docker-Container (ich hatte aber auch schon ohne Erfolg die testing und nightly Versionen ausprobiert). IEC_POWER wird korrekt übertragen, IEC_ENERGY_COUNTER wird korrekt gelogt, übertragen wird aber nur 0.
Ich hätte die Antwort von @sathya eigentlich so verstanden, dass es mit den zitierten Einstellungen in der Datei /etc/homegear/devices/0/rf_es_tx_wm.xml betreffend den <parameter id="IEC_ENERGY_COUNTER" funktionieren sollte, tut es bei mir aber leider nicht (die Einstellungen sind bei mir so wie in dem alten Post).
Wenn ich diesen Thread anschaue, scheint @bitte-ein-bit genau das gleiche Problem zu haben (und sich über ein parsen der log-Datei geholfen zu haben).
Von daher die Frage, sollte die Übertragung von Werten des IEC_ENERGY_COUNTER eigentlich funktionieren, oder funktioniert diese generell nicht? Falls ersteres der Fall ist: welche Informationen betreffend meine Installation könnten helfen, den Fehler zu finden? Falls zweiteres der Fall ist: besteht die Chance, dass das Problem in Zukunft gefixt wird oder bleibt nur der Umweg über ein parsen der log-Datei?
Viele Grüße,
Multani