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

[darkbrain85]

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

Von mir aus gerne

[jmaus]

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.

Hast du denn ne Möglichkeit den v2 HM-ES-TX-WM auch mit RaspberryMatic zu testen bzw. mit der Test/Release-Candidate version die ich hier verlinkt habe? Und dann ggf. etwas javascript-debugging im Webbrowser zu machen?!? Dann könnten wir schauen was passiert bzw. welche Anpassungen es braucht auch den v2 Zähler zu unterstützen.

[jp112sdl]

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);
    }                                           

Sieht gut aus für die Modelle, die ich testen kann (HM-ES-PMSw1-Pl, HM-ES-TX-WM V 1.0 und V 2.2).
P.S.: JSON-Sprech ist aber typeof ohne () , auch wenns mit den Klammern trotzdem funktioniert

[jmaus]

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);
    }                                           

Sieht gut aus für die Modelle, die ich testen kann (HM-ES-PMSw1-Pl, HM-ES-TX-WM V 1.0 und V 2.2).

Gut, dann soll es so sein:
https://github.com/jens-maus/RaspberryM ... heck.patch

P.S.: JSON-Sprech ist aber typeof ohne () , auch wenns mit den Klammern trotzdem funktioniert

Ich bevorzuge in der Tat die Klammernvariante weil die IMHO nicht nur netter aussieht sondern auch intuitiver ist.

Danke auf jedenfalls für deine Hilfe. Dann wird es morgen vmtl. eine weitere Release-Candidate/Testversion geben die du dann gerne mitesten kannst

[Theo]

Hallo Jens,

Update auf Thinkerboard S ohne Probleme.

Bei Gruppen (Heizungsgruppen) ist mir aufgefallen dass unter Geräte / Einstellen gelegentlich die Kanalparameter fehlen. Ab- und wieder Anmelden löst das Problem bis zum nächsten Mal. Ich meine dies Problem gab es schon mal.

Unter Geräte / Einstellen fehlen gelegentlich die Kanalparameter.

An dieser Stelle auch der Hinweis zum eQ3 Changelog: [HMCCU-150] Automatische Übertragung der Standortdaten an neu angelernte HmIP-Geräte für AstroFunktionen. Dies stimmt nur bedingt, da man die Positionsangaben bei einem Heizkörper nicht direkt angeben kann, muss dies in den Gruppen getan werden. Und eben diese Gruppen werden nicht aktualisiert wenn man unter Systemsteuerung / Zeit- und Positionseinstellungen die Werte neu setzt. Bei anderen HmIP-Geräte (z.B. HMIP-PSM) funktioniert dies problemlos.

Ein kleiner Schönheitsfehler, wobei ich nicht weiss ob dieser bereits in der Basis vorhanden ist.

HmIP-STHO, komische Zeichen.

[darkbrain85]

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

Es gibt definitiv ein Problem mit classic RF und dem aktuellen RC.
Ich hatte heute Nacht wieder mehrere Komm. Störungen eines Dimmers (HM-LC-Dim1T-FM), der vor dem Update absolut ohne Störungen lief. Dazu weiterhin der MP3 Gong (HM-OU-CFM-TW) welcher bei Bedienung Komm. Störungen hat.

Dagegen laufen Fenstersensoren (HM-Sec-SCo) und auch eine HM-Sec-Sir-WM problemlos. Viel mehr RF Geräte habe ich nicht. Wired läuft ohne schmerzen.

Der Dimmer verhält sich so: Einstellen auf 50% über WebUI -> Dimmer geht kurz an, direkt danach wieder aus. WebUI zeigt kurz 0,5 als Wert an, springt dann wieder auf 50%. NAch einer kurzen Zeit springt die WebUI dann auch wieder auf 0%. Dazwischen gibt es Komm. Störungen.
Jetzt gerade ist der Dimmer laut WebUI auf 60%, aber physikalisch ist er aus.

Bei den gestörten Geräten hat sich weder der Standort geändert, noch habe ich den Raspberry und seine Antenne seit gestern angefasst. Das Update wurde remote durchgeführt...

Edit:

Offensichtlich ein Problem der EQ3 Firmware. Vermutlich dann tatsächlich mit der neuen Funkmodul Firmware.
Hier gibt es die Probleme offensichtlich auch:

viewtopic.php?f=26&t=51384&start=29

[jmaus]

Offensichtlich ein Problem der EQ3 Firmware. Vermutlich dann tatsächlich mit der neuen Funkmodul Firmware.
Hier gibt es die Probleme offensichtlich auch:

viewtopic.php?f=26&t=51384&start=29

Also selbst kann ich davon nicht berichten, denn hier in meiner eigenen produktiven Umgebung verursacht die aktuelle Testversion keine erkennbaren Probleme.

Wenn es allerdings so sein sollte würde ich dazu raten hier als erstes geordnet in der Analyse vorzugehen. D.h. ein paar stunden zu warten bis sich das Problem eingependelt hat, dann einen Neustart ggf. mit kompletter Trennung von der Stromquelle zu machen. Das dann auch mehrfach wiederholen um genug Aussagekraft in der Messreihe zu bekommen. Und wenn das problem dann immer noch auftritt ein Downgrade auf die 3.45.7.20190622 zu machen und zu schauen ob auch dort nach mehrfachen reboots und warten das problem definitiv nicht mehr auftritt. Wenn dadurch die Aussage gesichert ist kannst du unter 3.45.7.20190622 dann mit folgendem Befehl zu Testzwecken eine Datei /etc/config/no-coprocessor-update anlegen:

Code: Alles auswählen

touch /etc/config/no-coprocessor-update

Und dann kannst du wieder auf die aktuelle Testversion gehen und schauen ob damit dann die Problem weg sind, denn durch die Existenz dieser Datei sollte er dann (wie der Name schon sagt) beim Starten nicht automatisch die Funkmodul-Firmware von der 4.0.16 auf die aktuelle 4.0.20 die mit der 3.47.10 mitgeliefert wird updaten. Und dann solltest du quasi eine RaspberryMatic 3.47.10.201907xx haben aber eben mit der alten 4.0.16 Funkmodul-Firmware und kannst damit dann wieder entsprechend testen.

Hierbei aber beachten das du jetzt natürlich nicht bis zum Ende aller Tage einfach diese Datei angelegt lassen solltest denn ggf. verpasst du dann somit in weiteren Versionen wichtige Funkmodul-firmware updates die andere Probleme beheben bzw. Verbesserungen einführen sollten.

[darkbrain85]

Danke für die Tips. Ich habe gerade ein downgrade gemacht. Leider bleibt das Problem dabei bestehen. Es wird also eher irgendwas beim Update passiert sein, was jetzt in der Config hängt. Genug Zeit zum "einpendeln" hatte das System heute Nacht ja...

Der Dimmer spuckt nach einem downgrade jetzt auch bei jeder Bedienung über die WebUI eine Komm. Störung aus. Eventuell hat der seinen DC erreicht... ich werde jetzt eine Weile warten.

[LukeUG]

Hallo an Alle,

auch wenn es nicht hilft, weil man nicht von sich selbst auf andere schliessen kann, bei meinen 55 HM-RF Geräten keine Auffälligkeiten ausser der Geschichte mit den "Strommessern".....

Aber ich denke auch solche Infos gehören zum Test.

Gruß UG

[Hütte]

...

Hast du denn ne Möglichkeit den v2 HM-ES-TX-WM auch mit RaspberryMatic zu testen bzw. mit der Test/Release-Candidate version die ich hier verlinkt habe? Und dann ggf. etwas javascript-debugging im Webbrowser zu machen?!? Dann könnten wir schauen was passiert bzw. welche Anpassungen es braucht auch den v2 Zähler zu unterstützen.

Da komme ich leider erst am nächsten Wochenende dazu. Dann werde ich meinen Raspi wieder aktivieren (Live-System ist mittlerweile auf einem Tinker-S) und es mal ausprobieren. Jetzt hat der HM-ES-TX-WM für meinen Stromzähler schon so lange nutzlos im Schrank gelegen, weil es mit der FW-Version 1.2 nicht funktionierte. Da kommt es auf ein oder zwei Monate auch nicht mehr darauf an, ob er in der offiziellen RaspberryMativ-Version läuft oder nicht.

Denn die Anzahl der Nutzer, die unbedingt Version FW-Version 2.2 benötigen, wird sicher überschaubar sein. Da diese Version eh nur benutzt werden darf, wenn ein ES-IEC-Sensor dran hängt. Alle anderen HM-ES-TX-WM, die mit den anderen Sensoren genutzt werden, dürfen das FW-Update ja gar nicht bekommen.

Mit welcher Version soll ich dann testen? Der letzten Test-Version oder der kommenden Version von nächstem Wochenende? Und worauf muss ich dann beim Debuging achten, falls was nicht funktioniert? Kannst mir die Anweisungen auch gerne als PN schicken, um hier nicht alles zu überfrachten.