Neues Modul HMCCU für Homematic CCU

[zap]

Die CCU stellt leider nicht für alle Gerätetypen Beschreibungen zur Verfügung. Welchen Typ Thermostat hast Du denn?

Um die Parameter für ein HMCCUDEV Device zu setzen, musst Du den Kanal mit angeben und außerdem "config" und "HMTHERMO" vertauschen:

Code Auswählen Erweitern


set HMTHERMO config 1 P1_TEMPERATURE_FRIDAY_1=21


Der Befehl akzeptiert auch mehrere Parameter=Wert Paare.

Kurz zum Hintergrund: Homematic kennt Konfigurationsparameter für Geräte und Kanäle, wobei nicht jeder Gerätetyp beides anbietet. Wenn Du einen Geräteparameter setzen oder auslesen willst, musst Du die Kanalnummer weglassen. Wenn Du hingegen einen Kanalparameter setzen oder auslesen möchtest, musst Du die Kanalnummer mit angeben (so wie im Beispiel oben).

[Stril]

Hallo!

Der Thermostat ist ein HM-TC-IT-WM-W-EU, der mich wohl irgendwie nicht mag.

Code Auswählen Erweitern


set HMTHERMO config 1 P1_TEMPERATURE_FRIDAY_1=21


hat leider nichts geändert, obwohl das Device ja auch passen sollte... Es kommt kein Fehler, aber danach ist die Config gleich.

Ich weiß gerade nicht, wo der Fehler liegt.
Hast Du noch eine Idee?

Grüße
Phil

[zap]

Ich habe das Wandthermostat auch. Werde mal testen, heute aber nicht mehr.

[Chaos]

Ahoi,

kann mir mal jemand eine Config für ein HM-LC-Sw2-FM geben?
Ich steh gerade auf dem Schlauch wie ich das einrichten kann.

Bisher hab ich:

Code Auswählen Erweitern

Internals:
   DEF        MEQ1711385 1
   IODev      d_ccu
   NAME       Gabionen_Licht
   NR         38
   STATE      Initialized
   TYPE       HMCCUDEV
   ccuaddr    MEQ1711385
   ccudevstate Active
   ccuif      BidCos-RF
   ccuname    Gabionenlicht
   ccutype    HM-LC-Sw2-FM
   channels   3
   statevals  devstate
   Readings:
     2016-10-19 12:44:11   state           Initialized
Attributes:
   IODev      d_ccu
   statechannel 1
   statevals  on:true,off:false
   substitute STATE!true:on,false:off,1:on,0:off

Aber bei nem get devstate bekomme ich

HMCCUDEV: Gabionen_Licht Invalid datapoint

MfG
Manuel

[zap]

Eigentlich sieht die Device Definition gut aus, bis auf das Internal statevals. Da müsste wegen dem Attribut statevals eigentlich "devstate|on|off" drin stehen statt nur "devstate". Das hat aber nichts mit der von Dir beschriebenen Fehlermeldung zu tun. Setz einfach mal das Attribut statevals nochmal.

Für den Fehler versuche mal

Code Auswählen Erweitern


get Gabionen_Licht datapoint 1.STATE


Falls das auch auf Fehler läuft, führe mal folgendes aus und poste das Ergebnis:

Code Auswählen Erweitern


get Gabionen_Licht deviceinfo


[zap]

Code Auswählen Erweitern


get HMTHERMO config 1

--> hat prima funktioniert und ich sehe alle Profile.

Da es sich bei den Profilen um Geräteparameter und nicht um Kanalparameter handelt, müsste eigentlich folgendes funktionieren

Code Auswählen Erweitern


get HMTHERMO config


Kannst Du mir noch einen Tipp geben, wie ich diese dann ändere?

Code Auswählen Erweitern


set config HMTHERMO R-HMTHERMO.P1_TEMPERATURE_FRIDAY_1 21
set config HMTHERMO R-HMTHERMO.P1_TEMPERATURE_FRIDAY_1=21
set config HMTHERMO P1_TEMPERATURE_FRIDAY_1=21
set config HMTHERMO P1_TEMPERATURE_FRIDAY_1 21

...hat leider nicht funktioniert.

Versuche mal folgendes:

Code Auswählen Erweitern


set HMTHERMO config P1_TEMPERATURE_FRIDAY_1=21.0


Die RPC-Schnittstelle der CCU ist hier etwas eigen. Sie hätte die Temperatur gerne mit Dezimalpunkt. Funktioniert so bei mir.

Bei den Config-Parametern ist es hilfreich, sich die Einstellungsseite für das jeweilige Gerät in der CCU anzuschauen, gerade wenn get configdesc nicht unterstützt wird. Dazu in der CCU Oberfläche Einstellungen->Geräte aufrufen und beim Gerät hinten den Button "Einstellungen" drücken. Dann sieht man die Einstellungen gruppiert nach Geräteparametern und Kanalparametern. Dadurch weiß man zumindest, ob man eine Kanalnummer angeben muss.

Ich werde noch eine Möglichkeit einbauen, die verfügbaren Parameter auch dann auszulesen, wenn get configdesc nicht funktioniert. Sonst ist das ein ziemlicher Blindflug.

[Stril]

Hallo!

Vielen Dank!!!

set HMTHERMO config P1_TEMPERATURE_FRIDAY_1=21.0

--> hat funktioniert.

Grüße

[Chaos]

Ahoi

Code Auswählen Erweitern


get Gabionen_Licht datapoint 1.STATE

liefert:

Code Auswählen Erweitern

HMCCUDEV: Gabionen_Licht Invalid datapoint
und

Code Auswählen Erweitern


get Gabionen_Licht deviceinfo

liefert:

Code Auswählen Erweitern

HMCCUDEV: Gabionen_Licht Execution of CCU script or command failed

Kann das evtl damit zu tun haben, dass in der CCU2 die einzelnen Channels nen anderen Namen haben?
Also das Device heißt da Gabionenlicht und der erste Aktor darunter heißt Gabionenlicht_hinten. Testweises Umbennenen hat leider auch nichts gebracht.

MfG
Manuel

[zap]

Kann das evtl damit zu tun haben, dass in der CCU2 die einzelnen Channels nen anderen Namen haben?
Also das Device heißt da Gabionenlicht und der erste Aktor darunter heißt Gabionenlicht_hinten. Testweises Umbennenen hat leider auch nichts gebracht.

Mit den Kanalnamen hat das nichts zu tun. Mach mal bitte folgendes:

Code Auswählen Erweitern


get d_ccu devicelist


Damit liest FHEM die Namen der Geräte in der CCU neu ein. Das ist immer notwendig, wenn in der CCU ein Geräte- oder Kanalname geändert oder ein neues Gerät definiert wurde.

Danach bitte nochmal ein

Code Auswählen Erweitern


get Gabionen_Licht deviceinfo


[Spielmann]

Hallo zap,
ich habe einen HM-PBI-4-FM in meiner CCU2, den ich schnellstmöglich über HMCCU aktualisieren möchte um ein Licht zu schalten. Eine Direktverknüpfung ist nicht möglich da der Schaltaktor eine Siemens LOGO ist. Das rpcserver Intervall habe ich derzeit auf 0,5s gesetzt - jedoch ist mir die Reaktionszeit von ca 1 - 1,5s noch etwas zu lang (das geht über CUL schneller).

Statt in FHEM ein Notify zu verwenden, könntest Du auch aus der CCU2 heraus ein Reading bzw. ein Dummy Device in FHEM auf den Wert setzen. Wie das geht, hatte ich schon mal irgendwo beschrieben. Du brauchst auf der CCU2 das Programm "nc" (NetCat) sowie am besten noch CuXD. Dann erstellst Du in der CCU2 ein Programm, das bei Änderung einer Variablen ausgeführt wird und entsprechende Werte an FHEM schickt.

Update: Hier ist der Beitrag:

https://forum.fhem.de/index.php?topic=42089.0

Das brachte mich auf die Idee dass bei einem Event auf der CCU ein Reading in FHEM auslöst und den rpcserver aktualisiert. Das Intervall könnte man dann wieder hochsetzen und das System wird weniger belastet. Ich habe mir das schon mal angesehen, jedoch scheitere ich derzeit schon am Passwort vom SPC und vermutlich mangelndem Wissen von Linux.
Macht es Sinn diesen Ansatz weiter zu verfolgen oder mache ich da einen Denkfehler und wird keine Verbesserung bringen?

Gruß
Spielmann

[zap]

Hallo zap,
ich habe einen HM-PBI-4-FM in meiner CCU2, den ich schnellstmöglich über HMCCU aktualisieren möchte um ein Licht zu schalten. Eine Direktverknüpfung ist nicht möglich da der Schaltaktor eine Siemens LOGO ist. Das rpcserver Intervall habe ich derzeit auf 0,5s gesetzt - jedoch ist mir die Reaktionszeit von ca 1 - 1,5s noch etwas zu lang (das geht über CUL schneller).

So ganz verstehe ich das Problem nicht. Ein Schaltbefehl an den HM-PBI-4-FM über HMCCU ausgelöst wird ja sofort an die CCU bzw. das Device geschickt. Da greift kein Intervall. Lediglich der Rückweg, also die Signalisierung des geänderten Zustands des HM-PBI-4-FM erfolgt über den RPC-Server und ist damit um max. 'rpcinterval' Sekunden verzögert. Oder möchtest Du als Reaktion auf die Meldung (z.B. Licht eingeschaltet) eine weitere Aktion ausführen, bei der die 1-1,5s zu viel sind?

Das brachte mich auf die Idee dass bei einem Event auf der CCU ein Reading in FHEM auslöst und den rpcserver aktualisiert. Das Intervall könnte man dann wieder hochsetzen und das System wird weniger belastet. Ich habe mir das schon mal angesehen, jedoch scheitere ich derzeit schon am Passwort vom SPC und vermutlich mangelndem Wissen von Linux.
Macht es Sinn diesen Ansatz weiter zu verfolgen oder mache ich da einen Denkfehler und wird keine Verbesserung bringen?

Was ist "SPC"? Grundsätzlich ist es über den von mir in dem anderen Thread beschriebenen Weg möglich, von der CCU aus beliebige Befehle in FHEM auszuführen. Damit könntest Du z.B. auch ein "get datapoint" oder "get devstate" für Dein HM-PBI-4-FM Device triggern, das dann das entsprechende Reading aktualisiert.

[Stril]

Hallo!

Kurze Info:
Der HMIP-WTH-2 (Wandthermostat für Fußbodenheizung) funktioniert mit HMCCU fast vollständig:

Möglich ist:
- Umschaltung Auto/Manuell
- Manuelle Temperatur vorgeben
- Temperatur, Luftfeuchte auslesen
- Partyzeiten setzen
- Boostmode
- Status (Batterie, etc.)

Bisher nicht möglich:
- Zeitprofile über FHEM setzen (hierzu gibt es keine Readings)

Hast Du noch eine Idee, wie die Zeitprofile reinkommen könnten?

Grüße
Phil

[zap]

Bisher nicht möglich:
- Zeitprofile über FHEM setzen (hierzu gibt es keine Readings)

Hast Du noch eine Idee, wie die Zeitprofile reinkommen könnten?

Doch das geht. Für Zeitprofile gibt es ebenfalls Config-Parameter. Ich kann die heute abend mal hier nachliefern. Allerdings sind die etwas "tricky" zu setzen, da man immer einen Tag komplett definieren muss. Die Zeitangabe erfolgt in Minuten seit 0 Uhr, d.h. 6:30 Uhr morgens wäre dann 6*60+30=390.

[Stril]

Doch das geht. Für Zeitprofile gibt es ebenfalls Config-Parameter. Ich kann die heute abend mal hier nachliefern. Allerdings sind die etwas "tricky" zu setzen, da man immer einen Tag komplett definieren muss. Die Zeitangabe erfolgt in Minuten seit 0 Uhr, d.h. 6:30 Uhr morgens wäre dann 6*60+30=390.

Hallo!

Kannst Du mir da einen Tipp geben? Ich finde keinen "datapoint", der diese Zeiten irgendwie enthält. Bei der HM-Variante (ohne IP) finde ich die Readings, aber beim HmIP-Wandthermostat gibt auch "get d_ccu deviceinfo HMIPTHERMO" nichts Passendes aus.

Danke und Grüße

[Spielmann]

Hallo zap,
anders herum. Ich habe den HM-PBI-4-FM mit der CCU gepairt und möchte über HMCCU das Devive in fhem ansprechen. Somit greift das Intervall. Anstatt jetzt das Intervall bis auf ein Minimum zu reduzieren, dachte ich man könnte doch bei einem Event in der CCU aktiv über Netcat fhem antriggern und die Werte im RPCserver auf fhem aktualisieren. Somit könnten auch zeitkritische Geschichten umgesetzt werden.

Ich bin noch in der Testphase vom HM-LAN auf HMCCU zu wechseln. Abgesehen von den unkonfortablen Nachteilen gegenüber der direkten HMCUL hat mich folgendes überzeugt eine Umstellung zu testen:
- durch die nicht mehr Verfügbarkeit des HM-LAN bin ich mit der CCU auf der sicheren Seite auch weiter unterstützte Geräte von eq3 zu erhalten (wenn nicht alles eingestellt wird oder eq3 Pleite geht)
- durch die rpc-Schnittstelle kann ich selbst auch als "Programmierlaie" eine Schnittstelle über die datapoints finden.
- eine komfortable Reichweitenvergrößerung ist in der CCU enthalten.

Ist jetzt etwas off Topic:
Noch etwas zum HM-PBI-4-FM (der etwas eigenartig reagiert): Ist der Taster nur mit der CCU gepairt erzeugt der Tasten beim Drücken nur das Event INSTALL-TEST. Ich habe dann ein Dummy Programm in der CCU angelegt, dass nur die 4 Tasten abfragt. Nach einem Druck auf die Install-Taste am HM-PBI-4-FM spricht er dann auch (LONG, SHORT,RELEASE). Damit kann ich jedoch leben (man muss nur darauf kommen).

Ansonsten ein großes Lob an HMCCU. Ohne dem autocreate hätte ich vermutlich das Thema nicht angegangen.

Gruß
Spielmann


update noch vergessen:

Was ist "SPC"? Grundsätzlich ist es über den von mir in dem anderen Thread beschriebenen Weg möglich, von der CCU aus beliebige Befehle in FHEM auszuführen. Damit könntest Du z.B. auch ein "get datapoint" oder "get devstate" für Dein HM-PBI-4-FM Device triggern, das dann das entsprechende Reading aktualisiert.

Damit meine ich natürlich WINSCP um NetCat auf die CCU zu bekommen.

Gruß
Spielmann