[erledigt] Ergänzung zu "HM-CC-VD Funk-Stellantrieb"

Begonnen von bernd_zwo, 04 April 2018, 18:56:17

Vorheriges Thema - Nächstes Thema

bernd_zwo

Hallo zusammen,

ich habe die Einrichtung des Ventil-Stellantriebs gerade in eineigen Varianten getestet und möchte die hilfreichen Forembeiträge gerne fürs Wiki zusammenfassen.
Den Artikel gibt es schon, wenn's denn so OK ist, bitte vor "Links" einfügen.

Danke & Gruß,
Bernd


= Betrieb mit FHEM, ohne (physischen) HM-CC-TC =

Alternativ kann der HM-CC-VD auch über einen virtuellen HM-CC-TC betrieben werden.
Damit diese Lösung stabil funktioniert, sollte die Kommunikation (nach Nutzererfahrung aus dem Forum) als IO-Device ein HMLAND oder ein HM-MOD-UART (Raspi-Modul) nutzen.
Ein CUL im RF-Mode 'Homematic' scheint das nötige präzise Timing (s.o.) nicht immer zu halten.

== Einrichtung ==
=== Vorbereitung ===
- der HM-CC-VD sollte zurückgesetzt sein - ca. 20 s den Button drücken und die Einfahrprozedur am Heizkörperventil abschließen.
- das Pairing durchführen: am HMLAND oder HM-MOD-UART (oder besser einer VCCU)  'set <HMIO> hmPairForSec nnn' und am HM-CC-VD den Button 5-10 s drücken, es sollte im Display des VD kurz von 20 s rückwärts gezählt werden und dann das Antennensymbol dauerhaft stehen.
Der HM-CC-VD sollte jetzt in der Liste der FHEM-Devices als HM_xxxxxx sichtbar sein.
Wichtig: Am neu eingerichteten Device HM-CC-VD  muss noch das Attribut msgRepeat = 0 gesetzt werden, sonst führt ein Zuviel an Kommunikation zwischen HM-CC-VD und IO-Device zum Verlust der Verbindung. Quelle: [[https://forum.fhem.de/index.php/topic,41588.msg339484.html#msg339484 1]]

<pre>
set HM_xxxxxx deviceRename <HM_CC_VD>
attr <HM_CC_VD> msgRepeat 0
</pre>


=== Einrichten virtueller HM-CC-TC ===
Der zur Kommunikation mit dem Stellantrieb HM-CC-VD nötige Virtuelle Controller wird wie folgt eingerichtet:
<pre>
define <HM-VIRT-TC> CUL_HM 112233*
attr <HM-VIRT-TC> expert 2_raw
attr <HM-VIRT-TC> model virtual_1
attr <HM-VIRT-TC> msgRepeat 0
attr <HM-VIRT-TC> subType virtual

set <HM-VIRT-TC> virtual 1
</pre>
* oder eine andere noch nicht vergebene ID


Weil es sich nicht um einen virtuellen Button, sondern um den Kanal eines virtuellen HM-CC-TC handelt, kann man den Kanal umbenennen:
<pre>
rename <HM-VIRT-TC>_Btn1 <HM-VIRT-TC>_c1
</pre>

In diesem Beispiel wird ein virtueller TC einem VD zugeortnet. Wenn man einen TC mit mehreren Kanälen nutzt (z.B. set <HM-VIRT-TC> virtual 2),
kann man den einzelnen VD nachher nicht kontrollieren, es wird nur der Status des zuletzt angesteuerten Kanals am <HM-VIRT-TC> ausgewertet.

Bei Einsatz einer VCCU kontrollieren, ob das richtige IO-Device genutzt wird (s. VCCU) - falls nicht, per IOgrp-Attribut setzen.
Ohne VCCU sollte IODev auf das richtige Device zeigen.

Hier z.B. ein HM-MOD-UART "UART-HM" an der VCCU "VIRTCCU1"
<pre>
attr <HM-VIRT-TC> IOgrp VIRTCCU1:UART_HM
</pre>


=== Peering von HM-CC-VD und virtuellem HM-CC-TC ===
<pre>
set <HM-VIRT-TC>c1 peerChan 0 <HM_CC_VD> single set
</pre>

Danach den Button am HM-CC-VD drücken, bis die 20-Sekunden-Anzeige anfängt zu laufen.

mit
<pre>
set <HM-VIRT-TC>c1 valvePos 55
</pre>
kann man den VD jetzt testen.

mit
<pre>
define heizung_regler PID20 <thermosensor>:temperature <HM-VIRT-TC>c1:valvePos
</pre>

lässt sich die Kombination aus HM-CC-VD und virtuellem HM-CC-TC im Regelmodul PID20 als Heizungsregler nutzen.



Quellen:
https://forum.fhem.de/index.php?topic=60296.0
https://forum.fhem.de/index.php?topic=22419.0
https://forum.fhem.de/index.php?topic=30738.0
https://forum.fhem.de/index.php?topic=54911.0
https://forum.fhem.de/index.php?topic=41588.0




edit: [erledigt] im Betreff ergänzt
Meine Installation: fhem 5.8, Raspi 2 / Raspbian, Busware CUL 868, HM-MOD-UART, HM-CFG-USB-2 (aCulfw V 1.26.04 a-culfw Build: 306), JeeLink V3, fht8v, TX29DTH-IT, HM- (diverse)