Neue Release-Candidate/Test Version (3.47.10.20190712) verfügbar

[LibertyX]

Wenn wir allerdings jemanden hätten der bereits einen HM-ES-TX-WM mit 2.0 hat und hier mitesten könnte wäre das natürlich super. Ich will nämlich ungern nun meinen hier auf v2 bringen und habe hier leider keinen anderen frei um das selbst noch testen zu können.

Hier ist aber zu beachten, dass mit dieser Firmware nur noch der ES-IEC Sensor unterstützt wird, die Unterstützung für alle übrigen Sensoren wurde in dieser FW entfernt. Wer das also testen wollen sollte, der sollte das nur tun, wenn er einen ES-IEC Sensor daran betreibt, sonst ist die fehlerhafte Anzweige das kleinste Problem.

Nach support rufen? Ist das nicht etwas für "Weicheier"? Aber mal im Ernst: ich werde das gerne mal ansprechen sobald ich zeit dafür finde. Trotzdem wäre es IMHO nicht schlecht wir könnten das selbst bereits lösen bzw. einen Workaround erarbeiten, da dies sicherlich schneller zum gewünschten Ergebnis führt.

Hilft allerdings nur den RaspMatic Usern, den Usern der CCU3 die das Problem auch haben erst einmal nicht.

[jp112sdl]

Hilft allerdings nur den RaspMatic Usern, den Usern der CCU3 die das Problem auch haben erst einmal nicht.

Ich gehe mal ganz naiv davon aus, dass man bei eQ3 den Fehler schon mitbekommen hat und ggf. in Kürze eine gefixte Version nachschiebt.
Insofern sind die Anstrengungen eines Fixes nur in Bezug auf RaspberryMatic relativ zu betrachten.

Hier ist aber zu beachten, dass mit dieser Firmware nur noch der ES-IEC Sensor unterstützt wird, die Unterstützung für alle übrigen Sensoren wurde in dieser FW entfernt. Wer das also testen wollen sollte, der sollte das nur tun, wenn er einen ES-IEC Sensor daran betreibt, sonst ist die fehlerhafte Anzweige das kleinste Problem.

Ich werde meinem Testsystem mal einen V 2.x HM ES TX WM anbieten und schauen, wie sich die WebUI darstellt.

Das ist in der Tat eine gute Frage. Allerdings denke ich wird momentan zumindest die absolute Minderheit einen HM-ES-TX-WM mit v2.0 firmware haben, sodass es mir IMHO gerechtfertigt erscheint diesen Workaround mit der nächsten RaspberryMatic einfach so auszuliefern, auch auf die Gefahr hin das dann die Anzeige des HM-ES-TX-WM mit 2.0 firmware nicht korrekt geht.

Mir solls recht sein, da ich nur "alten" HM RF Kram im Einsatz habe.

[jp112sdl]

HM-ES-TX-WM mit FW Version 2.2 und original ausgelieferter webui.js:

HM-ES-TX-WM mit FW Version 2.2 und modifizierter RaspberryMatic-webui.js:

[jmaus]

HM-ES-TX-WM mit FW Version 2.2 und original ausgelieferter webui.js:
Bildschirmfoto 2019-07-08 um 19.20.24.png

HM-ES-TX-WM mit FW Version 2.2 und modifizierter RaspberryMatic-webui.js:
Bildschirmfoto 2019-07-08 um 19.19.13.png

Interessant. Dazu würde mich dann natürlich das enstprechende Debugging interessieren was so eine v2 als "paramSet.METER_TYPE" bzw. "this.opts.chType" zurückliefert an der besagten stelle.

[jp112sdl]

paramSet.METER_TYPE

ist weiterhin "undefined"

Alle anderen Parameter sehen so aus:

[jp112sdl]

Und hier noch mal mit der alten Version 1.0 auf dem HM-ES-TX-WM:

[darkbrain85]

Hallo Jens!

Nach dem Update mit 3.47.10.20190708 habe ich nach dem reboot massive Probleme mit RF classic Geräten. In diesem Fall aufgefallen bei einem HM-LC-Dim1T-FM und der HM-OU-CFM-TW.

Nach dem Dimmvorgang auf z.B. 40% ist der Dimmer wieder auf 0% gesprungen ohne das die Zentrale das mitbekommen hat. In der WebUI war dann das Zahnrad zu sehen. Erneute Änderungen führten dann sporadisch zu Komm. Störungen.
Der MP3 Gong hat beim Einschalten über die WebUI sporadisch Kommunikationsstörungen erzeugt. Manchmal ging es, manchmal nicht...

Gibt es Änderungen die das Verhalten erklären? Eine Weile nach dem zweiten reboot ist jetzt gerade alles ruhig. Dutycycle kann ich ausschließen. War selbst bei den ganzen Tests gerade mal bei 9% (große Wired Installation).

[jmaus]

Gibt es Änderungen die das Verhalten erklären? Eine Weile nach dem zweiten reboot ist jetzt gerade alles ruhig. Dutycycle kann ich ausschließen. War selbst bei den ganzen Tests gerade mal bei 9% (große Wired Installation).

Das einzige was gegenüber der 3.45.x ggf. einen Einfluss haben könnte wäre die neuere Firmware version für das RPI-RF-MOD die mit der 3.47.x mitkommt. Aber ansonsten, nein. Was anderes kann das IMHO nicht erklären. Und da nach dem zweiten reboot alles ruhig ist tippe ich auf Zufall / Ausreißer und gut ist

[jmaus]

paramSet.METER_TYPE

ist weiterhin "undefined"

Alle anderen Parameter sehen so aus:
Bildschirmfoto 2019-07-08 um 19.32.14.png

Ok, also über den "chType" sollte man es doch hinbekommen. Wie sieht es mit folgendem if aus:

Code: Alles auswählen

    if (typeof(paramSet.METER_TYPE) === "undefined") {                                                                                                                                   
      return ((this.opts.chType === "POWERMETER_IEC1" || this.opts.chType === "POWERMETER_IEC2") ? this.sensorTypeID.iec : this.sensorTypeID.eletricity);
    }                                           

[Hütte]

Habe am Wochendende gerade deshalb meine alte CCU2 wieder reaktiviert, um genau diese Version 2.2 des HM-ES-TX-WM zu testen, da ich für meinen Stromzähler Elster AS1440 einen ES-IEC-Sensor habe. Ich wollte damit eigentlich sowohl Strombezug als auch Stromeinspeisung durch meine PV erfassen. Mit der alten FW-Version 1.2 des HM-ES-TX-WM hatte ich es nicht geschafft, irgendwelche Daten auszulesen.
Meinen HM-ES-TX-WM, der meinen Gaszähler "ausliest", belasse ich natürlich auf der FW-Version 1.2.
Mit der aktuellen Version für die CC2 (2.47.12) und der Version 2.2 für den HM-ES-TX-WM kann ich nun endlich zumindest den Kanal 1 (Strombezug) auslesen. Obwohl die Kennzahlen, um den Kanal 2 2 auszulesen, korrekt sind, scheint in der FW-Version 2.2 noch nicht diese Option hinterlegt zu sein. Jedenfalls bleiben die beiden Zählerstände im Kanal 2 permanent auf Null, obwohl am Wochenende so ein paar kWh eingespeist wurden. Habe deshalb bei EQ-3 schon eine Anfrage/Ticket eröffnet.

Allerdings ist mir aufgefallen, dass ab dem Zeitpunkt, wo ich die Daten auslesen konnte (musste erst eine Weile mit den Parametern "spielen"), beide Zählerwerte "Energie-Zähler CCU" und "Energie-Zähler Gerät" identisch sind und mit den Werten am Zähler selber übereinstimmen. Ist ja auch logisch, da die Werte direkt aus dem Zähler ausgelesen werden. Alle Angaben sind sofort in kWh. Sie werden zwar mit 4 Nachkommastellen angezeigt. Aber da der Zähler diesen Wert nur mit ener Nachkommastelle liefert, sind die restlicheh Nachkommastellen nur "Schall und Rauch". Ebenso die 4 Nachkommastellen, die bei Leistung (aktueller Verbrauch in W), da der Wert direkt aus dem Zähler ausgelesen wird und nicht mehr über Impuls-Counter berechnet werden muss. Das bedeutet, das im Moment so manche "universellen" Zählerscripte für den HM-ES-TX-WM doch nicht mehr ganz so universell sind. Sie müssen dann nämlich einen Unteschied machen, ob es sich beim Einsatz als Stromzähler um einen Infrarot/LED-Sensor handelt oder ob da ein ES-IEC-Sensor dran hängt und somit eine Umrechnung von Wh in kWh notwendig ist oder nicht.