Neues Modul eingecheckt: 89_VCLIENT.pm

[andies]

Ich hatte das Modul zur Steuerung von Viessmann-Heizungen mit vcontrold bereits vor einiger Zeit entwickelt. Es ist jetzt offiziell eingecheckt. Dokumentation hängt am Modul selbst dran, auch einen Wiki-Eintrag habe ich bearbeitet: https://wiki.fhem.de/wiki/Vitotronic_200_(Viessmann_Heizungssteuerung) und dort Abschnitt drei.

Bitte hier Fehlermeldungen oder Fragen mitteilen, wenn das jemand nutzt.

(Vorheriger Thread, der ist aber geschlossen: https://forum.fhem.de/index.php/topic,78101.msg700396.html#msg700396)

[andies]

Ich habe eine unangenehme Beobachtung gemacht. Mit getSystemTime kann man bei vcontrold die Systemzeit abrufen, die erscheint als String. Eigentlich kann man mit setSystemTime die Zeit setzen, wobei da kein Argument verlangt wird - angeblich wird die Zeit des Rechners genommen. Bei mir kam dann aber der 1.1.1984 an, also nicht so gut.

Mit

Code Auswählen Erweitern

attr <device> userreadings SystemTimeDifference {
ReadingsVal($name,"SystemTime","") =~ /(\d+).(\d+).(\d+)\s(\d+):(\d+):\d+/;
my $r1=timelocal( 0, $5, $4, $1, $2-1, $3);
ReadingsTimestamp($name,"SystemTime","") =~ /^(\d+)-(\d+)-(\d+)\s(\d+):(\d+):\d+$/;
my $r2=timelocal( 0, $5, $4, $3, $2-1, $1);
return sprintf("%d" , ($r1-$r2)/60)}
}
lasse ich mir jetzt einfach die ungefähre Zeitdifferenz ausgeben und ändere das händisch bzw passe alle anderen Zeiten an, wenn dazu Anlass besteht.

[phantom]

Hi andies,

bei meiner Viessmann lässt sich die Zeit nur so setzen:

Code Auswählen Erweitern

# mit Abschalten der Einheitenumrechung zum Setzen von Zweierpaeckchen
JETZT=`date "+%C %y %m %d 0%u %H %M %S"`
RETURN=`$VITODIR/vclient -h localhost:3002 -c "unit off,setSystemTime $JETZT,unit on"`
G
Das läuft seit Jahren als cronjob um 04:00 täglich. Es klappt bei mir nur mit "unit off/on"

Gruß Phantom

[andies]

wie hieße denn der Befehl für beispielsweise heute? Irgendeine Uhrzeit?

Als ich das eingegeben hatte (ich habe da aber kein +C), war das Datum falsch. Das mit der unit off hatte ich gesetzt. Im code von vcontrold steht, dass man das Datum nicht setzen könne...

[phantom]

so für diese Uhrzeit mit Datum:
Mon Jan  7 20:38:45 CET 2019

vclient -h localhost:3002 -c "unit off,setSystemTime 20 19 01 07 01 20 38 45,unit on"

[andies]

genau das klappt bei meinem softwarestand nicht. Aus der unit.c des Quelltextes:

Code Auswählen Erweitern


int setSysTime(char *input, char *sendBuf, short bufsize)
{
    char systime[80];
    time_t tt;
    struct tm *t;

    // No parameter, set the current system time
    if (!*input) {
        time(&tt);
        t = localtime(&tt);
        bzero(systime, sizeof(systime));
        sprintf(systime, "%04d  %02d %02d %02d %02d %02d %02d",
                t->tm_year + 1900, t->tm_mon + 1, t->tm_mday, t->tm_wday,
                t->tm_hour, t->tm_min, t->tm_sec);
        // We put a blank in the year
        systime[4] = systime[3];
        systime[3] = systime[2];
        systime[2] = ' ';
        logIT(LOG_INFO, "current system time %s", systime);
        return string2chr(systime, sendBuf, bufsize);
    } else {
        logIT1(LOG_ERR, "Setting an explicit time is not supported yet"); <================
        return 0;
    }
}


[phantom]

Hm, mein vcontrold ist zwar recht alt (version 0.9 von 6/2010), aber der läuft recht stabil und auch mit dem setSysTime. Evtl. helfen meine Erfahrungen hierzu. Zur Info meine unit.c:

Code Auswählen Erweitern

int setSysTime(char *input,unsigned char *sendBuf,short bufsize) {
        char *bptr=sendBuf;
        char string[200];
        char systime[200];
        int hour,min;
        int count=0;
        time_t tt;
        struct tm *t;

        /* kein Parameter, setze aktuelle Systemzeit */
        if (!*input) {
                time(&tt);
                t=localtime(&tt);
                bzero(string,sizeof(string));
                bzero(systime,sizeof(systime));
                sprintf(systime,"%04d  %02d %02d %02d %02d %02d %02d",t->tm_year+1900,t->tm_mon+1,t->tm_mday,t->tm_wday,t->tm_hour,t->tm_min,t->tm_sec);
                /* wir fummeln uns nun ein Blank zwischen die Jahreszahl */
                systime[4]=systime[3];
                systime[3]=systime[2];
                systime[2]=' ';
                sprintf(string,"aktuelle Sys.Zeit %s",systime);
                logIT(LOG_INFO,string);
                return(string2chr(systime,sendBuf,bufsize));
        }
        else {
                sprintf(sendBuf,"Setzen von explizieten Zeit noch nicht unterstuetzt");
                logIT(LOG_ERR,"Setzen von explizieten Zeit noch nicht unterstuetzt");
                return(0);
        }
}

Das sieht nicht so anders aus. Die ViessmannVitotronic-200 Typ KW2 ist aus dem gleichen Jahr.
Einzige Probleme, die ich habe, sind manchmal recht zähe Antworten der Vitotronic. Es dauert machmal bis zu 3-4 sec. bis ein Wert zurückkommt.

Und:
Mein altes, von von FHEM unabhängiges, Auswertescript mit vclient ruft daher die Werte nicht nacheinander, sondern zugleich ab, so z.B.:

Code Auswählen Erweitern

./vclient -h localhost:3002 -c 'getTempA,getTempKist,getTempWWist,getBrennerStunden1,getBrennerStarts,getBrennerStatus,getPumpeStatusM1,getPumpeStatusM2,getPumpeStatusSp,' | awk 'NR%2==0 {print "'\''"$1"'\''"}' | tr '\n' ',' | sed 's/.$//'

Und dazwischen min. 1 Min Pause. (eine Pause ist insb. beim Zeit-Setzen nötig). Wenn ich die Vitotronic zu schnell befrage, reagiert sie minutenlang gar nicht mehr. Aktuell füllt das Auswertescript seit 2010 eine DB und unabhängig davon in Pausen dazwischen wird FHEM über VCLIENT.pm mit Werten gefüttert und hierüber werden nun auch die set-Kommandos abgesetzt.

Ich werde später mal auf deine aktuelle Version per FHEM-Update aktualisieren ...

[andies]

Ich werde später mal auf deine aktuelle Version per FHEM-Update aktualisieren ...

Mach unbedingt ein Backup. Ich habe eine deiner Änderungen nicht übernommen, ins Modul!

Ich könnte auch mal probieren, diese if-Abfrage zu löschen und vcontrold neu zu kompilieren.

[phantom]

Hi,
ich habe das Update durchgeführt und musste danach den Wert  timeout auf 15 hochsetzen, damit das Abholen von ca. 15 Werten wieder funktioniert.

Als nicht übernommene Differenz zu meiner letzten Version (Mitte Dez.18) habe ich nur Änderungen in Zeile 891 gefunden:
my $this_timeout = AttrVal( $name, 'timeout', '1'); #default value is 1 second
Dies sieht aber nun korrekt aus oder war da noch etwas anderes, was du nicht übernommen hast?

Habe noch 2 Fragen zum Abfrageablauf und den beiden timeout's:
- Werden mit update alle Werte nacheinander abgerufen und bezieht sich der Wert für timeout auf jede einzelne Abfrage oder auf alle zusammen? Ich habe beobachtet, daß die Antworten der Vitotronic immer länger dauern, je mehr Werte direkt hintereinander abgerufen werden.
- Wie genau wirkt sich dabei das internal_update_intervall aus? Ist dies die Pause zwischen den einzelnen Abfragen?

Bei meinen bisherigen Abfragen mit vclient aus dem vcontrol-Paket kann ich auch nicht schnell direkt hintereinander einzelne Werte per vclient abfragen, sondern dort geht es nur stabil, wenn alle abzufragenden Werte kommagetrennt zugleich im vclient angegeben werden.


und noch etwas:  Nach einem FHEM shutdown restart  läuft der VCLIENT nicht von allein im Abfrageintervall an. Erst wenn man einmal darin set reload_command_file ausführt, läuft der Abfragezyklus weiter. Dies sollte evtl. noch korrigiert werden.

Phantom

[andies]

- Werden mit update alle Werte nacheinander abgerufen und bezieht sich der Wert für timeout auf jede einzelne Abfrage oder auf alle zusammen? Ich habe beobachtet, daß die Antworten der Vitotronic immer länger dauern, je mehr Werte direkt hintereinander abgerufen werden.

Timeout bezieht sich auf jede einzelne Abfrage. Die Abfragen werden erfasst und in eine queue geschoben. Diese Queue wird dann Schritt für Schritt abgearbeitet. Bei jedem Befehl wird auf eine Antwort gewartet. Kommt die innerhalb von Timeout Sekunden, geht es weiter. Kommt sie nicht, wird die Queue geleert und die Abfrage abgebrochen. Ich selbst sende bis zu zehn Befehle auf einmal.

- Wie genau wirkt sich dabei das internal_update_intervall aus? Ist dies die Pause zwischen den einzelnen Abfragen?

Genau. Die Pause zwischen den Befehlen, die in einer Queue abgearbeitet werden.

und noch etwas:  Nach einem FHEM shutdown restart  läuft der VCLIENT nicht von allein im Abfrageintervall an. Erst wenn man einmal darin set reload_command_file ausführt, läuft der Abfragezyklus weiter. Dies sollte evtl. noch korrigiert werden.

OK, da muss ich mal nachdenken. Das geht eigentlich nur dann, wenn in den Internals ein Pfad zur Datei schon gesetzt ist. Man könnte bei der Initialisierung abfragen, ob es den Pfad gibt und dann schon starten. Ich hatte das so nicht vorgesehen. Aber das stimmt schon. Ich hoffe, dass ich das am Wochenende hinkriege; außerdem will ich ein paar mehr debug-Infos einbauen.

[andies]

PS Bei mir läuft beispielsweise das anstandslos durch

Code Auswählen Erweitern

Viessmann_Schalter:Heizung_an set Viessmann M1_1Mo_ein;set Viessmann M1_2Di_ein;set Viessmann M1_3Mi_ein;set Viessmann M1_4Do_ein;set Viessmann M1_5Fr_ein ;set Viessmann M1_6Sa_ein ;set Viessmann M1_7So_ein ;set Viessmann M2_1Mo_ein ;set Viessmann M2_2Di_ein ;set Viessmann M2_3Mi_ein ;set Viessmann M2_4Do_ein ;set Viessmann M2_5Fr_ein;set Viessmann M2_6Sa_ein;set Viessmann M2_7So_ein
und die Befehle sind hier definiert

Code Auswählen Erweitern

setTimerM1Mo M1_1Mo_ein 06:00-22:00|||
setTimerM1Di M1_2Di_ein 06:00-22:00|||
setTimerM1Mi M1_3Mi_ein 06:00-22:00|||
setTimerM1Do M1_4Do_ein 06:00-22:00|||
setTimerM1Fr M1_5Fr_ein 06:00-22:00|||
setTimerM1Sa M1_6Sa_ein 06:00-22:00|||
setTimerM1So M1_7So_ein 06:00-22:00|||
setTimerM2Mo M2_1Mo_ein 05:30-21:00|||
setTimerM2Di M2_2Di_ein 05:30-21:00|||
setTimerM2Mi M2_3Mi_ein 05:30-21:00|||
setTimerM2Do M2_4Do_ein 05:30-21:00|||
setTimerM2Fr M2_5Fr_ein 05:30-21:00|||
setTimerM2Sa M2_6Sa_ein 05:30-21:00|||
setTimerM2So M2_7So_ein 05:30-21:00|||


[phantom]

mit einem Intervall von 900sec fragt FHEM mit folgender config die Viessmann ab:

Code Auswählen Erweitern

# Informationen Nur-Lesen
getTempA                Aussentemperatur
getTempKist             TempIst_Kessel
getTempWWist            TempIst_Warmwasser
getTempVListM2          TempIst_VorlaufM2       manually
getTempRListM2          TempIst_RuecklaufM2     manually
getBrennerStarts        Brennerstarts
getBrennerStarts        BrennerstartsBisGestern daily
getPumpeStatusM1        Status_Pumpe_Haus       manually
getPumpeStatusM2        Status_Pumpe_Wellness   manually
getPumpeStatusSp        Status_Pumpe_Warmwasser manually
getPumpeStatusZirku     Status_Pumpe_Zirku      manually


# Temperatur-Sollwerte
getTempRaumNorSollM1    TempSoll_Haus           daily
getTempRaumRedSollM1    TempSoll_Haus_Reduz     daily
getTempRaumNorSollM2    TempSoll_Wellness       daily
getTempRaumRedSollM2    TempSoll_Wellness_Reduz daily
getTempWWsoll           TempSoll_Warmwasser     daily

setTempRaumNorSollM1    TempSoll_Haus           22,21,20,19,12,8
setTempRaumRedSollM1    TempSoll_Haus_Reduz     22,21,20,19,12,8
setTempRaumNorSollM2    TempSoll_Welllness      22,21,20,19,12,8
setTempRaumRedSollM2    TempSoll_Wellness_Reduz 22,21,20,19,12,8
setTempWWsoll           TempSoll_Warmwasser     50,60,15


# Betriebs-Parameter
getSystemTime            Systemzeit_Heizung     daily
getBetriebArtM1          Betriebsart_HausM1     daily
getBetriebArtM2          Betriebsart_WellnessM2 daily
getBetriebSparM1         Betriebsart_SparM1
getBetriebSparM2         Betriebsart_SparM2
getBetriebPartyM1        Betriebsart_PartyM1    manually
getBetriebPartyM2        Betriebsart_PartyM2    manually

#setBetriebArtM1                 Betriebsart_Haus       NORM,RED,WW,H+WW,ABSCHALT
#setBetriebArtM2                 Betriebsart_Haus       NORM,RED,WW,H+WW,ABSCHALT
setBetriebSparM1         Betriebsart_SparM1     0,1
setBetriebSparM2         Betriebsart_SparM2     0,1
setBetriebPartyM1        Betriebsart_PartyM1    0,1
setBetriebPartyM2        Betriebsart_PartyM2    0,1

Die Reihenfolge der zyklischen Abfrage ist doch von oben nach unten aller Werte außen manually oder daily, oder?
Dies klappt meistens mit den Mindest-Werten: timeout=15 und internal_update_interval=0.2.

Doch seit der letzen Version sehe ich öfters (5-6x mal Tag) folgende Debug's im FHEM-Log.

Code Auswählen Erweitern

2019.01.10 16:18:07 1: DEBUG>Vitotronic: buf ERR: read timeout
Fehler recv, Abbruch
Fehler beim ausfuehren von getBrennerStarts

oder

2019.01.10 16:48:47 1: DEBUG>Vitotronic: buf ERR: read timeout
Fehler wait, Abbruch
Fehler beim ausfuehren von getBetriebSparM1


Das sind Werten mitten aus der Abfrageliste, wobei ich dachte der Zyklus würde beim ersten timeout komplett abgebrochen.
Kannst du mir zu diesen Meldungen näheres sagen? Könnte gerne am WE das ganze noch mal genauer testen.

[phantom]

wenn man sich die Readings dazu anschaut zeigen die timestamps jedoch nicht die Reihenfolge der config-Datei (s. Anlage)
wie ist das mit der Abfragereihenfolge genau vorgesehen?

und könnte man aus den zeitlichen Unterschieden das optimale, minimale timeout ermitteln?
(wenn die Reihenfolge bekannt und fix ist)

Gruß Phantom

[andies]

Die Reihenfolge der zyklischen Abfrage ist doch von oben nach unten aller Werte außen manually oder daily, oder?

Genau, von oben nach unten. Die Readings werden dann mE alphabetisch geordnet.

Doch seit der letzen Version sehe ich öfters (5-6x mal Tag) folgende Debug's im FHEM-Log.
Das sind Werten mitten aus der Abfrageliste, wobei ich dachte der Zyklus würde beim ersten timeout komplett abgebrochen.

Ja, wird er auch. Das habe ich ab und an auch. Dann war es so, dass bei Erreichen dieses Befehls keine Antwort innerhalb der Timeout-Grenze kam. Oder die Antwort nicht verstanden wurde. Ich habe die leidige Erfahrung gemacht, dass das bei mir an den Dioden lag. Wenn die etwas zu starke Abweichungen hatten, ging es nicht. Ein anderes Mal war es das Optolink-Kabel (Selbstbau), da fehlte Schirmung. Das war also bei mir außerhalb des Moduls. Das würde ich da auch vermuten. Ich habe das einmal am Tag und das wird dann ignoriert.

[andies]

ich habe das Update durchgeführt und musste danach den Wert  timeout auf 15 hochsetzen, damit das Abholen von ca. 15 Werten wieder funktioniert.

Nach einem FHEM shutdown restart  läuft der VCLIENT nicht von allein im Abfrageintervall an. Erst wenn man einmal darin set reload_command_file ausführt, läuft der Abfragezyklus weiter. Dies sollte evtl. noch korrigiert werden.

Das sollte mit dem nächsten update (demnächst) behoben sein. Hat eine Weile gedauert, sorry.

[khk123]

Hab vcontrol auf eine Raspi Zero W laufen und frage über den VCLIENT Werte ab. Dabei fällt mir auf, dass es immer ein Wert gibt bei dem Fehler kommen. Es tauchen nach dem Neuladen der vclient.cfg ein fehlerhafter Wert auf, der dann auch regelmäßig falsch ankommt. Direkt auf dem PZero kommt eine korrekte Antwort für diesen Abfragewert. Gibt es evtl.  ein Timingproblem beim Abfragen über VCLIENT?

Noch eine Frage: Warum taucht im Log "try to execute set command AZ_Vitronic ?" auf. Ich habe keine Set-Commands aktiviert.

FHEM ist auf dem aktuellen Stand und "89_VCLIENT.pm 18441 2019-01-28 16:21:00Z andies" ist aktuell.

Log-Auszug

Code Auswählen Erweitern


2019.01.30 17:28:27 5: AZ_Vitronic: vcontrold opened
2019.01.30 17:28:27 5: AZ_Vitronic: Requesting getTempWWist now
2019.01.30 17:28:29 1: DEBUG>AZ_Vitronic: buf ERR: Ergebnis falsch, Abbruch
Fehler beim ausfuehren von getTempWWist

2019.01.30 17:28:29 3: AZ_Vitronic: Received AZ_Vitronic: Unkown buffer format for Temp_Warmwasser_ist
2019.01.30 17:28:31 5: AZ_Vitronic: Requesting getTempKist now
2019.01.30 17:28:32 3: AZ_Vitronic: Received 49.0 for Temp_Kessel_ist
2019.01.30 17:28:32 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.30 17:28:33 5: AZ_Vitronic: Requesting getTempKsoll now
2019.01.30 17:28:35 3: AZ_Vitronic: Received -0.1 for Temp_Kessel_soll
2019.01.30 17:28:35 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.30 17:28:36 5: AZ_Vitronic: Requesting getTempA now
2019.01.30 17:28:38 3: AZ_Vitronic: Received 3.6 for Aussentemperatur
2019.01.30 17:28:38 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.30 17:28:39 5: AZ_Vitronic: Requesting getBrennerStarts now
2019.01.30 17:28:41 3: AZ_Vitronic: Received 20004 for Brennerstarts
2019.01.30 17:28:41 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.30 17:28:44 5: AZ_Vitronic: Closing vcontrold connection
2019.01.30 17:28:44 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?


Meine vclient.cfg

Code Auswählen Erweitern


##### VCLIENT-Konfigurationsdatei #########

# Werte zyklisch
getTempKsoll            Temp_Kessel_soll 
getTempA                 Aussentemperatur
getTempKist             Temp_Kessel_ist_0
getTempKist             Temp_Kessel_ist
getTempWWist            Temp_Warmwasser_ist
#getTempVListM2         Temp_VorlaufM2_ist       
getBrennerStarts        Brennerstarts
getBrennerStarts        Brennerstarts_bis_gestern daily
getBrennerStunden1      Brennerstunden            daily

# Soll-Werte
getTempKsoll           Temp_Kessel_soll          daily   
getTempRaumNorSollM1   Temp_Haus_soll            daily
getTempRaumRedSollM1   Temp_Haus_Reduz_soll      daily
#getTempRaumNorSollM2  Temp_Raum soll_M2         daily
#getTempRaumRedSollM2  Temp_Raum_Reduz_soll_M2   daily
getTempPartyM1         Temp_Party_soll           daily
getTempPartyM2         Temp_Party_Reduz_soll     daily
getTempWWsoll          Temp_Warmwasser_soll      daily

# Timer-Werte
getTimerM1Mo           Heizung1_1Montag          manually
getTimerM1Di           Heizung1_2Dienstag        manually
getTimerM1Mi           Heizung1_3MIttwoch        manually
getTimerM1Do           Heizung1_4Donnerstag      manually
getTimerM1Fr           Heizung1_5Freitag         manually
getTimerM1Sa           Heizung1_6Samstag         manually
getTimerM1So           Heizung1_7Sonntag         manually
getTimerM2Mo           Heizung2_1Montag          manually
getTimerM2Di           Heizung2_2Dienstag        manually
getTimerM2Mi           Heizung2_3Mittwoch        manually
getTimerM2Do           Heizung2_4Donnerstag      manually
getTimerM2Fr           Heizung2_5Freitag         manually
getTimerM2Sa           Heizung2_6Samstag         manually
getTimerM2So           Heizung2_7Sonntag         manually
getTimerWWMo           Warmwasser_1Montag        manually
getTimerWWDi           Warmwasser_2Dienstag      manually
getTimerWWMi           Warmwasser_3Mittwoch      manually
getTimerWWDo           Warmwasser_4Donnerstag    manually
getTimerWWFr           Warmwasser_5Freitag       manually
getTimerWWSa           Warmwasser_6Samstag       manually
getTimerWWSo           Warmwasser_7Sonntag       manually

# Betriebs-Parameter
getSystemTime          Systemzeit_Heizung       manually
getBetriebArtM1        Betriebsart_Haus         manually
getBetriebSparM1       Betriebsart_SparM1       manually
getBetriebSparM2       Betriebsart_SparM2       manually
getBetriebPartyM1      Betriebsart_PartyM1      manually
getBetriebPartyM2      Betriebsart_PartyM2      manually
getPumpeStatusM1       Status_Pumpe_Haus        manually


#setBetriebArtM1       Betriebsart_Haus         NORM,RED,WW,H+WW,ABSCHALT
#setBetriebArtM2       Betriebsart_Haus         NORM,RED,WW,H+WW,ABSCHALT
#setBetriebSparM1      Betriebsart_SparM1       0,1
#setBetriebSparM2      Betriebsart_SparM2       0,1
#setBetriebPartyM1     Betriebsart_PartyM1      0,1

#setTempRaumNorSollM1  Temp_Haus_soll           22,21,20,19,12,8
#setTempRaumRedSollM1  Temp_Haus_Reduz_soll     22,21,20,19,12,8
#setTempRaumNorSollM2  Temp_Raum_soll_M2        22,21,20,19,12,8
#setTempRaumRedSollM2  Temp_Raum_Reduz_soll_M2  22,21,20,19,12,8
#setTempWWsoll         Temp_Warmwasser_soll     50,60,15


...und die VCLIENT Definition

Code Auswählen Erweitern


Internals:
   .prompt    /vctrld>$/
   DEF        192.168.1.25 3002 vclient.cfg 900
   FILE       vclient.cfg
   FUUID      5c4f25c2-f33f-2526-b510-c43f832d3b22eb18
   INTERVAL   900
   IP         192.168.1.25
   NAME       AZ_Vitronic
   NR         409
   PORT       3002
   STATE      disconnected
   TYPE       VCLIENT

Attributes:
   DbLogInclude .*
   group      Heizung
   internal_update_interval 1.5
   room       Heizung
   timeout    15
   verbose    5


[andies]

Direkt auf dem PZero kommt eine korrekte Antwort für diesen Abfragewert. Gibt es evtl.  ein Timingproblem beim Abfragen über VCLIENT?

Kannst Du mir mal so eine vcontrold-Kommunikation zeigen? Es kann in der Tat ein timing-Problem geben, so was hatte ich hier auch. Wenn ich ehrlich bin, verstehe ich  das nur bedingt, denn die Kommunikation ist ja eigentlich so schnell, dass das nicht vorkommen soll. Ich habe dann die Abstände zwischen den Abfragen so lange angepasst, bis es ging.

Noch eine Frage: Warum taucht im Log "try to execute set command AZ_Vitronic ?" auf.

Auch dahinter bin ich noch nicht gekommen (ich bin etwas neu bei dieser Art Programmierung, sorry). Das Fragezeichen zeigt, dass in Wirklichkeit kein set-Befehl gesendet wurde. Das scheint eine Art null-Kommunikation zwischen Server und Controller zu sein, bei dem dann am Ende aber keine Befehle geschickt werden. Ich ignoriere das, weil ich es nicht verhindern konnte (höchstens bei der Ausgabe, so dass man es nicht sieht - aber das hast Du ja nur bei verbose 5, sonst ohnehin nicht).

[khk123]

Hab dir mal ein Screenshot der direkten Abfrage von 10:28 angehängt.

Ansonsten hat sich von gestern Abend bis heute früh nichts geändert. Der Wert für TempWWist wird von VCLIENT regelmäßig als fehlerhaft erkannt. Interessant ist allerdings, dass der erst Abruf von VCLIENT (10:35:43) nach der manuellen Abfrage (10:28) einen korrekten Wert für TempWWist findet. Muss mal probieren, ob das nur zufällig oder regelmäßig so ist.

Der Wert von TempKSoll liegt übrigens immer (auch bei der manuellen Abfrage) bei -0.1. Ich habe einen Vitodens 333-F mit einer Vitotronic 200. Die Abfrage getDevType bringt bei vcontrold "UNKNOWN" zurück. Anscheinen ist TempKSoll nicht an der gesuchten Stelle abgespeichert. Stört mich aber nicht besonders.

Das "try to execute set command AZ_Vitronic ?" stört mich auch nicht, da verbose=5 normalerweise nicht gesetzt ist. Allerdings, was passiert wenn der versuchte set einen command finden sollte?

Hier das Log von 10:20 bis 10:51:

Code Auswählen Erweitern


2019.01.31 10:20:22 5: AZ_Vitronic: will now update readings
2019.01.31 10:20:24 5: AZ_Vitronic: Opening vcontrold connection to 192.168.1.25:3002
2019.01.31 10:20:24 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.31 10:20:24 5: AZ_Vitronic: vcontrold opened
2019.01.31 10:20:24 5: AZ_Vitronic: Requesting getTempWWist now
2019.01.31 10:20:27 1: DEBUG>AZ_Vitronic: buf ERR: Ergebnis falsch, Abbruch
Fehler beim ausfuehren von getTempWWist

2019.01.31 10:20:27 3: AZ_Vitronic: Received AZ_Vitronic: Unkown buffer format for Temp_Warmwasser_ist
2019.01.31 10:20:29 5: AZ_Vitronic: Requesting getTempKist now
2019.01.31 10:20:30 3: AZ_Vitronic: Received 65.3 for Temp_Kessel_ist
2019.01.31 10:20:30 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.31 10:20:31 5: AZ_Vitronic: Requesting getTempKsoll now
2019.01.31 10:20:33 3: AZ_Vitronic: Received -0.1 for Temp_Kessel_soll
2019.01.31 10:20:33 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.31 10:20:34 5: AZ_Vitronic: Requesting getTempA now
2019.01.31 10:20:36 3: AZ_Vitronic: Received 2.1 for Aussentemperatur
2019.01.31 10:20:36 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.31 10:20:37 5: AZ_Vitronic: Requesting getBrennerStarts now
2019.01.31 10:20:39 3: AZ_Vitronic: Received 20014 for Brennerstarts
2019.01.31 10:20:39 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.31 10:20:42 5: AZ_Vitronic: Closing vcontrold connection
2019.01.31 10:20:42 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?

2019.01.31 10:35:42 5: AZ_Vitronic: will now update readings
2019.01.31 10:35:43 5: AZ_Vitronic: Opening vcontrold connection to 192.168.1.25:3002
2019.01.31 10:35:43 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.31 10:35:43 5: AZ_Vitronic: vcontrold opened
2019.01.31 10:35:43 5: AZ_Vitronic: Requesting getTempWWist now
2019.01.31 10:35:45 3: AZ_Vitronic: Received 50.5 for Temp_Warmwasser_ist
2019.01.31 10:35:45 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.31 10:35:47 5: AZ_Vitronic: Requesting getTempKist now
2019.01.31 10:35:48 3: AZ_Vitronic: Received 65.6 for Temp_Kessel_ist
2019.01.31 10:35:48 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.31 10:35:50 5: AZ_Vitronic: Requesting getTempKsoll now
2019.01.31 10:35:51 3: AZ_Vitronic: Received -0.1 for Temp_Kessel_soll
2019.01.31 10:35:51 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.31 10:35:53 5: AZ_Vitronic: Requesting getTempA now
2019.01.31 10:35:54 3: AZ_Vitronic: Received 2.6 for Aussentemperatur
2019.01.31 10:35:54 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.31 10:35:56 5: AZ_Vitronic: Requesting getBrennerStarts now
2019.01.31 10:35:57 3: AZ_Vitronic: Received 20014 for Brennerstarts
2019.01.31 10:35:57 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.31 10:36:00 5: AZ_Vitronic: Closing vcontrold connection
2019.01.31 10:36:00 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?

2019.01.31 10:51:00 5: AZ_Vitronic: will now update readings
2019.01.31 10:51:02 5: AZ_Vitronic: Opening vcontrold connection to 192.168.1.25:3002
2019.01.31 10:51:02 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.31 10:51:02 5: AZ_Vitronic: vcontrold opened
2019.01.31 10:51:02 5: AZ_Vitronic: Requesting getTempWWist now
2019.01.31 10:51:09 1: DEBUG>AZ_Vitronic: buf ERR: Ergebnis falsch, Abbruch
Fehler beim ausfuehren von getTempWWist

2019.01.31 10:51:09 3: AZ_Vitronic: Received AZ_Vitronic: Unkown buffer format for Temp_Warmwasser_ist
2019.01.31 10:51:10 5: AZ_Vitronic: Requesting getTempKist now
2019.01.31 10:51:12 3: AZ_Vitronic: Received 65.0 for Temp_Kessel_ist
2019.01.31 10:51:12 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.31 10:51:14 5: AZ_Vitronic: Requesting getTempKsoll now
2019.01.31 10:51:15 3: AZ_Vitronic: Received -0.1 for Temp_Kessel_soll
2019.01.31 10:51:15 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.31 10:51:17 5: AZ_Vitronic: Requesting getTempA now
2019.01.31 10:51:18 3: AZ_Vitronic: Received 3.5 for Aussentemperatur
2019.01.31 10:51:18 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.31 10:51:20 5: AZ_Vitronic: Requesting getBrennerStarts now
2019.01.31 10:51:21 3: AZ_Vitronic: Received 20014 for Brennerstarts
2019.01.31 10:51:21 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.31 10:51:24 5: AZ_Vitronic: Closing vcontrold connection
2019.01.31 10:51:24 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?


[khk123]

...beim Testen mit vcontrold auf dem piZero ist mir ist noch etwas aufgefallen. Nachdem ich getDevType abgefragt hatte, lieferte anschließend getTempWWist den fehlerhaften Wert. Eine erneute Abfrage getTempWWist ergab einen korrekten Wert. Ich konnte das Verhalten allerdings nicht reproduzieren. Sieht anscheinend so aus, als ob der Fehler doch eher bei vcontrold liegt.

Code Auswählen Erweitern


vctrld>getDevType
UNKNOWN
vctrld>getTempWWist
ERR: Ergebnis falsch, Abbruch
Fehler beim ausfuehren von getTempWWist
vctrld>getTempWWist
51.000000 Grad Celsius
vctrld>getTempWWist
51.200001 Grad Celsius
vctrld>getDevType
UNKNOWN
vctrld>getTempWWist
51.400002 Grad Celsius
vctrld>getTempWWist
51.299999 Grad Celsius
vctrld>getDevType
UNKNOWN
vctrld>getTempWWist
51.099998 Grad Celsius
vctrld>


[andies]

Anscheinen ist TempKSoll nicht an der gesuchten Stelle abgespeichert.

Ja, das ist dann an einer anderen Stelle kodiert oder eventuell auch gar nicht abrufbar?

Allerdings, was passiert wenn der versuchte set einen command finden sollte?

Den müsste er aus der cfg-Datei holen (woanders kann der nicht "entstehen") und wenn da keiner steht, passiert nichts. Ich muss mal CoolTux fragen, wie das entsteht. Der hat mir damals diesen Programmtipp gegeben. So habe ich das erst hinbekommen.

Code Auswählen Erweitern


2019.01.31 10:51:02 5: AZ_Vitronic: Requesting getTempWWist now
2019.01.31 10:51:09 1: DEBUG>AZ_Vitronic: buf ERR: Ergebnis falsch, Abbruch
Fehler beim ausfuehren von getTempWWist


Also, ich habe die Stelle gefunden, wo das entsteht, Zeile 441. Ich verstehe aber anhand des Screenshot nicht, wieso das passiert. Zur Erläuterung. Es kommt eine Rückmeldung von vcontrold, die kommt in einem buffer. Der enthält uU mehrere Zeilen (bei timern zum Beispiel). Diese Zeilen werden hier eingelesen (Zeile 390ff)

Code Auswählen Erweitern


my @zeilen=split /\n/, $buf;

und dabei wird für jede Zeile ein neuer Eintrag in dem Hash vorgenommen. Bei Dir ist das erstmal nur eine einzige Zeile mit der Temperatur.

Danach wird ausgerechnet, wie viel Zeilen übergeben wurden

Code Auswählen Erweitern


my $zeilen = @zeilen;

und da müsste 1 herauskommen. Dann gibt es eine Fallunterscheidung: Eine Zeile oder vier? Eine Zeile => dann die erste Zahl auswerten. Vier Zeilen => Das sind timer, auch auswerten. Bei Dir wird nun die dritte Möglichkeit in Anspruch genommen: Fehlermeldung?!

Oder ich mache was grundlegend falsch. Eventuell müssten wir mit der Hand da debuggen und sich mal den $buf direkt anschauen. Da musst Du aber unmittelbar in VCLIENT eingreifen. Können wir gern zusammen machen. Zum Beispiel so

Code Auswählen Erweitern


401    } else {
402 my @zeilen=split /\n/, $buf;
403 # Anzahl uebergebener Zeilen
404 my $zeilen = @zeilen;
+          for(my $i=0;$i < $zeilen; $i++){
+      Log3 $name, 5,  $zeilen[$i];
+              }

Ich habe das nur hier nicht getestet.

[khk123]

...hab die Abfrage mal eingebaut. Momentan sind die Updates korrekt. Sobald der fehlerhafte Wert wieder auftaucht melde ich mich.
Übrigens bei der nicht erfolgreichen Abfrage von getTempWWist kommen 2 Zeilen zurück und das läuft bei dir in den Zweig "# format der Ausgabe unbekannt". Vielleicht wäre es in dem Fall besser den Fehler zu melden. vcontrold meldet ja "ERR:" zurück.

Noch eine Frage, nur zu meinem Verständnis: Warum steht in $zeilen eigentlich der Wert 1? Das Array beginnt doch mit 0 und hat meist nur eine Zeile.

Code Auswählen Erweitern


vctrld>getTempWWist
ERR: Ergebnis falsch, Abbruch
Fehler beim ausfuehren von getTempWWist


[andies]

Warum steht in $zeilen eigentlich der Wert 1? Das Array beginnt doch mit 0 und hat meist nur eine Zeile.

@zeilen ist der array
$zeilen ist die Anzahl der Elemente im array
@#zeilen ist der höchste Index im array
$zeilen[index] sind die elemente.

Schon schräge Bezeichnungen. Als ich das zuerst sah dachte ich, ich spinne.

[khk123]

...und schon taucht ein fehlerhafter Wert auf:

Code Auswählen Erweitern


2019.01.31 17:27:50 5: AZ_Vitronic: Opening vcontrold connection to 192.168.1.25:3002
2019.01.31 17:27:50 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.31 17:27:50 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.31 17:27:50 5: AZ_Vitronic: vcontrold opened (khk)
2019.01.31 17:27:50 5: AZ_Vitronic: Requesting getTempKsoll now
2019.01.31 17:27:54 5: AZ_Vitronic KhK: Anzahl Zeilen: 2
2019.01.31 17:27:54 5: AZ_Vitronic KhK: Zeile 0: ERR: Ergebnis falsch, Abbruch
2019.01.31 17:27:54 5: AZ_Vitronic KhK: Zeile 1: Fehler beim ausfuehren von getTempKsoll
2019.01.31 17:27:54 1: DEBUG>AZ_Vitronic: buf ERR: Ergebnis falsch, Abbruch
Fehler beim ausfuehren von getTempKsoll

2019.01.31 17:27:54 3: AZ_Vitronic: Received AZ_Vitronic: Unkown buffer format for Temp_Kessel_soll
2019.01.31 17:27:56 5: AZ_Vitronic: Requesting getTempWWist now
2019.01.31 17:27:56 5: AZ_Vitronic KhK: Anzahl Zeilen: 1
2019.01.31 17:27:56 5: AZ_Vitronic KhK: Zeile 0: 41.700001 Grad Celsius
2019.01.31 17:27:56 3: AZ_Vitronic: Received 41.7 for Temp_Warmwasser_ist
2019.01.31 17:27:56 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.31 17:27:56 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.31 17:27:58 5: AZ_Vitronic: Requesting getTempA now
2019.01.31 17:27:59 5: AZ_Vitronic KhK: Anzahl Zeilen: 1
2019.01.31 17:27:59 5: AZ_Vitronic KhK: Zeile 0: 4.200000 Grad Celsius
2019.01.31 17:27:59 3: AZ_Vitronic: Received 4.2 for Aussentemperatur
2019.01.31 17:27:59 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.31 17:27:59 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.31 17:28:01 5: AZ_Vitronic: Requesting getBrennerStarts now
2019.01.31 17:28:02 5: AZ_Vitronic KhK: Anzahl Zeilen: 1
2019.01.31 17:28:02 5: AZ_Vitronic KhK: Zeile 0: 20015.000000
2019.01.31 17:28:02 3: AZ_Vitronic: Received 20015 for Brennerstarts
2019.01.31 17:28:02 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.31 17:28:02 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.31 17:28:04 5: AZ_Vitronic: Requesting getTempKist now
2019.01.31 17:28:05 5: AZ_Vitronic KhK: Anzahl Zeilen: 1
2019.01.31 17:28:05 5: AZ_Vitronic KhK: Zeile 0: 64.500000 Grad Celsius
2019.01.31 17:28:05 3: AZ_Vitronic: Received 64.5 for Temp_Kessel_ist
2019.01.31 17:28:05 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.31 17:28:05 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.31 17:28:08 5: AZ_Vitronic: Closing vcontrold connection
2019.01.31 17:28:09 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?
2019.01.31 17:28:09 5: AZ_Vitronic: try to execute set command AZ_Vitronic ?


...kurz danach die direkte Abfrage in vcontrold:

Code Auswählen Erweitern


pi@raspi-z:~ $ telnet localhost 3002
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
vctrld>getTempKsoll
-0.100000 Grad Celsius
vctrld>quit
good bye!
Connection closed by foreign host.


Ich denke der Fehler liegt in vcontrold. Evtl. ist dort ein Timing-Problem vorhanden.  ich suche mal in den issues
https://github.com/openv/openv/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc
von vcontrold, ob ich da etwas finde.

[khk123]

Schon schräge Bezeichnungen. Als ich das zuerst sah dachte ich, ich spinne.

Stimme ich dir zu.

[andies]

Dann passt es im Modul. Man könnte da noch ein wenig mehr Fehleranalyse einbauen, aber bei zwei Zeilen kommt halt nichts vernünftiges heraus.

So etwas kann zB an den Dioden liegen. Wie oft liest Du aus? Ich habe das früher alle 5' gemacht und bin jetzt bei 15'. Reicht auch. Versuch doch mal die Zeit zwischen den Abfragen hinauszuzögern. Da gibt es zwei Attribute, die machen das.


Gesendet von iPad mit Tapatalk Pro

[khk123]

Ich hole alle 15 Minuten ein paar Werte. timeout ist auf 15 sec eingestellt und internal_update_interval ist auf 1.5 sec. Ich erhöhe mal auf 2.5 sec und beobachte das Ganze.

Übrigens: Vielen Dank für die prompte Hilfe!

[khk123]

Die Erhöhung auf 2.5sec hat nichts gebracht. Die Fehler tauchen immer noch auf und kommen von vcontrold.

Code Auswählen Erweitern


2019.02.02 03:05:40 1: DEBUG>AZ_Vitronic: buf ERR: Ergebnis falsch, Abbruch
Fehler beim ausfuehren von getTempA

2019.02.02 03:05:40 3: AZ_Vitronic: Received AZ_Vitronic: Unkown buffer format for Aussentemperatur


Interessant ist auch, das getBrennerStarts einen fehlerhaften Wert liefert. Auch bei der direkten Abfrage in vcontrold kommt erst ein fehlerhafter Wert und bei einer unmittelbar danach gestarteten Abfrage ist der Wert richtig. Ich denke, dass es auch hier ein Timingproblem innerhalb von vcontrold gibt.

Code Auswählen Erweitern


2019.02.02 12:22:30 3: AZ_Vitronic: Received 1285 for Brennerstarts

vctrld>getBrennerStarts
1285.000000
vctrld>getBrennerStarts
20051.000000


Alles in allem: Es läuft etwas holperig, aber es läuft und ich kann damit leben.

[phantom]

Hi khk123,

Im VCLIENT bringt ein zu hohes  internal_update_interval eher Probleme, wenn die Antworten vom vcontrold manchmal zu langsam kommen. Bei mir laufen timeout=15 und internal_update_interval =0.4 prima.

Der vcontrold liest leider ab und zu unsinnige Daten aus der Viessmann, die wird man wohl einfach ignorieren und direkt verwerfen müssen. Das geschieht insbsondere bei zu häufigem Abfragen der Viessmann und wenn "Andere" die Viessmann oder den vcontrold ansprechen (z.B. ein Raumthermostat).

Ebenfalls kritisch ist die optische Ankopplung an die Vitotronic; habe dazu nach einigen Versuchen mit unpassenden IR-LED's doch den Optolink-Adapter eingesetzt und dafür gesorgt, daß kein Fremdlicht einstreuen kann. Beim Füttern einer Datenbank mit vcontrol-Werten sollte eine Plausibilitätsprüfung Unsinn verwerfen.

Vielleicht hilft das eine oder andere weiter.
Phantom

[khk123]

Hallo Phantom,

danke für die Hinweise. Es ist mir schon klar, dass die optische Anbindung nicht optimal ist. Ich habe die USB-Platine in einem kleinen Gehäuse (wie auf dem anh. Bild) an die Steuerung angeschlossen und über einen PiZero per WLAN an FHEM angekoppelt. Der Raum in dem die Heizung steht ist ohne Fenster und daher absolut dunkel. Fremdlicht kommt daher keines. Die Device-Id in vcontrold stimmt wohl auch nicht ganz für meine Steuerung. Es stimmen eigentlich alle Werte bis auf die Brennerstarts. Am Display sehe ich 08 56 57 und über vcontrold kommt 20121. Ich hab mal deine Werte für timeout und internal_update_interval übernommen.Mal sehen, ob sich etwas verändert.

[andies]

Schicker Adapter, wo hast Du den her? Ich habe so eine selbstgebastelte Krücke, die geht aber auch.

[khk123]

Hab ich mal vor Jahren gekauft. Weiter Infos unter https://github.com/openv/openv/wiki/Bauanleitung-USB. Dort findest Du die Bauanleitung und außerdem steht dort:

Wer sich die SMD Löterei nicht zutraut kann den Adapter bei mir bestellen. Ein fertig aufgebauter Adapter mit FT232RL kostet 29,80€, die schmale Variante mit CH340G 19,80€, beides jeweil zzgl. Versandkosten. Näheres unter   optolink@bytelink.de. Ein 3D gedrucktes Gehäuse könnt Ihr ebenfalls erwerben oder selbst drucken.

Das Gehäuse habe ich mir vor kurzem von https://www.meltwerk.com drucken lassen. Hat mit Versand knapp 13 € gekostet. Die 3D-Druckdatei ist auch auf der Github-Seite zu finden.

[andies]

ich habe gerade ein update eingecheckt und dabei einen Fehler behoben, dafür aber einen neuen gemacht. Also:

• Bisher war es so, dass bei einer Nichterreichbarkeit des fernen vcontrold-Servers faktisch FHEM totgelaufen ist (ich hatte das zwar bemerkt, es aber nicht auf mein Modul zurückgeführt). Das sollte jetzt behoben sein, es gibt eine Fehlermeldung und das ganze blockiert nicht mehr (war ein vergessenes Ausrufezeichen, so ein Mist).
• Dabei habe ich auch noch Kleinigkeiten bei verbose 5 hinzugefügt.
• Und einen neuen Fehler gemacht. Timeout setze ich jetzt defaultmäßig auf 5 Sekunden (und nicht eine), bei mir klappt das nie.

Dadurch sind zwei Updates oben und wer Timeout nicht gesetzt hat (als Attribut), könnte evtl einen Fehler bemerken. Bitte melden, wir reparieren das zusammen. Wer das Attribut gesetzt hat, sollte nichts bemerken.

[morbusp]

Hallo!
Vielen Dank für das Modul! Ich habe letzte Woche meinen alten Optolink aus 2015 auf der Heizung liegen sehen, der da nach mehreren frustranen Versuchen sein Dasein gefristet hat. Da die vcontrold-XMLs auf openv zufälligerweise perfekt zur 20C2 im Keller passen, ein arbeitsloser Raspi herumgelegen hat und ich mich vor anderen Sachen drücken wollte, habe ich der alten Geschichte nochmal eine Chance gegeben. Und siehe da: VCLIENT ist die Lösung für die damaligen Probleme (USB-Kabel in sinnlosen Längen, schlechtes WLAN, Devolos, die ausgerechnet dort auch nicht gut zu positionieren waren und ein schlichtes Scheitern an der Konfiguration).
Das Teil schnurrt und deshalb nochmals: herzlichen Dank für die Realisierung!