HMCCU: Neue Version 4.2 mit neuem RPC Server verfügbar

zap · 26 Februar 2018, 19:04:06

Da fällt mir nur noch ein, von GetFileFromURL() auf NonblockingGet() umzustellen. Das wird aber nicht so einfach und der Effekt wird nicht für jeden User logisch erscheinen. Muss ich mal drüber nachdenken ....

Rewe2000 · 26 Februar 2018, 19:31:44

Hallo,

@zap:

ZitatEs scheinen Timing-Probleme zu sein. Wird der Befehl auch bei einer Fehlermeldung trotzdem ausgeführt, ggf. verzögert?

Bei mir wurde der Befehl (nach der Fehlermeldung in Fhem am 25.02.) definitiv nicht an das Wandthermostat weitergegeben. Da ich die 1.SET_POINT_TEMPERATURE im Chart habe, kann ich dies noch genau sehen.

Habe eben nochmals versucht, die Fehler mit trace zu provozieren, derzeit keine Change, bleibe aber dran.

Gruß Reinhard

zap · 27 Februar 2018, 07:00:09

@Rewe2000

Du schreibst weiter oben, dass Du Thermostat, Fenstersensor und Wandthermostat verknüpft hast. Wie hast Du das gemacht, über eine virtuelle Gruppe in der CCU oder in Handarbeit? Ich weiß nicht, ob die CCU virtuelle Gruppen mit HmIP Devices unterstützt. Aber wenn sie es tut, solltest Du das auch so verknüpfen. Dann bindest du das virtuelle Gruppendevice in FHEM ein und setzt die Datenpunkte im virtuellen Gruppendevice und NICHT direkt am Wand- oder Heizkörperthermostat!

Xervek · 27 Februar 2018, 11:02:28

Es gibt also aktuell keine möglichen Ansätze (neben dem Umbau von von GetFileFromURL() auf NonblockingGet()) mehr das Problem zu beheben? Ist denn abzusehen, dass es mit NonblockingGet() nicht mehr auftreten wird?

In dem Fall würde ich dich dann darum bitten, den Timeout bis dahin eventuell höher zu setzen und / oder konfigurierbar zu machen, wie du es angesprochen hast. So wie ich das sehe müssen wir ja ohnehin > 4 Sekunden warten ehe die Befehle im Timeout-Fall korrekt verarbeitet werden und ansonsten geht das ja ohnehin weit schneller als 4 Sekunden. Aktuell umgehen wir mit einem Timeout > 4 Sekunden ja die ausgegebene Fehlermeldung / Weiterleitung / Blockierung von FHEM oder übersehe ich etwas?

Edit:
Ich habe übrigens meinen Türkontakt in der CCU2 unter "Startseite > Programme und Verknüpfungen > Direkte Verknüpfungen" miteinander verknüpft und keine virtuelle Gruppe erstellt, jedenfalls nicht, dass ich wüsste. Wobei das ja für mich, wenn ich recht informiert bin ohnehin nicht notwendig ist, da die virtuellen Gruppen für HomeMatic gedacht sind...

zap · 27 Februar 2018, 12:41:10

Zitat von: Xervek am 27 Februar 2018, 11:02:28
Es gibt also aktuell keine möglichen Ansätze (neben dem Umbau von von GetFileFromURL() auf NonblockingGet()) mehr das Problem zu beheben? Ist denn abzusehen, dass es mit NonblockingGet() nicht mehr auftreten wird?

Wenn die Anfrage an die CCU tatsächlich in den 4 Sekunden Timeout läuft, dürfte NonblockingGet() zumindest die Fehlermeldung verhindern. Das Schalten an sich wird dadurch natürlich nicht beschleunigt.

Zitat
In dem Fall würde ich dich dann darum bitten, den Timeout bis dahin eventuell höher zu setzen und / oder konfigurierbar zu machen, wie du es angesprochen hast. So wie ich das sehe müssen wir ja ohnehin > 4 Sekunden warten ehe die Befehle im Timeout-Fall korrekt verarbeitet werden und ansonsten geht das ja ohnehin weit schneller als 4 Sekunden. Aktuell umgehen wir mit einem Timeout > 4 Sekunden ja die ausgegebene Fehlermeldung / Weiterleitung / Blockierung von FHEM oder übersehe ich etwas?

Ja, aber: FHEM blockiert natürlich so lange, bis der Timeout abgelaufen ist.

Xervek · 27 Februar 2018, 13:13:21

Danke für die Aufklärung und deine Bemühungen, dann habe ich es nun hoffentlich verstanden. Das ist ja echt übel, gerade weil es vollkommen unberechenbar passiert. Heute Nacht erneut zum Schlafen gehen einfach mit

Code Auswählen

2018.02.27 00:40:34 1: HMCCUDEV: HMIP_Radiator_Thermostat_Livingroom Execution of CCU script or command failed
2018.02.27 00:40:34 3: set HMIP_Radiator_Thermostat_Livingroom control 17.0 : HMCCUDEV: HMIP_Radiator_Thermostat_Livingroom Execution of CCU script or command failed

aus heiterem Himmel ausgelöst.

Wenn du etwas brauchst oder ich irgendwie noch weiter helfen kann, lass es mich bitte einfach wissen.

zap · 27 Februar 2018, 14:01:23

Mein Problem bei der Sache ist, dass Du und Rewe2000 bisher die einzigen seid, die diesen Fehler haben.

Vielleicht tritt der Fehler auch nur auf der Software-CCU auf, und die alte CCU ist davon nicht betroffen. Vielleicht tritt es auch nur bei HmIP auf. Alles nur Vermutungen.

Ich habe fast 80 HM-Devices in FHEM definiert. Ich habe die Logs seit 1.1.2018 durchsucht. Ich hatte den Fehler in dieser Zeit nicht.

Rewe2000 · 27 Februar 2018, 18:10:18

Hallo,

@zap

Ich habe die HmIP Geräte als Direktverknüpfungen direkt in der CCU2 (keine Software) angelegt, denn ich will bei komplettem Ausfall der Software (Raspi, Fhem oder CCU2 selbst) meine Raumheizung zumindest noch (normal) bedienen können.
anbei ein Bild der CCU2 Direktverknüpfungen:

Ich triggere mein doif mit öffnen oder schließen des Fensters, aber zur gleichen Zeit jagt ja auch noch der Fensterkontakt (vermutlich intern) an den gleichen Datenpunkt vom Wandthermostaten auch noch die Temperatur, welche vorher eingestellt war. Beim öffnen der Fenster stelle ich immer 5°C ein.

Was passiert eigentlich in der CCU2, wenn zur gleichen Zeit (von unterschiedlichen Stellen) der gleiche Datenpunkt "1.SET_POINT_TEMPERATURE" beschrieben wird?
Wird das sequentiell nach Reihenfolge des Eingangs abgearbeitet, oder bleibt der schwächste oder langsamste Sender auf der Strecke.
Wenn du etwas davon hältst, könnte ich den set Befehl an die CCU2 um einige Sekunden im doif verzögern, um die gleichzeitigen Sendungen auf den gleichen Datenpunkt auszuschließen.

Ich habe den Fehler wirklich nicht häufig, ca. 15 Mal seit 1. Januar, bei 3 unterschiedlichen HM und HmIP Geräten. Was mir noch auffällt, Zeitgleich kommt immer ein Perfmon-Hänger mit, Dauer ca. 3-5 Sekunden (bei mir) mit.

Code Auswählen

2018.01.22 20:13:02 1: HMCCUDEV: HM_OG_RT1_Schlafzimmer Execution of CCU script or command failed
2018.01.22 20:13:02 1: Perfmon: possible freeze starting at 20:12:59, delay is 3.141

@Xervek

Hast du Perfmon oder etwas ähnliches bei dir auf dem System, um "Hänger" zu erkennen, nicht dass diese die Fehler erst verursachen.

Gruß Reinhard

zap · 27 Februar 2018, 19:27:18

Eine virtuelle Gruppe macht erst mal auch nichts anderes, als eine direkte Verknüpfung zwischen den Geräten herzustellen. Der Vorteil ist: du brauchst kein Doif. Das Absenken der Temp passiert automatisch, wenn der Sensor Fenster auf meldet.

Ich glaube, es sind 2 unterschiedliche Probleme. Bei dir kommen sich vermutlich zwei set Befehle ins Gehege. Bei xervek ist die CCU mit irgendwas beschäftigt und daher läuft das Set in einen Timeout.

Xervek · 28 Februar 2018, 14:44:16

@zap

Das ist alles auch gar nicht wild und verständlich. Ich wollte nicht wirken als sollte jetzt alles umgebaut werden wegen dem Fehler um ihn zu eliminieren. Irgendwie habe ich den Wald aber auch vor lauter Bäumen nicht mehr gesehen, was den Puls beschleunigt hat, ... Ich habe eines meiner beiden Probleme mittlerweile aber gelöst was den Fehler betrifft. Es bleibt bei mir aktuell weiterhin nur die Weiterleitung wenn der Fehler auftritt, die vor dem Update auf 4.2 nicht stattgefunden hat... Ich wollte lediglich sagen, dass ich etwas verwirrt bin durch die Unberechenbarkeit die das Handhaben erschwert...

@Rewe2000

Ich habe bisher quasi ein nacktes RaspMatic (genau: 2.29.23.20171216) ohne Plugins und FHEM auf der anderen Seite, ohne eigene Überwachung der Auslastung. Ich bin ehrlich: Ich befinde mich aktuell noch immer in der Einfindungsphase, dem Durcharbeiten des "Erste Schritte" PDF und habe unter anderem deshalb so lange gebraucht mich hier zu melden und das Problem anzusprechen, einfach um eigene möglicherweise offensichtliche Fehler ausschließen zu können.

@zap zum Zweiten

Ich wüsste nicht womit sie beschäftigt sein könnte... Ich habe lediglich 3 HomeMatic IP und 1 HomeMatic Türkontakt(e), eine HomeMatic IP Schaltsteckdose und mein HomeMatic IP Heizkörperthermostat Thermostat. RaspMatic ist nackt, ohne Plugins, ohne sonstige großen Änderungen am System. Alles was ich wirklich "anfasse" läuft über FHEM. Die "messages" der CCU2 sind wie im anderen Thread geschrieben leider ebenfalls leer und zeigen keinen Fehler an...

Rewe2000 · 28 Februar 2018, 17:49:30

Hallo Xervek,

dann guck dir doch mal Perfmon https://wiki.fhem.de/wiki/Perfmon an ob das nicht etwas für dich sein könnte. Du brauchst es nicht unter Fhem installieren, wenn es im Verzeichnis der Module ist, so tut es zuverlässig seinen Dienst, wenn du es nicht mehr brauchst, so löscht du es einfach wieder, nach einem shutdown restart ist es vom System verschwunden.

Es schreibt zuverlässig "Hänger" ab 1 Sekunde ins Log und du bist in jeden Fall im Bild, wenn's irgend wo klemmt.

Zitat... Ich habe eines meiner beiden Probleme mittlerweile aber gelöst was den Fehler betrifft.

An was war es denn bei dir gelegen?

Gruß Reinhard

zap · 01 März 2018, 09:11:32

HMCCU liegt nun in der Version 4.2.003 im SVN.

Bugfixes:

- Ersetzung von Datenpunkt-Variablen in einigen Befehlen / Attributen funktionierte nicht richtig
- Das Attribut 'peer' in Devices vom Typ HMCCUCHN und HMCCUDEV sollte nun korrekt funktionieren

Neu:

- Mit dem neuen Attribut ccuReqTimeout kann der Timeout für CCU HTTP Requests festgelegt werden. Default ist 4 Sekunden. Dieser Wert wirkt sich auf die Befehle "set datapoint", "set var", "get datapoint" und "get var" aus. Achtung! Wenn der Timeout greift, blockiert FHEM während dieser Zeit.

Ich werde zeitnah im Wiki ein Beispiel für die sinnvolle Nutzung von 'peer' beschreiben (Steuerung eines Somfy-Rollladens in FHEM aus der CCU heraus mit Hilfe eines CUxD Wrapper Device).

Rewe2000 · 01 März 2018, 18:10:04

Hallo zap,

Danke für deine Mühe, das hast du ja schnell umgesetzt.
Ich werde die neue Version bei mir testen und gebe dir Bescheid wenn etwas nicht läuft (wie immer).
Habe eben die Version 4.2.003 installiert, sieht bisher sehr gut aus.

Bei mir ist der Fehler nun seit einigen Tagen nicht mehr aufgetreten, deshalb werde ich die Standardeinstellung für ccuReqTimeout erstmal so lassen.

Auf dein Beispiel im Wiki zu peer bin ich gespannt, bisher habe ich alle Direktverknüpfungen immer in der CCU2 programmiert.

Noch eine Frage an Dich:
Ist es möglich mit Fhem gepeerte Kanäle von Devices, in Fhem protokollieren (Verbose X, trace) zu lassen. Oder sieht man hier genau soviel als wenn diese mit der CCU2 gepeert werden, nämlich nichts, da die Kommunikation ja direkt von Device zu Device geht.

Gruß Reinhard

zap · 02 März 2018, 18:13:45

Zitat von: Rewe2000 am 01 März 2018, 18:10:04
Auf dein Beispiel im Wiki zu peer bin ich gespannt, bisher habe ich alle Direktverknüpfungen immer in der CCU2 programmiert.

Das solltest Du auch weiter so machen für Homematic Komponenten. Das geht zwar auch mit dem Attribut "peer", jedoch ist die CCU interne Variante deutlich schneller. Das Attribut "peer" ist eher dafür gedacht, in FHEM Homematic Devices mit Nicht-Homematic Devices zu verknüpfen. Also quasi eine Art Abkürzung bzw. Ersatz für Notify und DOIF.

Zitat
Noch eine Frage an Dich:
Ist es möglich mit Fhem gepeerte Kanäle von Devices, in Fhem protokollieren (Verbose X, trace) zu lassen. Oder sieht man hier genau soviel als wenn diese mit der CCU2 gepeert werden, nämlich nichts, da die Kommunikation ja direkt von Device zu Device geht.

Mit ccuflags = trace und verbose >= 2 sollten bei Devices mit Attribut peer einige Meldungen ausgegeben werden, wenn das Peering greift.

Xervek · 07 März 2018, 12:22:43

@Rewe2000

Danke für den Link, ich werde mir das die Tage mal anschauen und gucken ob es eventuell auch bei mir irgendwo hängt.

Was das Beheben eines meiner beiden Probleme betrifft, entschuldige, ich habe mich missverständlich ausgedrückt. Ein Problem ist, dass offenbar was die CCU2 betrifft, FHEM nahezu vollständig bei mir blockiert wenn es einen Timeout gibt. Das bedeutet, dass das Abschicken eines Befehls, beispielsweise die Temperaturänderung, gefolgt von einem update auf einen Datapoint keine geänderte Rückgabe bringt, egal wie lange ich warte. Gibt es jedoch keinen Timeout, funktioniert das direkt folgende Update sauber. Das hat mir massiv kopfzerbrechen bereitet, bis ich es in ein separates notify ausgelagert habe.
Ich habe leider weiterhin die Timeouts zu unmöglichen Zeiten und in unmöglichen Situationen, aber einen Weg gefunden, damit umgehen zu können.

@zap

Vielen Dank für die extrem schnelle Umsetzung! Ich werde das Update im Laufe des Tages installieren und mich in den kommenden Tagen wieder melden. Ich werde testhalber so weit den Timeout erhöhen bis der Fehler nicht mehr auftritt, zumindest kenne ich dann die Dimensionen von denen wir hier schreiben.