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

zap · 24 Februar 2018, 12:12:58

Ich versuche, das mal bei einem CUxD Device nachzustellen. Das Problem könnte sein, dass der Datenpunkt SET_TEMPERATURE vom Typ Float ist, du aber einen String übergibst.

gentoo79 · 24 Februar 2018, 16:43:21

Ist denn die neue HMCCU soviel anders, als die alter Version ?.
Denn mit dem vorigen hat es super geklappt alles.

LG
gentoo79

zap · 24 Februar 2018, 17:20:19

Set datapoint ist anders.

Aber ich kapier immer noch nicht, wie du einen Text in einen nummerischen Datenpunkt in der CCU schreiben willst. Und dann auch noch in SET_TEMPERATURE, das write only ist. Das kannst du nicht mal in der CCU auslesen

gentoo79 · 24 Februar 2018, 18:47:05

Zitat von: zap am 24 Februar 2018, 17:20:19
Set datapoint ist anders.

Aber ich kapier immer noch nicht, wie du einen Text in einen nummerischen Datenpunkt in der CCU schreiben willst. Und dann auch noch in SET_TEMPERATURE, das write only ist. Das kannst du nicht mal in der CCU auslesen

Ich will ja keinen Text Schreiben sondern einfach die Temperaturen ( Grad Celsius ) von meinen Oregon Sensoren die über fhem laufen in die ccu (90) Wrapper Device schreiben. So als wenn ich einen homematic Temperatursensor habe.

Gesendet von iPhone mit Tapatalk

zap · 25 Februar 2018, 11:22:32

Den Use Case kann ich nachvollziehen, den Weg dahin nicht. Warum

set datapoint 1.SET_TEMPERATURE "$temperature comma C off on off"

und nicht

set datapoint 1.SET_TEMPERATURE $temperature

Wozu "comma C off on off"? Den Teil kann man in einem numerischen Datenpunkt nicht ablegen. Vielleicht ist das die neue Version auch etwas genauer.

UPDATE:

Ich habe das bei mir jetzt mal getestet mit einem solchen CUxD Device:

set mydev datapoint 1.SET_TEMPERATURE 23.0

führt dazu, dass sofort der Datenpunkt 1.TEMPERATURE auf 23.0 gesetzt wird. Also funktioniert alles wie erwartet.

ACHTUNG! Wichtig ist, dass in den Geräteeinstellungen des Wrapper Device in der CCU der Haken bei HMAdapt weg ist, sonst kann kein Datenpunkt manuell gesetzt werden.

Rewe2000 · 25 Februar 2018, 11:31:12

Hallo zap,

ich habe sporadisch, seit einiger Zeit Probleme mit Befehlen zu einigen HmIP Geräten. Ich verwende eine CCU2 (neueste Firmware, ohne eigene Programme) als Kommunikationsweg CCU2 zu Fhem verwende ich HMCCURPCPROC Fhem neuester Stand.
Im Log stehen häufig folgende Fehler (Befehle werden von einem doif gesendet):

Code Auswählen

2018.02.25 08:25:46 1: HMCCUDEV: HM_OG_RT1_Schlafzimmer Execution of CCU script or command failed
2018.02.25 08:25:46 3: set HM_OG_RT1_Schlafzimmer datapoint 1.SET_POINT_TEMPERATURE 17.0 : HMCCUDEV: HM_OG_RT1_Schlafzimmer Execution of CCU script or command failed
2018.02.25 08:25:46 2: di_Schlafzimmer_Lueften_Heizung_normal: {     {if (ReadingsVal("HM_OG_RT1_Schlafzimmer","1.ACTIVE_PROFILE",0) == 2)       {fhem("set HM_OG_RT1_Schlafzimmer datapoint 1.SET_POINT_TEMPERATURE 17.0")}    }   }: HMCCUDEV: HM_OG_RT1_Schlafzimmer Execution of CCU script or command failed

Setze ich den gleichen Befehl "set HM_OG_RT1_Schlafzimmer datapoint 1.SET_POINT_TEMPERATURE 17.0" über die Fhem Eingabezeile ab, wird dieser teilweise mit Fehler quittiert oder einfach angenommen und ausgeführt.
Als Fehler taucht dann folgendes im Log auf, wird der Befehl ausgeführt, steht natürlich nichts im Log:

Code Auswählen

2018.02.25 10:07:08 1: HMCCUDEV: HM_OG_RT1_Schlafzimmer Execution of CCU script or command failed

Hast du oder habt ihr für mich einige Tipps, in welche Richtung ich da den Fehler suchen kann?
Kann das ein Zeitproblem sein, weil Fhem oder die CCU2 anderweitig beschäftigt ist, da es sporadisch funktioniert?

Komisch ist nur, dass es manchmal funktioniert und manches Mal wieder nicht.
Gerne liefere ich noch weitere Infos nach, will aber nicht das gesamte Forum mit Anhängen zumüllen.

Gruß Reinhard

zap · 25 Februar 2018, 12:47:57

Setze mal bitte folgendes Attribut:

attr HM_OG_RT1_Schlafzimmer ccuflags trace

Das solltest Du dann so lange eingeschaltet werden, bis der Fehler auftritt. Dann hätte ich gerne die entsprechenden Einträge im FHEM-Log.

Aber Achtung! Das Tracing wird ziemlich viele Logeinträge generieren. Verbose muss >= 2 sein.

Chris8888 · 26 Februar 2018, 08:37:16

Hallo Zap,

der Befehl "get CCU firmware" liefert derzeit nicht den aktuellen Stand.
Beispiel: HmIP-WTH2
Auf dem EQ3-Server liegt die 1.8.0, über den Befehl bekomme ich die 1.4.4 angeboten. Siehe Screenshot.

Hat EQ3 da etwas verändert?

Viele Grüße
Christian

zap · 26 Februar 2018, 11:55:43

vermutlich. Leider gibt es keine offizielle API für die Abfrage. Wenn EQ3 die Webseite ändert, muss ich das in HMCCU auch anpassen.

Xervek · 26 Februar 2018, 16:20:41

@Rewe2000

Bin scheinbar ebenfalls von deinem / dem Problem betroffen. HMCCUDEV: <HMIP-Device> Execution of CCU script or command failed

Aktuell im Aktueller Status nur nach get Update-Thread am Schreiben mit zap darüber...

Rewe2000 · 26 Februar 2018, 17:45:08

Hallo,

@Xervek, das scheint in der Tat etwas ähnliches wie bei mir zu sein, mit der einzigen Ausnahme, bei mir kommt dies absolut selten, ist aber dennoch nicht OK.

@zap, leider konnte ich heute den Fehler mit trace nicht "erwischen", bleibe aber dran.

Einige Punkte sind mir aber aufgefallen, welche ich mal hier in die Runde werfen will.

Ich beobachte diese Fehler nur, wenn längere Zeit nichts zu den Devices gesendet wird. Versuche ich den Fehler "auf biegen und brechen" zu provozieren gelingt mir dies (bisher) nicht.
Den Fehler beobachte ich auch häufiger an einem HM-Dis-EP-WM55 Homematic (ohne IP) E-Paper Display und an 2 HmIP-WTH-2 Wandthermostaten.

Einige Fragen/Überlegungen hierzu:

Kann es etwas damit zu tun haben, wenn auf ein Device, zur gleichen Zeit (von verschiedenen anderen Devices, über Direktverknüpfungen) und der CCU2 unterschiedliche Befehle gesendet werden? Ich habe meine HmIP-WTH-2 (Wandthermostate) mit den HmIP-eTRV (Heizkörperthermostaten) und HMIP-SWDO (Fensterkontakten) direkt verknüpft, und die Fenster - Auf Temperatur liegt bei 5.0°C.
In diesem Zusammenhang fällt mir derzeit ein anderes seltsames Verhalten auf, glaube aber nicht, dass es etwas mit dem ursprünglichen Problem zu tun hat. Bei einem Fensterkontakt blinkt teilweise die LED sporadisch bis zu 30x bevor diese mit grün beendet. Häufig passt der Fensterzustand im Heizkörper und Wandthermostat, aber in der CCU2 ist das Fenster noch geöffnet obwohl es aktuell geschlossen ist. Bei einem bestätigten Funk-Tranfer sollte meines Erachtens dies nicht vorkommen, oder es müsste zumindest ein Fehler in der CCU2 angezeigt werden.
Da es ja unterschiedliche HM und HmIP Geräte betrifft, kann es ja nicht an der neuen Firmware (Vers. 1.8) in den HmIP-WTH-2 Wandthermostaten liegen, welche ich erst vor einigen Tagen installiert habe.

Gruß Reinhard

zap · 26 Februar 2018, 18:00:05

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

Hintergrund: HMCCU schickt den Befehl per FHEM Funktion GetFileFromURL() an die CCU. Diese Funktion hat einen Timeout von 4 Sekunden, was genau zu dem Effekt passt, den Xervek festgestellt hat.

Ich könnte den Timeout höher setzen oder konfigurierbar machen. Das löst aber das Problem nicht. Schließlich möchte man nicht 4 Sekunden oder länger auf die Ausführung eines Befehls warten.

Ich kann dir momentan auch nur den Tipp geben, die CCU mal durchzustarten.

Du könntest auch probehalber für eines der Devices das Attribut ccuget auf "Value" setzen. Hintergrund: Damit wartet die CCU nicht, bis ein Wert wirklich beim Device angekommen ist. Das könnte verhindern, dass sich Set Befehle von Direktverknüpfungen mit manuell abgesetzten in die Quere kommen.

Xervek · 26 Februar 2018, 18:12:29

@Rewe2000

Das mit dem "längere Zeit nichts gesendet" hatte ich zunächst auch in Vermutung, scheint sich bei mir aber nicht zu bewahrheiten. Bei mir lässt sich das Problem am Thermostat offenbar mit kurzem Testen reproduzieren indem ich immer wieder die Temperatur ändere. Oftmals geht es problemlos, vereinzelt dauert es dann länger, der Fehler kommt ehe es weiter geht.

Mein Thermostat ist lediglich mit einem Türkontakt verbunden der aber offenbar zum Fehlerzeitpunkt keine Aktualisierung durchführt und auch nicht manuell "bedient" wird.

@zap
Habe das mit dem "ccuget auf Value" mal schnell mit meinem Thermostat versucht, ohne Erfolg. Der Fehler tritt weiterhin unverändert auf.

Wie im anderen Thread geschrieben hat es bei mir nicht geholfen die CCU2 und FHEM neu zu starten. Wir können das Ganze der Übersicht halber auch gerne zusammenführen und das hier im Thread besprechen / schreiben.

zap · 26 Februar 2018, 18:38:09

Könnte auch sein, dass das Sendelimit für das 868 MHZ Band für das Gerät bei zu häufigem Senden überschritten wird.

Xervek · 26 Februar 2018, 18:41:47

Danke für den Hinweis, das ist mir bewusst. In den Fällen aktuell aber noch nicht eingetreten. Normalerweise ändere ich eher wenig bis sehr wenig und nur aktuell so viel zum Testen. Das Limit wurde aktuell scheinbar noch nicht überschritten da die letzte Änderung der Temperatur auf den Ursprungswert noch akzeptiert und sauber eingestellt wurde.

Laut dem trace von nach dem Neustart ist es ja leider weiterhin das Problem mit dem Timeout... und im schlimmsten Fall ändere ich die Temperatur für eine Stunde manuell am Thermostat