Anbindung Viessmann Heizung mit VCONTROL300

Begonnen von srxp, 23 Februar 2017, 13:15:51

Vorheriges Thema - Nächstes Thema

andies

Und in diesem Moment (ich habe gerade einen kalten Neustart gemacht) *läuft alles*! Na ich bin heute ein Glückspilz...


Gesendet von iPad mit Tapatalk Pro
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

crispyduck

Hallo,

Hast du ein starkes Netzgerät an der Raspi und auch den Strom der USB Ports im config.txt rauf gedreht?

Hatte ein ähnliches seltsames Verhalten mit einem RS485 Adapter, welches aber nur alle paar Tage oder Wochen aufgetreten ist, nachdem ich bei der Pi2 im config.txt den Strom der USB Ports erhöht habe ist (glaube ich) Ruhe.

Lg
Crispyduck

andies

Ich habe das ja nicht am USB, sondern RxTx. Und ein 2A-Netzteil, nachdem ich woanders mal ein halbes Jahr verzweifelt nicht nachvollziehbare Fehler suchte, die letztendlich auf ein 1A-Netzteil zurückzuführen waren.  Wie stellst Du den Strom in der config hoch?

Mein Problem, das ich ursprünglich hatte, existiert leider noch immer. Manchmal werden die Daten perfekt gelesen, manchmal geht es nicht, so wie heute Nacht:
2017.10.13 07:28:56 3: VCONTROL300: TCP connection opened
2017.10.13 07:28:56 3: Opening Viessmann device 192.168.2.105:3002
2017.10.13 07:28:56 3: Viessmann device opened
2017.10.13 07:28:56 4: VCONTROL300: Start of update...
2017.10.13 07:28:56 4: VCONTROL300: Start of polling values...
2017.10.13 07:28:56 4: VCONTROL300: Waiting for sync byte...
2017.10.13 07:28:56 5: SW: 04
2017.10.13 07:28:57 4: VCONTROL300: Waiting for sync byte...
2017.10.13 07:28:57 5: SW: 04
2017.10.13 07:28:57 4: VCONTROL300: Received sync byte!
2017.10.13 07:28:57 4: VCONTROL300: Waiting for init byte...
2017.10.13 07:28:57 5: SW: 160000
2017.10.13 07:29:00 4: VCONTROL300: Waiting for init byte...
2017.10.13 07:29:00 5: SW: 160000
2017.10.13 07:29:03 4: VCONTROL300: Waiting for init byte...
2017.10.13 07:29:03 5: SW: 160000
2017.10.13 07:29:05 4: VCONTROL300: Waiting for init byte...
2017.10.13 07:29:05 5: SW: 160000
2017.10.13 07:29:07 4: VCONTROL300: Waiting for init byte...
2017.10.13 07:29:07 5: SW: 160000
2017.10.13 07:29:09 4: VCONTROL300: Waiting for init byte...
2017.10.13 07:29:09 5: SW: 160000
2017.10.13 07:29:12 4: VCONTROL300: Waiting for init byte...
2017.10.13 07:29:12 5: SW: 160000
2017.10.13 07:29:14 4: VCONTROL300: Waiting for init byte...
2017.10.13 07:29:14 5: SW: 160000
2017.10.13 07:29:16 4: VCONTROL300: Waiting for init byte...
2017.10.13 07:29:16 5: SW: 160000
2017.10.13 07:29:18 4: VCONTROL300: Waiting for init byte...
2017.10.13 07:29:18 5: SW: 160000
2017.10.13 07:29:21 4: VCONTROL300: Waiting for init byte...
2017.10.13 07:29:21 5: SW: 160000
2017.10.13 07:29:23 4: VCONTROL300: Init status: 'error'!
2017.10.13 07:29:23 4: VCONTROL300: Did not receive init byte after 11 retries
2017.10.13 07:29:23 4: VCONTROL300: End of polling values! Duration: 26.34
2017.10.13 07:29:23 4: VCONTROL300: Update done!
2017.10.13 07:29:23 3: VCONTROL300: TCP connection closed
2017.10.13 07:29:23 5: VCONTROL300: Undef set_cmd_list_values!

und eine Stunde später
2017.10.13 08:28:56 3: VCONTROL300: TCP connection opened
2017.10.13 08:28:56 3: Opening Viessmann device 192.168.2.105:3002
2017.10.13 08:28:56 3: Viessmann device opened
2017.10.13 08:28:56 4: VCONTROL300: Start of update...
2017.10.13 08:28:56 4: VCONTROL300: Start of polling values...
2017.10.13 08:28:56 4: VCONTROL300: Waiting for sync byte...
2017.10.13 08:28:56 5: SW: 04
2017.10.13 08:28:57 4: VCONTROL300: Waiting for sync byte...
2017.10.13 08:28:57 5: SW: 04
2017.10.13 08:28:58 4: VCONTROL300: Waiting for sync byte...
2017.10.13 08:28:58 5: SW: 04
2017.10.13 08:28:59 4: VCONTROL300: Received sync byte!
2017.10.13 08:28:59 4: VCONTROL300: Waiting for init byte...
2017.10.13 08:28:59 5: SW: 160000
2017.10.13 08:28:59 4: VCONTROL300: Received init byte!
2017.10.13 08:28:59 4: VCONTROL300: Init status: 'ok'!
2017.10.13 08:28:59 5: VCONTROL300: Send 41050001088A029A
2017.10.13 08:28:59 5: SW: 41050001088a029a
2017.10.13 08:28:59 5: VCONTROL300: Read '0641070101088A02'
2017.10.13 08:28:59 5: VCONTROL300: Read '8182A0'
2017.10.13 08:28:59 5: VCONTROL300: Received 10 of 10 bytes

und weiter geht's. Ich habe das ganze "Lesegerät" deshalb komplett neu gebaut, weil ich den Fehler da vermutet habe (zB falsche Platzierung der Dioden etc.). Dort liegt aber der Fehler nach meiner Meinung nicht, denn dass mit zwei verschiedenen Konstruktionen und zweimal verschiedenen Bauteilen dasselbe passiert, ist unwahrscheinlich.  Also denke ich, dass es irgendwas mit dem Übergang "Diode im Lesegerät" und "Viessmann" zu tun hat. Nur was? Timing-Probleme? Strom (wie gesagt: 2A am RPi zero).
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

crispyduck

Ach ja, du hast das ja nicht mit einem USB Adapter drann hängen.
Mit max_usb_current=1 in the /boot/config.txt, kannst du bei der Pi2/3 den insgesamtwn USB output current von 600mA auf 1200mA anheben.

Lg
Crispyduck

andies

#154
Es wird immer rätselhafter. Wenn ich über vcontrold gehe, habe ich sofort Zugriff zu den Zahlen, die ich in FHEM nicht oder nur schwer herausbekomme
vctrld>getTempRaumNorSollM1
DEBUG:Fri Oct 13 11:07:15 2017 : Befehl: getTempRaumNorSollM1
DEBUG:Fri Oct 13 11:07:15 2017 : >SEND: 41
DEBUG:Fri Oct 13 11:07:15 2017 : >SEND: 05
DEBUG:Fri Oct 13 11:07:15 2017 : >SEND: 00
DEBUG:Fri Oct 13 11:07:15 2017 : >SEND: 01
DEBUG:Fri Oct 13 11:07:15 2017 : >SEND: 23
DEBUG:Fri Oct 13 11:07:15 2017 : >SEND: 06
DEBUG:Fri Oct 13 11:07:15 2017 : >SEND: 01
DEBUG:Fri Oct 13 11:07:15 2017 : >SEND: 30
DEBUG:Fri Oct 13 11:07:15 2017 : <RECV: len=1 06 (40.0 ms)
DEBUG:Fri Oct 13 11:07:15 2017 : <RECV: received 06
DEBUG:Fri Oct 13 11:07:15 2017 :
DEBUG:Fri Oct 13 11:07:15 2017 : >FRAMER: Command send
DEBUG:Fri Oct 13 11:07:15 2017 : >FRAMER: no preset result
DEBUG:Fri Oct 13 11:07:15 2017 : <RECV: len=1 41 (0.0 ms)
DEBUG:Fri Oct 13 11:07:15 2017 : <RECV: received 41
DEBUG:Fri Oct 13 11:07:15 2017 : <RECV: len=1 06 (0.0 ms)
DEBUG:Fri Oct 13 11:07:15 2017 : <RECV: received 06
DEBUG:Fri Oct 13 11:07:15 2017 : <RECV: len=7 01 (0.0 ms)
DEBUG:Fri Oct 13 11:07:15 2017 : <RECV: received 01 01 23 06 01 13 45
DEBUG:Fri Oct 13 11:07:15 2017 : Typ: uchar (in float: 19.000000)
DEBUG:Fri Oct 13 11:07:15 2017 : (FLOAT) Exp:V [B0:13 B1:00 B2:00 B3:00 B4:00 B5:00 B6:00 B7:00 B8:00 B9:00 ]
DEBUG:Fri Oct 13 11:07:15 2017 : 19.000000 Grad Celsius
19.000000 Grad Celsius

Was ist denn der Unterschied zwischen vcontrold und VCONTROL300.pm, ich meine in Bezug auf den Zugriff auf Viessmann?

PS Könnte das an ser2net liegen?

PPS Nein, daran liegt es nicht. Ich bin das gerade umgangen, indem ich FHEM auf dem RPi zero selbst installiert habe. Läge es an ser2net, müsste der Fehler verschwinden, tut er aber nicht. Dafür kam aber eine genauere Fehlermeldung, hier scheint es im Code ein Problem zu geben:
2017.10.13 11:30:11 5: VCONTROL300: Send 410500012110083F
2017.10.13 11:30:11 5: SW: 410500012110083f
2017.10.13 11:30:11 5: VCONTROL300: Read '06410D0101211008'
2017.10.13 11:30:11 5: VCONTROL300: Read '31B0FFFFFFFFFFFF'
2017.10.13 11:30:11 5: VCONTROL300: Received 15 of 16 bytes
2017.10.13 11:30:11 5: VCONTROL300: Read '23'
2017.10.13 11:30:11 5: VCONTROL300: Received 16 of 16 bytes
2017.10.13 11:30:11 2: VCONTROL300: Error while reading parameter 2110 : Retry 0!!!
2017.10.13 11:30:11 5: VCONTROL300: Send 410500012110083F
2017.10.13 11:30:11 5: SW: 410500012110083f
2017.10.13 11:30:11 5: VCONTROL300: Read '06410D0101211008'
2017.10.13 11:30:11 5: VCONTROL300: Read '31B0FFFFFFFFFFFF'
2017.10.13 11:30:11 5: VCONTROL300: Received 15 of 16 bytes
2017.10.13 11:30:11 5: VCONTROL300: Read '23'
2017.10.13 11:30:11 5: VCONTROL300: Received 16 of 16 bytes
2017.10.13 11:30:11 2: VCONTROL300: Error while reading parameter 2110 : Retry 1!!!
2017.10.13 11:30:11 5: VCONTROL300: Send 410500012110083F
2017.10.13 11:30:11 5: SW: 410500012110083f
2017.10.13 11:30:11 5: VCONTROL300: Read '06410D0101211008'
2017.10.13 11:30:11 5: VCONTROL300: Read '31B0FFFFFFFFFFFF'
2017.10.13 11:30:11 5: VCONTROL300: Received 15 of 16 bytes
2017.10.13 11:30:11 5: VCONTROL300: Read '23'
2017.10.13 11:30:11 5: VCONTROL300: Received 16 of 16 bytes
2017.10.13 11:30:11 2: VCONTROL300: Error while reading parameter 2110 : Retry 2!!!
2017.10.13 11:30:11 5: VCONTROL300: Send 410500012110083F
2017.10.13 11:30:11 5: SW: 410500012110083f
2017.10.13 11:30:11 5: VCONTROL300: Read '06410D0101211008'
2017.10.13 11:30:11 5: VCONTROL300: Read '31B0FFFFFFFFFFFF'
2017.10.13 11:30:11 5: VCONTROL300: Received 15 of 16 bytes
2017.10.13 11:30:11 5: VCONTROL300: Read '23'
2017.10.13 11:30:11 5: VCONTROL300: Received 16 of 16 bytes
2017.10.13 11:30:11 2: VCONTROL300: Error while reading parameter 2110 : Retry 3!!!

Das war mein Versuch, die oben erfolgreich ausgelesenen Uhrzeiten zu bestimmen!
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

amenomade

ZitatWas ist denn der Unterschied zwischen vcontrold und VCONTROL300.pm
Der grunsätzliche Unterschied wurde hier erklärt: https://forum.fhem.de/index.php/topic,51167.msg539660.html#msg539660
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

andies

Ich habe mal eine grundsätzliche Frage. Vielleicht noch zwei Sätze zur Vorgeschichte (auch oben nachzulesen): Ich habe Probleme mit VCONTROL und VCONTROL300 und weiß nicht, wieso. Ich konnte bisher sowohl den RPi als auch meinen Optolink-Adapter ausschließen, muss also vermuten, dass VCONTROL300 die Ursache ist. Im Gegensatz dazu scheint aber vcontrold alles das an Daten zu liefern, was VCONTROL300 nicht schafft?!

Nun habe ich mir folgendes überlegt und würde mich freuen, wenn mir der eine oder die andere einen Hinweis geben könnte. Wieso schreiben wir nicht ein Modul, das auf vcontrold zugreift? Der Daemon erlaubt doch eine Telnet-Verbindung "von außen", so dass das Modul "nur" diese Telnet-Verbindung auslesen müsste, dabei die in vcontrold vordefinierten Befehle aufruft und die Rückmeldungen in FHEM einspeist.

Ist das überhaupt (also rein theoretisch) machbar? Hat das schon jemand versucht? Und liegen da irgendwo Probleme versteckt, die ich noch nicht überblicke? Sonst würde ich mich mal auf die Suche machen. Mir persönlich erscheint vcontrold stabiler als VCONTROL300, aber ich kann mich da auch irren und es kann auch an Besonderheiten liegen, die nur etwas mit mir zu tun haben?

Sonst würde ich mal in einem anderen Thread eine Frage dazu eröffnen. Eine Grundstruktur eines Moduls sollte ich hinbekommen. Das Problem scheint mir der telnet-Aufruf zu sein. Wenn ich das richtig verstehe (ich konnte bisher kein Perl) muss man das sinngemäß so machen (DevIo lässt, wenn ich das richtig gelesen habe, die Verbindung ständig offen)
use Net::Telnet ();
    $t = new Net::Telnet (Timeout => 10, Prompt => '/bash\$ $/');
    $t->open($host);
    $t->login($username, $passwd);
    @lines = $t->cmd("command");
    print @lines;

aber dann fangen die Probleme schon an: Dieser Zugriff dürfte blockierend sein. Gibt es da Alternativen? Oder ist das schon der richtige Weg? Was ist, wenn sich zwei Abfragen "überkreuzen" (erste noch offen, zweite schon abgeschickt - muss ich das organisieren in meinem Modul oder geschieht das automatisch)? Also ich bin etwas durcheinander und würde mich freuen, wenn der eine oder die andere einen Tipp hat...
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Happy Fhem User

@andies

Verstehe ich Deinen Aufbau richtig?


[Host A mit FHEM]
  / \
   |
[Netzwerk]
   |
  \ /
[Host B mit angeschlossenen Viessmann-Lesegerät]



Falls ja, gäbe es da diverse Quellen, die zu de Fehlern führen können. Spontan fallen mir ein:

a) FHEM greift nicht alleine auf die Datenschittstelle zu. Hast Du irgendwo auf einen der Hosts noch einen VControlD laufen? Oder etwas anderes, daß die Schnittstelle des Lesers anspricht?
b) Ist das Netzwerk stabil zwischen den beiden Hosts?

Beide Probleme könnten zu sporadisch bis oft aber nicht immer auftretenden Fehlern führen.

andies

Zitat von: Happy Fhem User am 14 Oktober 2017, 15:16:04
a) FHEM greift nicht alleine auf die Datenschittstelle zu. Hast Du irgendwo auf einen der Hosts noch einen VControlD laufen? Oder etwas anderes, daß die Schnittstelle des Lesers anspricht?
b) Ist das Netzwerk stabil zwischen den beiden Hosts?

Vielen Dank für die Hilfe! VControld läuft nur auf dem HeinzugsRPi (die Zeichnung war richtig!). Und das Netzwerk zwischen beiden ist stabil. Den Unterschied, der für die Probleme verantwortlich ist, kann ich inzwischen genau eingrenzen: Einmal sendet vcontrold die Signale an das Optolink-Kabel, einmal macht es VCONTROL300. Und bei letzterem gibt es anscheinend Probleme.

Inzwischen habe ich mich dazu aufgerafft, das ganz anders zu lösen. Ich bin dabei, ein Modul 89_VCLIENT.pm zu schreiben, das die Kommunikation mit dem Daemon vcontrold übernimmt (der sendet ja telnet auf Port 3002). Zu meinem Erstaunen (ich konnte bisher kein Perl) bin ich schon ziemlich weit und werde das vermutlich auch fertig kriegen. Falls jemand Interesse hat, kann ich dazu ja mal einen eigenen Thread aufmachen.  Im Grunde simuliert dieses Modul dann die Eingaben, die man normalerweise in vcontrold macht und schreibt die Ausgaben mit. Das läuft bei mir ja stabil.

Die einzige Schwierigkeit ist momentan noch herauszubekommen, was für eine Art "Telnet" das sein soll, das vcontrold sendet. Mit Net::Telnet  von Perl kann man das nur teilweise auslesen und die Webseite von openv ist (sorry jungs, openv war tolle Arbeit, aber) so was von chaotisch...
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

amenomade

ZitatEinmal sendet vcontrold die Signale an das Optolink-Kabel, einmal macht es VCONTROL300.
Es ist wohl bekannt, dass es zu Problemen führt, wenn 2 unterschiedliche Programme den gleichen Optolink nutzen.

Wegen telnet: es ist doch telnet, aber dann werden die "commands" genutzt, die in der config XML File definiert sind. Was Du direkt im Terminal mit telnet machst, sollte auch im Perl funktionieren? Vielleicht eine Frage von Timeout - dies kannst Du bein "new Net::Telnet" definieren.

Ich würde aber eher vclient nutzen, der scheint vollständig zu sein, und den Protokoll 300 zuunterstützen.

Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

andies

Nein, da habe ich mich falsch ausgedrückt. Einmal wird vcontrold gestartet, VCONTROL300 wird gelöscht (bzw FHEM greift gar nicht zu) und die Sache funktioniert. Dann Neustart und ich starte FHEM, lade VCONTROL300 und es geht nicht mehr. Das habe ich mehrfach durch, es liegt wirklich an VCONTROL300 (zumindest bin ich mir sicher). Ich vermute DevIO als Ursache.

Timeout hilft leider bei dem Gewürge mit vcontrold nicht, weil die anscheinend keinen richtigen Prompt senden. Jedenfalls erkennt den Net::Telnet nicht. Ich behelfe mir gerade mit den Einheiten, die von vcontrold mitgegeben werden, das funktioniert. vclient habe ich, wenn ich ehrlich bin, nicht verstanden (wie gesagt, die Webseite von openv ist eine ziemliche Katastrophe).
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

vitolinker

Hallo Andies,

bist du sicher, dass vcontrold nach dem Neustart nicht läuft?
ps -ef |grep vcontrold
gibt darüber Auskunft.
Es sollte nur ein Eintrag zurück geliefert werden (der des grep Befehls). Wenn noch der vcontrold läuft, dann mit
kill -9 <PID>
den Prozess mit der Nummer aus dem Eintrag =<PID> abschießen.

Viel Glück

andies

Sorry, ganz schwierig heute morgen bei mir. Mit ,,nicht läuft" meine ich nur, dass einige der Steuerungsbefehle nicht an der Heizung ankommen. Das passiert nie bei vcontrold (wenn es von mir gestartet wurde), aber leider fast regelmäßig bei VCONTROL300.


Gesendet von iPad mit Tapatalk Pro
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

So, ich habe das jetzt. Ich habe mir ein neues Modul geschrieben, das ich VCLIENT nennen werde und in einem eigenen Thread vorstelle. Da ich das nur für mich nutze, habe ich mir bei der Doku jetzt nicht so wahnsinnig viel Mühe gegeben und werde das nur ausbauen, wenn sich jemand anderes dafür auch interessiert. Bei mir läuft es, und das war mir das wichtigste. Wieso ich VCONTROL oder VCONTROL300 nicht zum laufen bekommen habe, ist mir nach wie vor ein Rätsel. Ich vermute, dass es die Art und Weise ist, mit der FHEM die IR-Dioden anspricht. Wenn das vcontrold macht, ist alles bestens. Wenn das FHEM (und damit DevIO) macht, gab es einfach zu viel Probleme.

Der Thread ist der hier: https://forum.fhem.de/index.php/topic,78101.msg700396.html#msg700396
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

#164
Hat eigentlich jemand von Euch mal die Ansteuerung des Ferienprogrammes bei einer Vitotronic 200 hinbekommen? Ich kann (irgendwie) noch die An- und Abreisetermine setzen, aber das Ferienprogamm muss noch einen Haken gesetzt bekommen - und das gelingt mir nicht mit Optolink, weil ich die entsprechende Adresse nicht kenne und in den Unterlagen auch nichts finde.

<EDIT> Sehr schön auch die folgende Kommunikation mit der Heizung:

vctrld>setBetriebArtM1 RED
OK
vctrld>getBetriebArtM1
ABSCHALT
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann