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.