Firmware Update von HM-ES-TX-WM funktioniert nicht

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 :slight_smile:! 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?

2 Likes

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

1 Like

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