Heizungssteuerung mit VCLIENT (Version 0.2.11f)

Begonnen von andies, 16 Oktober 2017, 21:51:13

Vorheriges Thema - Nächstes Thema

andies

Guten Tag, wie angekündigt hier meine Erfahrungen mit Viessmann und den hier vorliegenden Modulen. Zuerst: Ich finde VCONTROL und VCONTROL300 wirklich tolle Module, aber ärgerlicherweise habe ich sie nicht zum laufen bekommen (siehe die dortigen Threads). Das war einfach Schade und weil mich die Fehlersuche nicht weitergebracht hat, habe ich mich entschlossen, dass ganz anders technologisch zu machen.

Ich nutze den Daemon vcontrold, der hier schon mehrfach erwähnt wurde und dessen Installation und Inbetriebnahme man hier nachlesen muss: http://openv.wikispaces.com/Linux+Software. Mein Modul (ich bin Perlanfänger und bitte um Nachsicht, wenn da was komisch programmiert wurde) leistet nur eine Kommunikation zwischen vcontrold und FHEM. Das bedeutet: Die Heizung selbst wird direkt von vcontrold gesteuert. Wenn das dort nicht funktioniert, schafft mein Modul auch nichts. Es ist also notwendig, eine funktionierende vcontrold-Installation vorab vorzulegen.  Am besten testet man diese Installation, indem man sich mit dem entsprechenden Rechner verbindet (telnet host:port, standardgemäß ist der Port 3002 voreingestellt) und wartet, ob man den Daemon sieht. Eine typische Session sieht so aus:

pi@heizung:~ $ telnet localhost 3002
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
vctrld>

und gibt man nun commands ein, so kann man sich sämtliche installierten Kommandos anzeigen lassen:

vctrld>commands
getTempAbgas: Ermittle die Abgastemperatur in Grad C
getNeigungM1: Ermittle Neigung Heizkennlinie M1
getNeigungM2: Ermittle Neigung Heizkennlinie M2
getNiveauM1: Ermittle Niveau Heizkennlinie M1
...


Erst dann sollte man mit der Installation dieses Moduls fortsetzen.

Des weiteren benötigt man eine "Konfigurationsdatei". Diese Datei ordnet die gerade erwähnten Befehle des daemon möglichen Readings im FHEM-Gerät zu. Dies geschieht zeilenweise. Ich habe mein Beispiel einer Konfigurationsdatei angehängt. Derzeit kann ich nur eine Art von Befehlen implementieren: Nämlich ausschließlich Lesebefehle, die auch nur eine einzige Zahl wiedergeben. Schreibbefehle werden kommen, auch will ich timer auslesen. Aber alles nach und nach.

Ich mache das ja in erster Linie für mich. Daher habe ich wenig dokumentiert. Sollten aber andere Interesse an dem Modul haben, kann ich das gern ausbauen, einfach hier melden. Nur wenn ich der einzige bin, der VCONTROL300 nicht nutzen kann (was durchaus sein kann), würde ich mir den Wiki etc sparen. Vielen Dank an alle die anderen Modulautoren, mir haben die Vorlagen hier sehr geholfen und ich konnte eine Menge nutzen!

Weitere Hinweise finden sich in der Doku am Ende der Datei.

--------------------------------------------------------------------------------------------------------------------------------------------
<EDIT 20. Oktober 2017> Dank CoolTux ist es mir gelungen, eine nonblocking Version 0.2.0 hinzubekommen (gibt ein Bier beim nächsten Berliner Treffen!). Damit hängt FHEM nicht, wenn die Anlage bzw vcontrold nicht antwortet. Bei einem Timeout wird allerdings der gesamte Lesevorgang abgebrochen. Ich habe auch die Doku ein wenig ausgebaut, einfach auf "device specific help" klicken. Wer die alte Version noch installiert hat, muss FHEM komplett neu starten, weil einige neue globale Variablen gesetzt werden.

--------------------------------------------------------------------------------------------------------------------------------------------
<EDIT 21. Oktober 2017> Weiter geht es mit Version 0.2.1. Es können timer gelesen werden (nähere Hinweise, wie das geht, stehen in der Datei Vclient.cfg) und man kann auch auswählen, dass ein Reader nur einmal täglich gelesen wird (auch das steht in der *.cfg Datei, wie das geht). Falls das jemand einsetzen will, bitte FHEM komplett neu starten - sonst werden notwendige arrays nicht angelegt.

--------------------------------------------------------------------------------------------------------------------------------------------
<EDIT nochmal 21. Oktober 2017> Inzwischen können auch set-Kommandos gelesen und gesendet werden. Ich werde als nächstes versuchen, die Betriebsart zu setzen. Das ist bei mir etwas blöd, weil die nicht als Zahl, sondern als Zeichenkette in vctontrold kodiert ist.

--------------------------------------------------------------------------------------------------------------------------------------------
<EDIT 24/26. Oktober 2017> Jetzt kann man auch set-Kommandos mit timern senden. Dazu muss erneut die cfg angepasst werden, außerdem liefert das Setzen der Zeiten eine Fehlermeldung seitens vcontrold, die aber übergangen werden kann (ärgerlich ist es trotzdem). Ich füge beide Dateien, das Modul und meine config, an, damit man sieht, wie man das umsetzen könnte. Ich hoffe, es gelingt auch anderen!  (Bei mir kann man die Betriebsarten nicht setzen, nur lesen. Das gilt auch für das Ferienprogramm. Es scheint an der Steuerung selbst zu liegen, konkret am "Softwarestand".)

Bitte FHEM neu starten, wenn das jemand in einer alten Version nutzt.

--------------------------------------------------------------------------------------------------------------------------------------------
<EDIT 28. Oktober 2017> Ich habe einen weitern Programmierfehler behoben. Ich habe jetzt mehrere Timer-Befehle, um zum Beispiel so etwas wie einen Ferienbetrieb zu simulieren (also man kann mit mehreren Befehlen die Warmwasserzeiten geschlossen ändern - mal vormittags sehr früh, mal vormittags eher später). Bisher ging das nicht.

--------------------------------------------------------------------------------------------------------------------------------------------
<EDIT 08. November 2017> Bei Fehlermeldungen im Verbindungsaufbau wird im STATE jetzt Error geschrieben. Da gleichzeitig das automatische update unterbrochen wurde, kann man auf diese Weise die Abbrüche weiter verarbeiten (zum Beispiel mit notify mit Nachricht oder Wieder-Einstellen des updates).

------------------------------------------------------------------------------------------------------------------------------------------
<EDIT 01.Mai 2018> Mehrere Set-Befehle bei gleichzeitiger Eingabe wurden wegen eines Fehlers im Programm nicht ausgeführt; klappt jetzt.
------------------------------------------------------------------------------------------------------------------------------------------
<EDIT 14.September 2018> Fehler behoben, wenn vcontrold nicht erreichbar ist.
------------------------------------------------------------------------------------------------------------------------------------------
<EDIT 12.Dezember 2018> Phantom wollte noch einen Integritätscheck, ist eingebaut. Außerdem werden bei Fehlern die Fehlerangaben selbst nicht mehr in der Reading geschrieben; das Reading bleibt unverändert. Mindestens zwei bugs wurden entfernt.
------------------------------------------------------------------------------------------------------------------------------------------
<EDIT 22.Dezember 2018> Englische commandref, bug von Phantom weiter behoben (Warnings entfernt).
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

Also so einfach, wie ich mir das vorgestellt habe, wird es nicht. Ich habe gestern Nacht folgendes im Log gesehen:
2017.10.17 01:31:10 5: commands: getTempA for Aussentemperatur
2017.10.17 01:31:11 5:
2017.10.17 01:31:11 5: 0
2017.10.17 01:31:11 5:
2017.10.17 01:31:11 5: commands: getTempWWist for Warmwassertemperatur
2017.10.17 01:31:12 5: vctrld>13.300000 Grad

2017.10.17 01:31:12 5: 3
2017.10.17 01:31:12 5: 13.300000
2017.10.17 01:31:12 5: commands: getBrennerStarts for Brennerstarts
2017.10.17 01:31:13 5: vctrld>48.799999 Grad

Man sieht, dass vcontrold zu spät antwortet und daher die Readings durcheinander geraten: In den brennerstarts stehen dann Temperaturen etc.

Und das bedeutet, die Sache wird schwieriger. Ich habe in einem anderen Thread über Details geschrieben: https://forum.fhem.de/index.php/topic,78085.msg700507.html#msg700507. Es gab schon einen Grund, warum das so schwierig mit den anderen Modulen war... 
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

CoolTux

Ich habe mal drüber geschaut. Hast Du Lust ein Versuch zu starten mit dem Gerüst was ich Dir im anderen Thread gegeben habe. Ich würde dann vorschlagen wir machen erstmal ein Spieldevice zum testen. Nur das nötigste das wir was einsenden können und schauen das wir was empfangen. Deine Befehle schicken wir dann später in eine Array Queue und fragen in der Read Funktion einfach immer ab ob da noch was im Array drin steckt, wenn ja rufe noch mal die Funktion zum abfragen auf.


while( my $obj = each %paths ) {
                unshift( @{$hash->{actionQueue}}, $obj );
            }

schickte alls in eine Queue


my $cmd            = pop( @{$hash->{actionQueue}} );

liest das letzte Element aus der Queue aus und sendet es dann als cmd telnet


FunktionZumSenden()
if( defined($hash->{actionQueue}) and scalar(@{$hash->{actionQueue}}) > 0 );

ruft noch einmal die senden Funktion auf wenn sich noch was in der Queue befindet und die senden Funktion holt sich dann wieder das letzte Element aus dem Queue Array


Nur mal das Du die Idee erkennst.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

CoolTux

Ich habe mir mal erlaubt Dir ein Beispiel Modul zu bauen. Ganz ganz einfach.

define myTest VLIENT_Test host port


Danach passiert gar nichts ausser anlegen des devices. Dann machst Du ein set connect und schaust mal ob schon ein Readings geschrieben wurde. Eventuell mit F5 Browser refresh machen. Denn Du sagtest ja das dauernd Daten kommen.
Wenn das passiert kommt stufe zwei. Du machst ein set telnetCmd BEFEHL und hoffst das eine Antwort kommt. Kann sein das die Antwort im Reading nicht zu sehen ist weil es ständig mit den anderen Daten beschrieben wird. Die Read Funktion schreibt alle erhaltenen Daten in das fhem log. Also das am besten immer parallel mit laufen lassen.


Versuch es einfach mal. Mal schauen was passiert. Ist ja nur ein Test
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

andies

Danke - schaue ich mir an, sobald ich Zeit habe!


<p style="font-size:small;"> Gesendet vom iPhone mit Tapatalk Pro</p>
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

#5
Das ist ja cool, das geht einfach so (ich habe leider den Code nicht kapiert, aber es klappt)! Wie kann ich nun Befehle senden? Und empfängt der einfach, wenn telnet etwas sendet? Ich habe das auf einem jungfräulichen System installiert. 

<EDIT> Jetzt muss ich trotzdem was doofes fragen. Mein Problem ist doch, dass bei mir die Sache FHEM blockiert. Wird durch select die Blockade überwunden? Aber wie erfährt dann sysread oder VCLIENT_Test, wann etwas zum abholen da ist? Ich hätte sonst einen array programmiert, der die nächsten Schritte (sei es lesen oder schreiben) enthält und dann langsam abgearbeitet würde; aber der Code ist hier ja stark.
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

CoolTux

#6
Was senden kannst Du jetzt erstmal im Frontend über set telnetCmd und dann das was Du senden willst. Irgendwie glaube so getTemp oder so hieß der Befehl.
Die Antwort sollte dann wie gesagt im Reading stehen, wird aber sicherlich schnell überschrieben. Schau also bitte ins fhem log.

Wir haben unsere Verbindung in die select Liste gesteckt. Nun kümmert sich die FHEM Hauptschleife darum. Sobald Daten zum abholen anliegen wird fhem.pl unsere Read Funktion aufrufen und die Daten werden abgeholt.
Hier wird nun nichts mehr blockiert.

Schau bitte erstmal ob das so geht wie ich denke. Also mach ein set telnetCmd und schaue dir mit tail -f /opt/fhem/log/fhem-... an ob die richtige Antwort kommt.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

andies

#7
ich bin (fast) sprachlos. Es klappt:

2017.10.17 20:56:12 3: VCLIENT_Test (Test) - defined with host 192.168.2.105 and Port 3002
2017.10.17 20:56:15 3: VCLIENT_Test (Test) - received buffer data, start VCLIENT_Test_ProcessRead: vctrld>
2017.10.17 20:58:33 3: VCLIENT_Test (Test) - received buffer data, start VCLIENT_Test_ProcessRead: vctrld>
2017.10.17 21:13:49 3: VCLIENT_Test (Test) - received buffer data, start VCLIENT_Test_ProcessRead: vctrld>
2017.10.17 21:15:45 3: VCLIENT_Test (Test) - received buffer data, start VCLIENT_Test_ProcessRead: 14.100000 Grad

2017.10.17 21:15:45 3: VCLIENT_Test (Test) - received buffer data, start VCLIENT_Test_ProcessRead: vctrld>

und ich habe mehrere Versuche gebraucht, bis ich die richtige Syntax hatte (sendCmd).

OK, dann kann man so senden und empfangen. Wie ordnet man nun aber die Kommandos den Rückmeldungen zu? Also beispielsweise (ich übertreibe mal) wird 21:15 der erste Befehle gesandt, 21:16 der zweite und 21:17 kommt die Rückmeldung des ersten und 21:18 des zweiten. Dann müsste man den Buffer irgendwie in ein array schreiben und dann zuordnen, oder? 

<EDIT-MIST> Es geht nicht immer durch. Es gibt also anscheinend doch manchmal Probleme:
2017.10.17 21:20:47 4: VCLIENT_Test (Test) - WriteFn called
2017.10.17 21:20:47 5: VCLIENT_Test (Test) - getTempA

2017.10.17 21:20:47 4: VCLIENT_Test (Test) - ReadFn gestartet
2017.10.17 21:20:47 3: VCLIENT_Test (Test) - received buffer data, start VCLIENT_Test_ProcessRead: ERR: >FRAMER: Error 05
Fehler send, Abbruch
Fehler beim ausfuehren von getTempA
vctrld>
2017.10.17 21:21:18 4: VCLIENT_Test (Test) - WriteFn called
2017.10.17 21:21:18 5: VCLIENT_Test (Test) - getTempA

2017.10.17 21:21:18 4: VCLIENT_Test (Test) - ReadFn gestartet
2017.10.17 21:21:18 3: VCLIENT_Test (Test) - received buffer data, start VCLIENT_Test_ProcessRead: ERR: >FRAMER: Error 05
Fehler send, Abbruch
Fehler beim ausfuehren von getTempA
vctrld>


<EDIT2> Ich war anscheinend nicht connected,
2017.10.17 21:22:37 4: VCLIENT_Test (Test) - Build socket connection
2017.10.17 21:22:37 4: VCLIENT_Test (Test) - Socket Connected
2017.10.17 21:22:37 4: VCLIENT_Test (Test) - ReadFn gestartet
2017.10.17 21:22:37 3: VCLIENT_Test (Test) - received buffer data, start VCLIENT_Test_ProcessRead: vctrld>
2017.10.17 21:22:44 4: VCLIENT_Test (Test) - WriteFn called
2017.10.17 21:22:44 5: VCLIENT_Test (Test) - getTempA

2017.10.17 21:22:46 4: VCLIENT_Test (Test) - ReadFn gestartet
2017.10.17 21:22:46 3: VCLIENT_Test (Test) - received buffer data, start VCLIENT_Test_ProcessRead: 14.000000 Grad

2017.10.17 21:22:46 4: VCLIENT_Test (Test) - ReadFn gestartet
2017.10.17 21:22:46 3: VCLIENT_Test (Test) - received buffer data, start VCLIENT_Test_ProcessRead: vctrld>
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

CoolTux

Ganz einfach. Wir lassen nicht zu das ein weiterer Befehl gesendet wird bevor nicht eine Anwort auf den abgesetzten Befehl kommt. Weitere Befehle kommen in die Array Queue.
Sobald die korrekte Antwort kommt wird im Array nachgeschaut ob noch ein Befehl drin ist, wenn ja wird noch mal die write funktion aufgerufen.

Interessant wird das rausfiltern von diesem dauerfeuer. Das nervt.
vctrld> wenn das kommt soll die antwort verworfen werden.


Und ich schlage vor wir beenden die Verbindung wenn das Array leer ist und bauen sie wieder auf wenn neue Befehle in der Array drin sind.


Versuche es Dir anhand der kleinen subs im Modul vorzustellen. im Grunde haben wir schon das aufbauen und beenden der Verbindung. Wir haben das schreiben und das lesen.
Alles was wir noch brauchen ist das aufbereiten vor dem schreiben und das aufbereiten nach dem lesen in separaten Funktionen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

andies

Klingt nachvollziehbar!


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

CoolTux

Du kannst wenn Du magst Dein Modul so weit wie möglich anpassen und wenn was klemmt dann fragst einfach noch mal nach  ;D
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

andies

#11
Danke!

Und hier stehen auch die Dinge, die in dem Modul ablaufen: https://wiki.fhem.de/wiki/DevelopmentModuleIntro#Ausf.C3.BChrung_von_Modulen Ich hatte das bisher schlichtweg überlesen.
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

Eine Sache ist mir noch eingefallen. Angenommen, ich sende zu einem Zeitpunkt X. Dann sollte ich intern ein timeout einbauen, damit nach Y Sekunden das Kommando gestrichen wird, wenn die Gegenseite nicht geantwortet hat.

Nehmen wir an, dass danach ein weiteres Signal gesendet wird. Dann besteht natürlich die Möglichkeit, dass erst jetzt die Antwort aus dem ersten Signal eintrifft. An dem Problem kann man nichts ändern, oder? Man muss nur darauf hinweisen, dass eben timeout nicht allzu kein sein darf. Korrekt?
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

CoolTux

Das von Dir beschriebene Szenario ist in der Tat nicht wirklich abfangbar. Würde aber auch zeigen die die Gegenstelle schon etwas seltsam reagiert.
Im "Normalfall" kommt eigentlich zeitnah die Antwort auf eine Anforderung.

Das Dumme ist halt das auf jeden Fall die Read Funktion aufgerufen werden muß. Du hast Glück das sie anscheinend kontinuierlich bei Dir aufgerufen wird, so könntest Du beim rausholen des Befehles auf der Queue einen timestamp unter hash->{helper} setzen und diesen bei nächsten aufruf der Read vergleichen. Ist er zu alt schaust du ob noch was in der queue ist und wenn ja rufst halt wieder die write funktion mit dem entsprechenden cmd aus der queue auf.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

andies

So sollte es gehen:
# Zum Mechanismus. ReadCommands liest alle auszufuehrenden Commandos in einen array.
# Dann oeffnet ReadCommands die Telnet-Connection und ruft Write auf.
#
# Write liest den genannten array. Ist er leer, wird Close_Connection aufgerufen. Ist er voll, wird das
# naechste command aufgerufen, aus dem array entfernt und an die Anlage geschickt. Gleichzeitig
# wird ein Timout gesetzt (das nach $timeout Sekunden die sub Timeout aufruft).
#
# 1. Moeglichkeit. Es wurde Read aufgerufen. Das geschieht (durch FHEM) nur dann, wenn ein Ergebnis empfangen wurde.
# Dies wird in das Reading geschrieben und der Timeout geloescht. Danach wird Write erneut aufgerufen.
#
# 2. Moeglichkeit. Es wurde Timeout aufgerufen. Dann wurde anscheinend kein Signal empfangen. Jetzt wird
# der Array geloescht und Connection_close aufgerufen. 
#
#                  Close
#                    ^     ---> Timeout -> Close
#                    |   /
#  ReadCommands -> Write ----> Read
#                     ^        |
#                     |        |
#                      --------
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