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

[zap]

Da kann ich chris nur zustimmen. Das peer Attribut ist eigentlich nur für Dinge gedacht, die sich mit Homematic Bordmitteln nicht lösen lassen. Ich ziehe direkte Verknüpfungen bzw. Konfigurationen in den Aktoren immer script oder FHEM basierten Lösungen vor. Dann funktioniert das Ganze auch noch, wenn CCU oder FHEM ausfallen.

[Wernieman]

Es gitb dazu einen passenden Biologischen Vergleich:

"Reflexe" werden nicht im Hirn verarbeitet
Nur Höhere Aufgaben werden dort verarbeitet

Also "Licht" an sollte immer von der Hardware direkt verarbeitet werden, d.h. Schalter -> Lampe.
Dagegen das "Einschalten Fernseher und automatisch Raum verdunkeln, Stimmungs Licht einschalten" ist eine Aufgabe von FHEM.

[dennis87]

Ihr habt recht und mich überzeugt . Ich habe gerade einen HM-IP Lichtschalter bestellt und werde das verproben .

@Chris8888 oder die anderen: Habt ihr ggf. ein paar Infos wie ich die beiden Komponenten am besten direkt miteinander verknüpfen kann? Ich weiß noch, dass das bei meinen nicht HM-IP Komponenten relativ komplex war.

Vielen Dank,

Dennis

[Chris8888]

Hi,

das ist nicht so schwer.
Die Tasten (1 &2) sind intern mit dem Kanal 4 (je nach Schalter) des Actors verknüpft.
Ich habe daher die "Treppenhauslicht"-Logik zwischen SPI und Schalter Kanal 5 verknüpft (im Anhang).
Zusätzlich habe ich Taster "aus" (1 oder 2) ebenfalls mit Kanal 5 als "aus" verküpft, um "Licht an" durch den SPI auch vorzeitig beenden zu können.

Damit komme ich wunderbar zurecht.

Viel Erfolg!

Viele Grüße
Christian

[jojojo]

Hallo zap,

ich habe eben auf HMCCURPCPROC umgestellt und das Problem, dass das Attribut rpcServerAddr ignoriert wird.
Ich habe FHEM in einem Dockercontainer laufen.
Obwohl rpcServerAddr auf die Docker-Host-Adresse gesetzt ist, wird das Callback-Interface auf die Ip des Docker-Containers (localaddress) registriert und nicht auf der IP des Hosts. Da kommt die CCU so halt nicht ran.

Ich könnte jetzt im Router den Dockerhost als Gateway für das private Container-Netz definieren,
schöner wäre es, wenn rpcServerAddr funktionieren würde

Irgendeine Idee, woran es liegen könnte?

Viele Grüße
Jürgen

[zap]

welchen RPC Server hast Du vorher verwendet, den internen oder den externen (HMCCURPC)?

Irgendwie scheine ich das im letzten Update ausgebaut zu haben. Keiner der RPC Server scheint das Attribut noch zu berücksichtigen. Muss ich mir anschauen.

[jojojo]

Mit dem externen (HMCCURPC) hat es vorher funktioniert.
Da ich gerade meine Docker-Umgebung umbaue und den FHEM-Container ein paar mal neu gemacht habe,
bin ich aber gerade nicht sicher, welche Version da lief.

Als workaround bau ich halt solange ein Gateway mit entspr. Route in meinen Router ein
Ich beobachte dann hier im Thread, ob es neues dazu gibt.

Danke und Gruß
Jürgen

[zap]

Eigentlich müsste das doch funktionieren. Es gibt 2 Möglichkeiten (unterschiedliche Schreibweise beachten):

1. Du definierst rpcserveraddr im I/O Device (das gilt dann für alle HMCCURPCPROC Devices ohne eigenes rpcServerAddr Attribut)
2. Du definierst rpcServerAddr im jeweiligen HMCCURPCPROC Device (ein Device je genutztes CCU Protokoll !)

Beim Start der RPC Server kannst Du mal auf folgende Meldungen im Log achten (verbose muss >= 2 sein):

"Registering callback ..."

Noch ein Hinweis: Der bzw. die RPC-Server müssen nach dem Setzen des Attributs neu gestartet werden. Am besten FHEM neu starten.

[jojojo]

Bei mir nicht

In beiden Fällen steht im Log "Registering callback http://172.19.0.4:7411/fh2001"
und das ist die Container-IP im Docker-Netz und nicht die Host-IP

[Wernieman]

Was bei einem docker-Container insofern logisch ist, da er die Host-IP nicht sieht (sehen kann)

[zap]

Muss ich mir nochmal anschauen. Normalerweise sollte die IP registiert werden, die in dem Attribut angegeben ist. Leider etwas schwierig zu testen. Muss erst mal auf meinem Raspi ein virtuelles Netzwerk Interface definieren.

[jojojo]

Was bei einem docker-Container insofern logisch ist, da er die Host-IP nicht sieht (sehen kann)

Deswegen gibt es ja die Möglichkeit, die IP mit rpcserveraddr bzw. rpcServerAddr zu überschreiben
Was aber halt nicht wie gedacht funktioniert.
Vielleicht habe ich am Wochenende auch nochmal Zeit, etwas länger zu testen.
Mit entspr. Gateway/route im Router funktioniert es ja auch erstmal so.

Viele Grüße
Jürgen

[zap]

ok, nachvollziehbar. Bei mir wird das Attribut auch ignoriert. Ich kümmere mich ...

[zap]

Bugfix für rpcServerAddr ist im SVN eingecheckt. Morgen per FHEM Update verfügbar.

Außerdem neu in dieser Version: v.a. bei HMIP Devices werden vermehrt Systemvariablen mit Kanälen verknüpft, um zB Counter zu speichern. Bisher war es in HMCCU nicht möglich, diese Variablen/Datenpunkte zu aktualisieren. Mit dieser Version ist eine Aktualisierung mit dem Befehl "get update" möglich.

Was nach wie vor nicht geht:
- Aktualisierung solcher Datenpunkte mit "get datapoint"
- Automatische Aktualisierung per RPC Server (die CCU schickt hier leider keine Infos)

[Chris8888]

Hallo,

ich habe eben mal todesmutig die neue Firmware der CCU2 eingespielt: 2.35.15
Völlig problemlos...HMCCU scheibt bisher auch einwandfrei zu funktionieren.

Wenn ich das ChangeLog richtig verstehe, so werden jetzt auch HmIP-Heizungsgruppen unterstützt.
Damit werde ich mich mal am Wochenende beschäftigen.

VG
Christian