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 (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).
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 (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...
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.
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
Danke - schaue ich mir an, sobald ich Zeit habe!
<p style="font-size:small;"> Gesendet vom iPhone mit Tapatalk Pro</p>
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.
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.
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>
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.
Klingt nachvollziehbar!
Gesendet von iPad mit Tapatalk Pro
Du kannst wenn Du magst Dein Modul so weit wie möglich anpassen und wenn was klemmt dann fragst einfach noch mal nach ;D
Danke!
Und hier stehen auch die Dinge, die in dem Modul ablaufen: https://wiki.fhem.de/wiki/DevelopmentModuleIntro#Ausf.C3.BChrung_von_Modulen (https://wiki.fhem.de/wiki/DevelopmentModuleIntro#Ausf.C3.BChrung_von_Modulen) Ich hatte das bisher schlichtweg überlesen.
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?
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.
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
# ^ |
# | |
# --------
So kann man es machen.
CoolTux, ich brauche nochmal Deine Hilfe. Ich habe versucht, alle Details aus VCLIENT_Test in meine Datei hinüberzunehmen (Datei hängt unten an). Mit Verbose 5 kann ich verfolgen, was alles passiert. Ich habe folgende Situation:
2017.10.19 17:43:17 5: Viessmann: execute get command Viessmann ?
2017.10.19 17:43:18 5: Viessmann: execute get command Viessmann update
2017.10.19 17:43:18 5: Viessmann: will now update readings
2017.10.19 17:43:18 5: Viessmann: Opening vcontrold connection to 192.168.2.105:3002
2017.10.19 17:43:18 5: Viessmann: vcontrold opened
2017.10.19 17:43:18 5: Viessmann: Requesting getBrennerStarts
2017.10.19 17:46:42 3: sduino IT_set: Steckdose_A on #also ein anderer Befehl, drei Minuten später - dazwischen nichts
und das heißt, er schickt das Kommando getBrennerStarts an Viessmann. Macht man das mit telnet, so erhält man etwa eine Sekunde später die Antwort. Hier ist es nun so, dass die Antwort von VCLIENT_Read abgefangen werden müsste, wenn ich das richtig verstanden habe. Aber VCLIENT_Read wird nicht aufgerufen (ich müsste sonst einen Log-Eintrag sehen, auch wenn da überhaupt nichts ankommt). Hast Du eine Idee, wieso das nicht geht?
<edit> Nochmal telnet (bitte die Einheit ignorieren):
$ telnet 192.168.2.105 3002
Trying 192.168.2.105...
Connected to raspheizung.fritz.box.
Escape character is '^]'.
vctrld>getBrennerStarts
165092.000000 Grad
vctrld>quit
good bye!
Connection closed by foreign host
Schaue ich mir nachher an. Dauert kleinen Moment.
Super, danke. Und ich weiß, dass das alles ehrenamtlich ist, also lass Dir Zeit.
<EDIT> Ich habe eine Idee. Es gibt eine Stelle, die ich nicht verstanden habe und anders behandelte. Nach der Definition einiger Routinen bei Dir stand da
my $hash = shift;
und ich habe das ersetzt durch
my ($hash) = @_;
Das wird es vermutlich sein, ich muss nur gleich weg und kann das nicht testen...
Du musst die Read und WriteFn doch noch entsprechend benennen.
$hash->{ReadFn} = "Modulname_Read";
$hash->{WriteFn} = "Modulname_Write";
Oder halt anders nennen. Aber das muss in die Initialize Funktion.
Es fehlt bei Dir auch noch die ganze Write Funktion
Danke, das war's. Jetzt liest er und ich muss noch kontrollieren, was da ankommt.
Mist, das war es leider nicht; ich muss nochmal nerven. Ich habe das inzwischen alles repariert, die Parameter genau so eingelesen wie in https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_Initialize etc beschrieben und auch die Read- und Write-Funktion gesetzt. Ich empfange auch etwas, aber eben nicht das Ergebnis. Derzeit mache ich es so (siehe Anhang), dass bei einem Empfang von vctrld> die Funktion VCLIENT_Read einfach "return" zurückgibt und damit wartet, ob es nochmal einen Rückmeldung gibt, weil sie ja dann erneut aufgerufen wird. (Es ist doch so, dass ich bei einem return innerhalb einer if-then-else-Abfrage die gesamte sub verlasse, oder?)
Diese kommt aber ärgerlicherweise nicht. Kann es sein, dass $buf zu klein ist? Aber 1024 müssten alle mal reichen?! So sieht der verbose 5-Log aus:
2017.10.19 22:17:55 5: Viessmann: execute get command Viessmann ?
2017.10.19 22:17:58 5: Viessmann: execute get command Viessmann update
2017.10.19 22:17:58 5: Viessmann: will now update readings
2017.10.19 22:17:58 5: Viessmann: Opening vcontrold connection to 192.168.2.105:3002
2017.10.19 22:17:58 5: Viessmann: vcontrold opened
2017.10.19 22:17:58 5: Viessmann: line = 7
2017.10.19 22:17:58 5: Viessmann: buf = vctrld> #habe ich mir ausgeben lassen
2017.10.19 22:17:58 5: Viessmann: received only prompt vctrld> #es wird erkannt, dass nur der Prompt ausgegeben wird
2017.10.19 22:17:58 5: Viessmann: Requesting getTempA #hier kommt erst der request
2017.10.19 22:18:22 5: Viessmann: execute get command Viessmann ? # und wieso passiert jetzt nichts? Kein Read aufgerufen?
Guten Morgen,
Ich trage erstmal zusammen
sub VCLIENT_Write($$)
{
my ( $hash, $message, $address) = @_;
Deiner Sub darfst Du max 2 Scalare übergeben. Innerhalb der Sub möchtest Du aber 2 auslesen. Das passt nicht. Übergib entweder $ Scalare oder ein Scalar und ein Array.
InternalTimer(gettimeofday()+ $my_internal_timer, "VCLIENT_Write", $hash, 1);
Du rufst die Write Funktion mit InternalTimer auf, dadurch verzögert. Ich weiß jetzt nicht wie hoch die Verzögerung ist. Und die 1 hinten am besten ganz weg nehmen. Die ist absolet. Also mit Komma davor weg.
Dann bau mal mehr Logausgaben ein. Nicht nur innerhalb von Abfragen sondern auch direkt nach dem auslesen.
Dann schaue einmal Deinen Subs. Was und wie viel übergibst Du und was liest Du davon ein. Da ist viel zu viel.
Und ganz wichtig, bitte niemals $hash->{STATE} beschreiben. Das wird vom Reading state gemacht. Also bitte nur das Reading state füllen.
Vielen, vielen Dank CoolTux: Es lag daran, dass ich beim Senden vergessen hatte am Ende ein "\r\n" zu setzen. Peinlich. Jetzt läuft alles. Ich habe da eine ganze Menge gelernt und vor allem die Angst vor der Modulprogrammierung verloren! Das war eine tolle Erfahrung.
Ich werde heute oder morgen (ich will länger testen) eine neue Version in den ersten Eintrag hier im Thread hochladen und entsprechend editieren. Danach setze ich mich mal an die set- und timer-Sachen. Wenn es noch zwei Leute hier im Forum gibt, die überlegen das Modul einzusetzen, dann würde ich mir noch mit einem Wikieintrag Mühe geben und überlegen es offiziell einzuchecken. Für mich alleine lohnt sich der Aufwand nicht. Also bitte melden, wenn es diese zwei Personen gibt; ich helfe auch gern beim einrichten.
So, set- und timer-Befehle gehen. Betriebsart kann ich noch nicht setzen, aber Temperaturen schon. Alles weitere im device specific help sowie dem allerersten Eintrag.
<edit> Nur zur Info: Die täglichen Brennerstarts erfasse ich (gegeben die genannte cfg-Datei) mit
attr <name> userReadings BrennerstartsNurGestern difference { ReadingsVal($name,"BrennerstartsBisGestern",0);;;; }
Ich kann nun endlich auch set-Befehle und insbesondere timer-Befehle für Heizung und Warmwasser senden. Das war ziemlich nervig, weil die Webseite openv (die ja kurz vor dem Abschalten steht) wirklich furchtbar ist. Man findet nichts, die Wikis sind nicht gepflegt und durchsetzt von Foren, bei denen es aber keine Antworten gibt, die Software ist nicht dokumentiert usw usf. Da merkt man mal, was für ein Glück es ist, dieses Forum zu haben.
Es kommt noch etwas hinzu. Timer werden zB so gesetzt:
setTimerWWMo 07:40 10:10 12:00 12:30 15:30 16:00 19:00 20:30
aber, und jetzt kommt es, ergibt das auch bei erfolgreicher Ausführung eine Fehlermeldung seitens vcontrold:
ERR: >FRAMER: addr was still active FE06
>FRAMER: Command send
>FRAMER: unexpected length 8 08
Fehler recv, Abbruch
Fehler beim ausfuehren von setTimerWWMo 07:40 10:10 12:00 12:30 15:30 16:00 19:00 20:40
Das scheint ein bug zu sein, den ich aber nicht reparieren kann. Da das Kommando durchgeht, reicht mir das. Alles weitere im ersten Post sowie device-specific-help.
Ich habe durch die Version, die jetzt oben liegt, gemerkt, dass ich langsam aber sicher an meine Programmiergrenzen in Perl stoße. Gerade die Übergabe von Parametern oder Syntaxprüfungen mit RegEx gehen zwar irgendwie, aber ich muss mir die Sachen aus anderen Programmen kopieren, weil ich keine rechten Ideen habe, wie das so geht. Also vermutlich wird bald hier Schluss sein. Zumal ich habe, was ich brauche.
Version 0.2.7, damit auch so etwas in der config-Datei geht:
setTimerWWMo WW_21Mo_aus 06:00-06:10|||
setTimerWWDi WW_22Di_aus 06:00-06:10|||
setTimerWWMi WW_23Mi_aus 06:00-06:10|||
setTimerWWDo WW_24Do_aus 06:00-06:10|||
setTimerWWFr WW_25Fr_aus 06:00-06:10|||
setTimerWWSa WW_26Sa_aus 06:00-06:10|||
setTimerWWSo WW_27So_aus 06:00-06:10|||
setTimerWWMo WW_11Mo_frueh 06:00-09:10|12:00-12:30|15:30-16:00|19:00-20:30
setTimerWWDi WW_12Di_frueh 06:00-09:00|12:00-12:30|15:30-16:00|19:00-20:30
setTimerWWMi WW_13Mi_frueh 06:00-09:00|12:00-12:30|15:30-16:00|19:00-20:30
setTimerWWDo WW_14Do_frueh 06:00-09:00|12:00-12:30|15:30-16:00|19:00-20:30
setTimerWWFr WW_15Fr_frueh 06:00-09:00|12:00-12:30|15:30-16:00|19:00-20:40
setTimerWWSa WW_16Sa_frueh 08:10-11:00|14:00-15:00|17:00-20:30|
setTimerWWSo WW_17So_frueh 08:10-13:10|16:00-17:00|18:50-20:30|
Ich beschreibe mal, zu welcher Lösung ich nun vorläufig endgültig gekommen bin. Ich hatte zuerst versucht, noch ein DOIF zu erstellen, so dass der Ferienbetrieb (also das Setzen der Wassertemperatur, der Raumtemperaturen und der Heizzeiten) in einem Befehl erfolgt. Das geht leider nicht, weil schon beim Setzen der Wassertemperatur vcontrold einen Fehler meldet und die Bearbeitung dann unterbrochen bzw abgebrochen wird. Da ich die Wassertemperatur nicht mehrfach täglich setzen möchte, lässt sich das verschmerzen.
Ich nehme derzeit folgende Vclient.cfg:
getTempA Aussentemperatur
getTempWWist Warmwassertemperatur
getTempKist Kesseltemperatur
getBrennerStarts Brennerstarts
getBrennerStarts BrennerstartsBisGestern daily
getTempRaumNorSollM1 RaumsollHaus manually
getTempRaumRedSollM1 RaumsollHausRed manually
getTempRaumNorSollM2 RaumsollWohnz manually
getTempRaumRedSollM2 RaumsollWohnzRed manually
getTempWWsoll WarmwasserSoll manually
getBetriebArtM1 BetriebHaus daily
getBetriebArtM2 BetriebWohnz daily
##Die Zahlen bei den readings sorgen fuer eine sinnvolle Anordnung der timer
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
getTimerFerienBeginn Ferienbeginn manually
getTimerFerienEnde Ferienende manually
setTempRaumNorSollM1 Haus_Soll 22,21,20,19,10
setTempRaumRedSollM1 Haus_Soll_Red 22,21,20,19,10
setTempRaumNorSollM2 Wohnz_Soll 22,21,20,19,10
setTempRaumRedSollM2 Wohnz_Soll_Red 22,21,20,19,10
setTempWWsoll WW_Soll 60,10
setTimerWWMo WW_11Mo_frueh 06:00-09:10|12:00-12:30|15:30-16:00|19:00-20:30
setTimerWWDi WW_12Di_frueh 06:00-09:00|12:00-12:30|15:30-16:00|19:00-20:30
setTimerWWMi WW_13Mi_frueh 06:00-09:00|12:00-12:30|15:30-16:00|19:00-20:30
setTimerWWDo WW_14Do_frueh 06:00-09:00|12:00-12:30|15:30-16:00|19:00-20:30
setTimerWWFr WW_15Fr_frueh 06:00-09:00|12:00-12:30|15:30-16:00|19:00-20:40
setTimerWWSa WW_16Sa_frueh 08:10-11:00|14:00-15:00|17:00-20:30|
setTimerWWSo WW_17So_frueh 08:10-13:10|16:00-17:00|18:50-20:30|
setTimerWWMo WW_21Mo_spaet 08:00-10:10|12:00-12:30|15:30-16:00|19:00-20:30
setTimerWWDi WW_22Di_spaet 08:00-10:00|12:00-12:30|15:30-16:00|19:00-20:30
setTimerWWMi WW_23Mi_spaet 06:10-10:00|12:00-12:30|15:30-16:00|19:00-20:30
setTimerWWDo WW_24Do_spaet 08:00-10:00|12:00-12:30|15:30-16:00|19:00-20:30
setTimerWWFr WW_25Fr_spaet 08:00-10:00|12:00-12:30|15:30-16:00|19:00-20:40
setTimerWWSa WW_26Sa_spaet 08:10-11:00|14:00-15:00|17:00-20:30|
setTimerWWSo WW_27So_spaet 08:10-13:10|16:00-17:00|18:50-20:30|
Damit werden die wichtigen Daten regelmäßig ausgelesen, der Rest (wie Solltemperaturen) nur bei Bedarf. In dem device kann ich dann händisch die Warmwasserzeiten setzen (sieben mal klicken), das klappt auch (weil ich danach die geänderten Daten manuell abrufe und ich sie unten an der Heizung nochmal kontrolliert habe). Das mache ich immer dann, wenn Schulferien beginnen oder enden.
Ebenso gehe ich mit den Raumtemperaturen um (vier Klicks). Die ändere ich, wenn ich länger, also für mehrere Tage, das Haus verlasse. Die Lösung läuft jetzt, in den nächsten Tagen sind wir mal für wenige Tage außer Haus, da teste ich das mal aus der Ferne und nicht im selben Netz. Aber das sollte genau so gehen wie gerade eben. Ich hoffe mal, ich kann jetzt das Basteln an der Lösung beenden; bin schon süchtig geworden.
Also mit brachialer Gewalt kriegt man den Fehler, dass timer nicht gesetzt werden können, auch in den Griff. Da ich alle Kommandos überprüft habe, ist das bei mir ok. Wer das nachmacht sollte sich sicher sein, was er/sie hier tut.
Ich habe in framer.c beim Quellcode von vcontrold (zum Beispiel https://github.com/c4rd0n/vcontrold/ oder https://github.com/openv/openv/) in Zeile 442 die Abfrage geändert. Da ist nämlich der Fehler. Wie er zustande kommt, weiß ich nicht. Ich weiß nur, dass zwei Längen verglichen werden und weil sie nicht gleich sind, wird angehalten. Der Vergleich ist fehlerhaft, weil der LEADIN für ein separates Kommando gehalten wird und so alles aus dem Tritt kommt. Schreibt man die Zeile wie folgt
if ((r_len != l_buf[P300_RESP_LEN_OFFSET]) && (l_buf[P300_RESP_LEN_OFFSET] != 8))
und neu ist dabei der Teil nach &&, dann gibt es keine Fehlermeldungen mehr und die Sache geht auch korrekt durch (nur timer haben ein l_buf[P300_RESP_LEN_OFFSET] von acht, sonst kommt das nicht vor). Aber wohler würde ich mich fühlen, wenn die Autoren des Codes sich dem mal annehmen würden. (Die originale vcontrold-Seite ist, wie vielleicht bekannt, gnadenlos verwaist und wird in drei Wochen wohl geschlossen.)
Also, am Anfang war das ja alles Spaß mit dem Löten und FHEM und so (und mehrere Freunde haben sich bei meinen Schilderungen an den Kopf gegriffen). Jetzt stellt sich ein nie beabsichtigter Nebeneffekt ein. Ich habe festgestellt, dass ich vor einigen Tagen 120 Brennerstarts pro Tag hatte (konnte ich ja früher nie bequem messen). Außerdem habe ich gesehen, dass das Wasser im Kessel permanent über 50 Grad warm ist - eigentlich ja schön, nur wenn hier nur morgens geduscht und abends bestenfalls Zähne geputzt werden?! Also habe ich angefangen, in Viessmann-Foren zu surfen, konnte aufgrund des Moduls mit vielen Details mitreden und Fragen stellen und musste feststellen, dass meine Anlage von meinem Heizungsbauer anscheinend reichlich falsch eingestellt wurde. Ohne die Zugriffe per FHEM wäre mir das nicht aufgefallen, es ist warm und alles scheinbar bestens.
Mal sehen, was alles noch passiert, wenn ich weiter irgendwo irgendwelche Sensoren einstelle. Langsam wird mir klar, wieso smart home eine wirklich tolle Sache ist. Man muss nur eine Menge Handarbeit investieren, und nicht die Fertigtools, die nicht miteinander kommunizieren können und Insellösungen darstellen.
So geht es mir auch gerade mit der Viessmann Regelung. ;D
Meine WP schaltet zum Glück nicht 120x am Tag ein, da wäre sie vermutlich ohnehin bald hinüber, aber es sind eben die Details.
Meine Modulierende WP z.B. moduliert nicht bei der WW Bereitung, da sind 3 Parameter falsch gesetzt; die Heizkreiselpumpe hat unnötig lange Laufzeiten auf 100% (40W);...
Dirch optimierung bei der WW Bereitung brauche ich bei dieser jetzt fast 30% weniger Energie und schone auch noch den Verdichter durch weniger Einschaltungen. ;)
Und das war jetzt alles vor der Heizperiode, mal schauen was noch alles auffällt wenn ich die Tage auch den Heizkreis in Betrieb nehme.
Lg
crispyduck
PS Jetzt bin ich von täglich 120 Brennerstarts auf 26 (gestern) runter...
Gesendet vom iPhone mit Tapatalk Pro
Siehste und schon hat sich die ganze Mühe gelohnt.
Grüße
Zitatdas Wasser im Kessel permanent über 50 Grad
wenn es ein Guss Kessel ist, wäre es auch nicht falsch, Stichwort Kondensat und Korrosion
Zitat von: andies am 29 Oktober 2017, 18:59:43
Also mit brachialer Gewalt kriegt man den Fehler, dass timer nicht gesetzt werden können, auch in den Griff.
Inzwischen gibt es dafür einen Patch, der auch bei mir funktioniert. Keine Probleme mehr:
https://github.com/openv/openv/issues/368#issuecomment-342448438 (https://github.com/openv/openv/issues/368#issuecomment-342448438)
Wenn man die Verbindung zum daemon verliert, erscheint bisher im Log folgende Fehlermeldung
2017.11.08 12:52:30 1: Viessmann: ERROR: Cannot open vcontrold connection, problem connecting to "192.168.2.105", port 3002: connect timed-out. Is vcontrold running?
2017.11.08 12:52:30 1: Viessmann: all of a sudden disconnected, this is an error
Man kann diese Fehlermeldung aber nicht "anfangen", weil das nur im Log steht. Jetzt wird im Reading state das Wort 'Error' eingestellt. Damit kann man Verbindungsabbrüche mit notify etc weiterbearbeiten.
Zitat von: andies am 04 November 2017, 08:32:28
PS Jetzt bin ich von täglich 120 Brennerstarts auf 26 (gestern) runter...
Gesendet vom iPhone mit Tapatalk Pro
was hast Du geändert?
Ich habe die Heizkörper voll geöffnet und nachts die Temperatur von 19 auf 10 Grad abgesenkt. Dann habe ich Warmwasser nicht durchgehend von 7-22 Uhr, sondern in vier unterschiedlichen Intervallen bereitgestellt (zB Donnerstag 6-9, 12-13, 15-16 und 19-21), weil ich gesehen habe, dass der Kessel immer noch heiß genug bleibt. Das hat es im Wesentlichen gebracht.
Nachts die Soll-Raum-Temperatur von Deiner Vissmann oder von den Raumthermostaten?
Wie steuerst Du die WW Intervalle? Mit dem internen Timer der Vissmann oder setzt Du manuell per notify/ doif?
Die Solltemperatur (habe keine HM o.Ä.). Und die WW-Intervalle sind fix. Meine Frau hat keinen Unterschied bemerkt zu vorher.
Gesendet vom iPhone mit Tapatalk Pro
Zitat von: andies am 29 Oktober 2017, 18:59:43(Die originale vcontrold-Seite ist, wie vielleicht bekannt, gnadenlos verwaist und wird in drei Wochen wohl geschlossen.)
Keine Panik!
Aufgeschreckt durch Dein Posting wollte ich einige Infos, die ich von dort habe, archivieren. Dann habe ich das hier gefunden:
ZitatMitteilung
Das openv wiki ist nach github umgezogen (https://github.com/openv/openv/wiki).
Die Diskussionen sind unter issues zu finden (https://github.com/openv/openv/issues).
Am 17.11.2018 wird dieses Wiki hier verschwinden.
Das sind ja noch etwas mehr als drei Wochen, und den Inhalt wird man auch weiterhin auf Github finden.
Grüße,
Manfred
Ein Jahr und 3 Wochen ;)
Ich möchte den VClient einsetzten wo kann ich den eine aktuelle Version finden?
Danke Klaus
Sorry hab's gefunden!
Habe eine neue Version eingestellt, siehe erster Post: Wenn vcontrold nicht erreichbar war, stürzte FHEM ab. Ist hoffentlich endgültig Vergangenheit.
Zitat von: andies am 06 Dezember 2017, 22:39:13
Dann habe ich Warmwasser nicht durchgehend von 7-22 Uhr, sondern in vier unterschiedlichen Intervallen bereitgestellt (zB Donnerstag 6-9, 12-13, 15-16 und 19-21), weil ich gesehen habe, dass der Kessel immer noch heiß genug bleibt. Das hat es im Wesentlichen gebracht.
Nur so ein paar Gedanken, weil ich diese ganze 'Heizungsoptimierungsgeschichte' auch hinter mir habe (ich habe allerdings nicht den gesamten Thread durchgelesen und kenne deine Anlage nicht, bspw hinsichtlich WW-Speicher etc.):
Unter Umständen kannst du diese WW-Zeiten sogar noch mehr einschränken und bspw. nur morgens und abends WW-Bereitung freigeben, wenn die 'Stoßzeiten' hinsichtlich Duschen, Baden etc. sind. Wenn keiner mehr nach 21Uhr duscht, brauchst du die späte Freigabe bspw auch nicht (aber natürlich ist das alles abhängig von deinem WW-Speichervolumen).
Ich habe festgestellt, dass man tagsüber mit weniger heißem Wasser auskommt, als man zuerst denkt - und nachts kann der Speicher ruhig etwas weiter auskühlen. Beim Duschen und selbst beim Abwaschen nach dem Mittagessen braucht man keine 55°C, da würde man sich recht zügig verbrühen und zapft daher eigtl auch immer kaltes Wasser mit. Im Zweifelsfall einfach mal die letztlich genutzte Wassertemp messen, das hilft einem schon weiter.
Bei mir gibts noch die alte Schwerkraftzirkulation, da macht sich der Wärmeverlust im WW-Speicher besonders in der kalten Jahreszeit recht deutlich bemerkbar. Solltest du eine Zirkupumpe haben, könntest du auch eine Zeitschaltuhr dafür einsetzen oder den bedarfsabhängigen Betrieb via Funktastern o.ä. steuern.
Ich weiß nicht, wie es bei Viessmann ist, aber bei meiner Brötje habe ich die Möglichkeit, einen manuellen TWW-Push auszuführen, so dass ich also bei Bedarf eine TWW-Ladung anstoßen kann, wenn doch mal außerhalb der Zeiten entsprechend heißeres Wasser benötigt wird.
Falls du bei dir einen 'gleitenden' oder 'absoluten' Betrieb für die WW-Bereitung einstellen kannst: Bei mir hat sich der 'absolute' Betrieb auch nochmal gelohnt. Der Heizkreis wird zwar in der Zeit nicht versorgt, dafür erfolgt die WW-Bereitung aber deutlich schneller. Es hilft auch, mal mit den Pumpeneinstellungen zu spielen - je nach Einstellung kann es hier nämlich auch sein, dass die Wärme nicht optimal an den WW-Speicher abgegeben wird und die Aufbereitung so länger dauert. Hier hilft es, wenn du die Kesseltemp, WW-Temp und Ladezeit im Auge behältst und vergleichst.
Hinsichtlich der HK-Pumpe gilt das Selbe: Eine eco-Funktion der Hocheffizienzpumpen ist zwar gut und schön, kann aber auch kontraproduktiv sein, wenn die Wärme nicht schnell genug vom Kessel weg kommt.
Dein Vorgehen, die HK-Thermostate voll aufzudrehen und die Raumtemp durch das Ermitteln der korrekten VL-Temp zu erreichen, ist absolut richtig. Meist sind die VL-Temps noch immer zu hoch eingestellt, so dass dann an den Thermostaten zuviel rumgeregelt wird. Bei den alten Gußheizkörpern muss sie dann natürlich höher sein, als bei den 'modernen' Flachheizkörpern, die nur aus dünnem Blech bestehen.
Gruß
Danke - inzwischen heize ich Warmwasserbereitung auch nur noch zweimal am Tage (und das zweite Mal nur kurz), als nächstes kommt im Winter die Heizkurve dran. Da ist wirklich sehr viel Spielraum, finde ich.
Gesendet von iPhone mit Tapatalk Pro
Hi andies,
zunächst erstmal besten Dank insb. an dich (und CoolTux) für die Zeit und Mühen, die in 98_VCLIENT.pm geflossen sind !
Auch ich habe schon seit gut 10 Jahren einen vcontrold laufen zur Auswertung meiner Vitotronic 200 (Viessmann KW-Protokoll). Da bietet sich ja dein Modul für FHEM an, zumal der vcontrold auf einem anderen System läuft ...
Zwei Fragen hätte ich dazu:
a) Da ich parallel zu FHEM den vcontrold regelmäßig stets alle geraden 4 Minuten befrage, kommt der sich mit dem VCLIENT ab und zu ins Gehege bei überschneidenen Abfragen.
Gibt es eine Möglichkeit das Default Intervall z.B. zu ungerade Minuten zu starten oder wie kann man so etwas per "timer" in der Vclient.cfg einstellen. (z.B. alle ungeraden X-Minuten) ?
b) Ab und zu kann der vcontrold keine sinnvollen Daten liefern (z.B. wenn man die Vitotronic 200 zu häufig befragt oder parallel einen Fernthermostat bedient).
Könnte man in solchen Fällen einfach den letzten gültigen Wert im Reading mit dessen Zeitstempel stehen lassen (evtl. als Konfig-Option dafür) ?
Derzeit bekommt man "Unkown buffer format" als Reading-Value, was sich für die grafische Auswertung weniger eignet.
Besten Gruß
Phantom
Zitat von: phantom am 08 Dezember 2018, 14:59:42
a) Da ich parallel zu FHEM den vcontrold regelmäßig stets alle geraden 4 Minuten befrage, kommt der sich mit dem VCLIENT ab und zu ins Gehege bei überschneidenen Abfragen.
Gibt es eine Möglichkeit das Default Intervall z.B. zu ungerade Minuten zu starten oder wie kann man so etwas per "timer" in der Vclient.cfg einstellen. (z.B. alle ungeraden X-Minuten) ?
Hi Phantom, Du meinst, dass von zwei verschiedenen Geräten aus auf vcontrold zugegriffen wird? Du kannst ja den timer=0 setzen, dann wird nur manuell ausgelöst. Allerdings müsste dann FHEM wissen, ob das zweite Gerät gerade zugreift. Oder eben timer=7, dann kommen die sich alle 4*7=48 Minuten in die Quere.
Wieso hast Du denn über zwei Geräte die Zugriffe? Was macht das andere Gerät? Würde denn FHEM nicht genügen?
Zitat von: phantom am 08 Dezember 2018, 14:59:42
b) Ab und zu kann der vcontrold keine sinnvollen Daten liefern (z.B. wenn man die Vitotronic 200 zu häufig befragt oder parallel einen Fernthermostat bedient).
Könnte man in solchen Fällen einfach den letzten gültigen Wert im Reading mit dessen Zeitstempel stehen lassen (evtl. als Konfig-Option dafür) ?
Derzeit bekommt man "Unkown buffer format" als Reading-Value, was sich für die grafische Auswertung weniger eignet.
Im Grunde ja, nur manchmal ist nicht klar, was genau ein Fehler ist. Wenn zB die Kesseltemperatur = 65000° ist, ist das logischerweise ein Fehler. Aber dass =103° auch einer ist, ist nicht so leicht erkennbar. Wenn da Texte drin stehen, könnte man das vermutlich löschen.
Wie wertest Du aus? Ich nehme grafana und dann sieht das so aus wie unten, trotz einer Fehlermeldung in der Nacht.
Hi andies,
zu a) ich habe eine Datenbank-Anwendung, die auch auf den vcontrold zugreift. Das liefert schon seit 10 Jh. und möchte ich aufgrund der Historie der Daten darin so belassen.
Diese Anwendung hat ein festes Abfrageraster zu gerade Minuten (jede 4. / 8. / 12. / ...)
FHEM sollte dazwischen liegen.
Wäre das Intervall im Define dann auf 0 zu setzen und alles mit den Timern in der Vclient.cfg zu regeln?
Wie genau sind diese zu verstehen? Könnte man dort z.B. 3,7,11,12,... für die ungeraden (nicht überschneidenen) Minuten eintragen?
Mir ist die Syntax der Timer (noch) nicht klar.
zu b) wenn ich mit verbose=5 logge sehen die Fehler z.B. so aus:
2018.12.08 15:16:33 5: Vitotronic: Requesting getTempWWist now
2018.12.08 15:16:37 3: Vitotronic: Received 49.1 for Warmwassertemperatur
2018.12.08 15:16:37 5: Vitotronic: Requesting getTempA now
2018.12.08 15:16:42 1: DEBUG>Vitotronic: buf ERR: read timeout
Fehler wait, Abbruch
Fehler beim ausfuehren von getTempA
2018.12.08 15:16:42 3: Vitotronic: Received Vitotronic: Unkown buffer format for Aussentemperatur
2018.12.08 15:16:43 5: Vitotronic: Closing vcontrold connection
Sonstige fehlerhaft zurückgelieferte Wert filtert meinen andere DB-Anwendung auch raus.
Da kommt aber bei mir nur 2 Fehlerzustände vor
Werte über 100°C oder Texte in Zahlenfelden werden durch den Vorgänger ersetzt
Nachtrag zu den filterbaren Fehlerwerten:
- Die Vitotronic gibt bei Abfrage mit dem vcontrold seit vielen Jahren ca. 2-3 mal am Tag Temperaturen über 100°C (bei mir stets 128.10) als unsinnige Werte zurück.
- Das macht sie auch bei Statusabfragen (z.B. ZirkuPumpe), da sind korrekte Stati 1 oder 0 und eben nichts > 100
- Seltener kommt ein Fehler bei den Betriebsstunden, hier verwerfe ich alle Werte die kleiner als der Vorgänger sind.
Wäre es nicht sinnvoll so etwas mal vorzusehen? (falls es einfach zu machen ist)
Gruß Phantom
Zitat von: phantom am 08 Dezember 2018, 15:33:34
Wäre das Intervall im Define dann auf 0 zu setzen und alles mit den Timern in der Vclient.cfg zu regeln?
Nicht mit Timern. Du setzt im define auf 0 und stößt dann die Abfrage durch einen eigenen get-Befehl an, also
get <DeinDeviceName> updateDas muss Du dann zu den Dir genehmen Minuten "manuell" (at?) machen.
Zitat von: phantom am 08 Dezember 2018, 15:33:34
zu b) wenn ich mit verbose=5 logge sehen die Fehler z.B. so aus:
2018.12.08 15:16:33 5: Vitotronic: Requesting getTempWWist now
2018.12.08 15:16:37 3: Vitotronic: Received 49.1 for Warmwassertemperatur
2018.12.08 15:16:37 5: Vitotronic: Requesting getTempA now
2018.12.08 15:16:42 1: DEBUG>Vitotronic: buf ERR: read timeout
Fehler wait, Abbruch
Fehler beim ausfuehren von getTempA
2018.12.08 15:16:42 3: Vitotronic: Received Vitotronic: Unkown buffer format for Aussentemperatur
2018.12.08 15:16:43 5: Vitotronic: Closing vcontrold connection
Also die Wassertemperatur kriegt er, die Außentemperatur aber nicht.
Nenn mir mal hier die vonctrold-Befehle, die Du von FHEM implementiert haben willst. Und sage mir, wie das reading heißen soll, dass dann die Rückgabe speichern soll. Ich zeige dann, wie das geht.
Zitat von: phantom am 08 Dezember 2018, 15:58:39
Wäre es nicht sinnvoll so etwas mal vorzusehen? (falls es einfach zu machen ist)
Also, die Stelle, an die das muss, ist diese hier:
my @zeilen=split /\n/, $buf;
# Anzahl uebergebener Zeilen
my $zeilen = @zeilen;
# hier gibt es zwei Moeglichkeiten: Entweder enthaelt $buf nur eine Zeile,
# dann kommt das Ergebnis gleich am Anfang (danach steht die Masseinheit).
if ($zeilen == 1 ) {
my @results = split /[ ]/, $zeilen[0]; # split around empty_space
# ueblicherweise stehen hier numerische Angaben, ausser zB bei der Betriebsart
if (looks_like_number($results[0])){
$value = sprintf("%.1f", $results[0]); #rounding to, for example, 16.6
} else {
$value = $results[0]; #Buchstaben fuer Betriebsart u.Ae.
}
Ich brauche dann aber eine Logik, nach der aussortiert wird. Man würde dann eine Fehlermeldung erzeugen ("Wert zu groß" oder so) und das dann nachfolgende readingsSingleUpdate($hash, $reading, $value, 1) unterlassen - dann bleibt der alte Wert stehen.
Nur die Logik kapiere ich noch nicht. Das muss ja irgendwie für alle Werte Sinn ergeben.
Als Logik zur Fehlererkennung bietet sich z.B. an alle Temperaturen über 110°C rauszuwerfen. Die haben den Substring ... Temp ... im vcontrol-command.
Ebenso haben die Statuswerte ein ... Status ... im vcontrol-command.
Die ViessmannStati sind binär 0 oder 1 .
Wenn für solch eine Wert dann über 110 zurückkommt könnte dies als Fehler rausfliegen (oder die Heizung ist schon beim explodieren :-\ )
Desweiteren sollte, wenn es Wert mal gar nicht ausgelesen werden nicht "Unkown buffer format" im Zahlen/Statuswert stehen
Es kommen leider ab und an read-timeouts einzelner Werte vor (s. vorheriges Beispiel)
Hilft dies weiter und sieht du dies auch als sinnvoll an?
Phantom
hier noch eine Kleinigkeit, die Abfrage der Viessmann-Zeit/Datum per vclient liefert:
./vclient -h localhost:3002 -c getSystemTime
getSystemTime:
Sa,08.12.2018 17:13:40
in VCLIENT fehlt beim Reading die Uhrzeit:
VitotronicSystemzeitSa,08.12.2018
2018-12-08 17:14:41
zu früh abgesendet...
ich setze z.B. die Viessmann Zeit so:
./vclient -h localhost:3002 -c "unit off,setSystemTime `date "+%C %y %m %d 0%u %H %M %S"`,unit on"`
meine kann keine Sommer/Winterzeitumstellung ...
So wäre es schön, wenn diese auch in FHEM zur Kontrolle mit angezeigt würde.
Der String wird wohl hinter dem Leerzeichen nicht weiter ausgewertet und endet dann mit dem Datum ohne die Zeit dahinter ?
Gruß Phantom
Zitat von: phantom am 08 Dezember 2018, 16:23:41
Hilft dies weiter und sieht du dies auch als sinnvoll an?
Ich habe mal was eingebaut, siehe Anhang. Drei Dinge:
- Das gibt bei mir jetzt keine Fehlermeldung, aber das heißt nichts. Du musst also testen und ich kann nur hoffen, dass es da keine Probleme gibt.
- Du lädst die Datei in FHEM und rufst dann "reload 89_VCLIENT.pm" auf. Das reicht aber nicht.
- Du musst danach den config.file neu einladen, sonst werden die Variablen nicht aktualisiert. Also "set <Device> reload_command_file <Dateiname_mit_pfad>".
Da ist jetzt eine Integritätsprüfung drin. Die sieht momentan so aus:
sub VCLIENT_integrity_check($)
{
my $value = shift;
my $integrity = 1;
#Temperaturen muessen unter 110 Grad Celsius sein
if ($last_cmd =~ /(T|t)emp/)
{
$integrity = ($value < 110);
}
#Status darf nur 0 oder 1 sein
if ($last_cmd =~ /status/)
{
$integrity &&= ($value =~ /(0|1)/);
}
return $integrity;
}
Also wenn irgendwas mit temp im letzten Kommando, muss die Rückgabe < 110 sein. Wenn irgendwas mit status im letzten Kommando, muss die Rückgabe 0 oder 1 sein. Mal sehen, ob das was bringt.
Zitat von: phantom am 08 Dezember 2018, 17:16:23
hier noch eine Kleinigkeit, die Abfrage der Viessmann-Zeit/Datum per vclient liefert:
Ich kann doch nur vcontrold. Gibt es da einen Befehl?
ZitatDieses Modul funktioniert nur, wenn auf einem (externen) Host vcontrold installiert wurde und fehlerfrei läuft.
zur Zeit / Datum Einstellung:
Auf dem System, auf dem der vcontrold läuft, gibt es auch den shell-Befehl names "vclient" mit dem man den vcontrold direkt (oder über Netz) ansprechen kann.
z.B. holt ./vclient -h localhost:3002 -c "getSystemTime" die Viessmann-Uhrzeit+Datum
oder ./vclient -h localhost:3002 -c "commands" liefert alle in der vito.xml definierten Befehle (die sollten zum Heizungsmodell passen !)
mit dem oben erwähnten Befehl setzte ich per cron Sommer- / Winterzeit (dabei muß ein unit off davor und unit on dahinter kommen)
für den VCLIENT wäre es schön, wenn mit Config: "getSystemTime VitotronicSystemzeit daily" die Viessmann-Zeit mitlkäme
derzeit kommt nur "Sa,08.12.2018" , d.h. die Zeit, die auf diesen String folgt wird abgeschnitten.
frag nach, wenn dies unklar ist
Phantom
P.S.: die angehängte neue Version von VCLIENT ist soeben installiert, später mehr dazu
Kannst du mal das ausprobieren? Da müsste jetzt das Datum komplett kommen. Ich hatte den hinteren Part immer entfernt, weil der normalerweise die Maßeinheit enthielt. Ist jetzt drin, wenn der erste Teil keine Zahl ist (und das ist er beim Datum nicht).
<edit> Da ist noch was faul, warte mal.
<edit>repariert.
hier meine Test-Erkenntnisse:
a) das mit der Systemzeit klappt nun
b) wenn vcontrold gar nichts zurückliefern kann kommt als Reading z.B. : "TempSoll_Warmwasser Vitotronic: Unkown buffer format"
und im verbose-5 Log sieht das so aus:
2018.12.08 18:26:02 5: Vitotronic: Requesting getTempWWist now
2018.12.08 18:26:07 1: DEBUG>Vitotronic: buf ERR: read timeout
Fehler wait, Abbruch
Fehler beim ausfuehren von getTempWWist
2018.12.08 18:26:07 3: Vitotronic: Received Vitotronic: Unkown buffer format for Warmwassertemperatur
2018.12.08 18:26:07 1: PERL WARNING: Argument "Vitotronic: Unkown buffer format" isn't numeric in numeric lt (<) at ./FHEM/89_VCLIENT.pm line 321.
dort ist die Ausgabe ja bei verbose>3 auch OK (bis auf den kleinen BUG in line 321 ...)
c) ansonsten wäre es schön, wenn die Statuswerte ohne Nachkommastellen als Integer (0|1) ausgegeben würden, wie viele andere FHEM-Stati auch
d) der Integritycheck auf >110°C sieht OK aus, das wird bestimmt heute och vorkommen, sonst muss ich es simulieren
Phantom
Kannst du mal das hier testen? Der Fehler mit dem buffer dürfte nicht mehr vorkommen, weil das inzwischen als nicht mehr integer abgewiesen wird (früher wurde es in das reading geschrieben).
Beim Status ohne Nachkommastelle tue ich mich schwer, weil ich das hardkodieren müsste. Ich mag so was nicht, weil ich nicht absehen kann, was dann passiert. Kannst Du nicht mit einem userreading das abfangen? Das liest aus dem Status aus und löscht dabei die letzte Nachkommastelle, also (ungetestet)
attr Vitotronic userradings status {sprintf("%d", $wert_aus_vcontrold)}
oder so?
der Test mit den Werten über 110°C kam gerade vor , es läuft
und auch der Unknown buffer format klappt (ist leichter zu provozieren)
das mit den UserReadings probiere ich später mal in Ruhe, lass alles erstmal so wie in der letztwn Version
ich gehe nun Essen :-)
aller Besten Dank für deine schnelle Umsetzung, ich hoffe das können noch andere gebrauchen
Gruß Phantom
Hallo andies,
ich möchte die Betriebs-Stati der Vitotronic setzen können, habe damit jedoch noch folgendes Problem:
in der Vclient.cfg steht:
...
# Betriebs-Parameter
getBetriebSparM1 Betriebsart_SparM1
getBetriebSparM2 Betriebsart_SparM2
setBetriebSparM1 Betriebsart_SparM1 0,1
setBetriebSparM2 Betriebsart_SparM2 0,1
...
Beim Setzen von setBetriebSparM2 1 geht alles klar, aber das Rücksetzen mit setBetriebSparM2 0 schlägt fehl:
im FHEM-Log mit verbose=5:
2018.12.09 16:28:37 1: DEBUG>Vitotronic: buf ERR: Fehler Unit Wandlung:Kein passendes Enum gefunden
Fehler beim ausfuehren von setBetriebSparM2 0,1
Es wird 0,1 anstatt nur der 0 weitergereicht, was dann fehlschlägt !?
Es wird wohl die 0 nicht akzeptiert, mit der 1 (=aktiv) klappt es.
Und dann habe ich folgende kleine Modifikation gemacht, damit die Status- und Betriebsartenwerte so angezeigt werden (0 oder 1), wie sie auch wieder zu setzen sind.
Damit sind alle Integer-Stati und -betriebarten meiner Viessmann Vitotronic abgedeckt, die sich auch setzen lassen.
(Die "Basisbetriebsart", die mit Strings wie "H+WW" ausgegeben wird, läßt sich bei mir mit vcontrold nicht setzen)
326c326
< if ($last_cmd =~ /(S|s)tatus/)
---
> if ($last_cmd =~ /status/)
401,406c401
< if ( $last_cmd =~ /(S|s)tatus/ || $last_cmd =~ /BetriebSpar/ || $last_cmd =~ /BetriebParty/ )
< {
< $value = sprintf("%.0f", $results[0]); #rounding to integer, if status value
< } else {
< $value = sprintf("%.1f", $results[0]); #rounding to, for example, 16.6
< }
---
> $value = sprintf("%.1f", $results[0]); #rounding to, for example, 16.6
Gruß Phantom
Ein noch unklares Phänomen gibt es , wenn man im Modul verbose=5 einstellt. Dann kommt es in unregelmäßigen Abständen zu einem FHEM-Restart !?
in Log sieht das etwas so aus:
...
2018.12.09 17:32:11 3: Vitotronic: Received 0 for Status_Pumpe_Wellness
2018.12.09 17:32:11 5: Vitotronic: Requesting getBetriebPartyM2 now
2018.12.09 17:32:15 3: Vitotronic: Received 0 for Betriebsart_PartyM2
2018.12.09 17:32:15 5: Vitotronic: Requesting getTempWWist now
2018.12.09 17:32:16 0: Server shutdown
2018.12.09 17:32:16 1: Shutdown executed
2018.12.09 17:32:21 1: Including fhem.cfg
...
es passiert stets im Anschluß zur Abfrage von Daten durch VCLIENT.pm ??
Habe dazu keine Ursache finden können; jedoch ist alles OK, wenn verbose z.B. auf 2 steht.
P.S.:
Die Betriebsartenstati für Spar und Party sind zwar "hardcodiert" in meiner kleinen Modifikation, aber mir ging es darum diese genauso Setzen wie Abfragen zu können.
Weitere setzbare Stati habe ich in der vcontrold -> vito.xml nicht gefunden.
Es geht um die Betriebsarten, die man ggf. besser auch als setzbaren String (mit 0 oder 1 oder H+WW oder ABSCHALT o.ä.) bearbeiten könnte.
Gruß Phantom
Zitat von: phantom am 09 Dezember 2018, 16:55:40
Beim Setzen von setBetriebSparM2 1 geht alles klar, aber das Rücksetzen mit setBetriebSparM2 0 schlägt fehl
Kannst Du mal nachschauen, wie die dropdown aussieht? So wie bei mir (sinngemäß)? Oder erscheint da 0,1? Und wenn Du die config mit verbose5 einliest, gibt es da Meldungen?
Zitat von: phantom am 09 Dezember 2018, 16:55:40
Und dann habe ich folgende kleine Modifikation gemacht, damit die Status- und Betriebsartenwerte so angezeigt werden (0 oder 1), wie sie auch wieder zu setzen sind.
OK, damit klappt es ja. Ich würde dann hier alle Änderungen dokumentieren, damit Du Deine Hardkodierung drin lassen kannst - sie aber nicht in der Hauptdatei übernehmen. Da kann ich vielleicht einen Link setzen, so dass jemand das auch händisch machen kann.
Zitat von: phantom am 09 Dezember 2018, 17:17:13
Ein noch unklares Phänomen gibt es , wenn man im Modul verbose=5 einstellt. Dann kommt es in unregelmäßigen Abständen zu einem FHEM-Restart !?
Uups. Das ist ja ätzend. Und ich werde mich die Woche damit nicht beschäftigen können. Also ich setze nur Log3-Befehle, die schreiben in die Logdatei. Das hört sich aber recht bös an.
Also das ist die Stelle hier
if ($last_cmd){
#send signal
Log3 $name, 5, "$name: Requesting ".$last_cmd." now";
$last_cmd .= "\r\n";
#flag because we need to stop sending until next timeout / successful reading, do this BEFORE syswrite
$reading_in_progress = 1;
if ($hash->{CD}){
syswrite($hash->{CD}, $last_cmd);
} else {
Log3 $name, 1, "$name: (ERROR) cannot reach hash, aborting syswrite";
}
#and set timer for timeout
RemoveInternalTimer($hash);
my $this_timeout = gettimeofday()+AttrVal( $name, 'timeout', '1'); #default value is 1 second
InternalTimer(gettimeofday()+$this_timeout, "VCLIENT_Timeout", $hash);
Da wird in den Hash geschrieben (und last_cmd existiert ja, weil es in den Log geschrieben wird) und dann wird ein Timer entfernt und ein neuer gesetzt. Also ich würde jetzt Zeile für Zeile auskommentieren und suchen, wo das genau passiert. Nach dem neuen internal timer wird die sub verlassen.
Aaah. Da ist doch zweimal "gettimeofday" drin, ist das nicht falsch? Aber dann hätte es doch nie funktioniert? Ich bin nicht vor Ort...
- das Setzen von z.B. setBetriebSparM2 auf 0 gibt folgendes im Log aus:
2018.12.10 19:07:05 5: Vitotronic: Requesting setBetriebSparM1 0,1 now
2018.12.10 19:07:05 1: DEBUG>Vitotronic: buf ERR: Fehler Unit Wandlung:Kein passendes Enum gefunden
Fehler beim ausfuehren von setBetriebSparM1 0,1
das "last_set_command"-Reading bleibt dann bei "command in progress" stehen ...
aber das Dropdown sieht gut aus (s. Anlage)
Da es bei Setzen auf 1 ja klappt, liegt es wohl an der 0 Null
- Die ungeplanten shutdown's verschwinden, wenn man die Timingwerte vergrößert, bei mir so:
evtl. liegt es an den recht vielen Werten, die ich abfrage (ca. 30)
Abfrageintervall von 180 auf 300
attr timout von 1 auf 2
attr internal_update_interval von 0.1 auf 0.2
In deinem Codeschnipsel sehe ich keine gravierende Fehlerursache: Es lag wohl am Timing, was wohl zu agressiv war.
dazu ein Mini.Bug im Logging:
167c167
< Log3 $name, 5, "$name: Internal_Update_Interval set to $attrVal";
---
> Log3 $name, 5, "$name: Internal_Update_Interval set to $internal_update_interval";
P.S.: wie bekommt man denn deine Doku, die im Modul schon da ist, in FHEM integriert?
Zitat von: phantom am 10 Dezember 2018, 20:24:25
P.S.: wie bekommt man denn deine Doku, die im Modul schon da ist, in FHEM integriert?
Ein FHEM Update machen dann kommt sie automatisch. Oder auf den FHEM Server
cd /opt/fhem
/usr/bin/perl contrib/commandref_join
ausführen.
Danke. mit contrib/commandref_join.pl klappts mit der Doku :)
und es bringt auch noch ein paar "Optimierungshinweise" :D ...
*** EN FHEM/10_IT.pm: negative tagcount for li, line 1532
*** EN FHEM/99_MyUtils.pm: No a-tag with name="MyUtils"
*** EN FHEM/50_TelegramBot.pm: negative tagcount for code, line 3529
*** EN FHEM/73_UpsPico.pm: negative tagcount for td, line 1189
*** EN FHEM/73_UpsPico.pm: negative tagcount for tr, line 1190
*** EN FHEM/89_VCLIENT.pm: Unbalanced ul (1, last line ok: 896)
*** EN FHEM/98_apptime.pm: negative tagcount for div, line 439
*** DE FHEM/10_IT.pm: negative tagcount for li, line 1819
*** DE FHEM/71_PHILIPS_AUDIO.pm: negative tagcount for li, line 2613
*** DE FHEM/21_SONOSPLAYER.pm: negative tagcount for li, line 2011
*** DE FHEM/21_SONOSPLAYER.pm: negative tagcount for ul, line 2050
*** DE FHEM/73_UpsPico.pm: negative tagcount for td, line 1369
*** DE FHEM/73_UpsPico.pm: negative tagcount for tr, line 1370
*** DE VCLIENT: nonempty line after =begin html ignored
Das mit den timings war in der Tat ein Fehler, da wurde zweimal der Tag addiert. Dazu muss wirklich, wie oben befürchtet, hier was geändert werden
my $this_timeout = gettimeofday()+AttrVal( $name, 'timeout', '1'); #default value is 1 second
InternalTimer(gettimeofday()+$this_timeout, "VCLIENT_Timeout", $hash);
das zweite "gettimeofday()+" muss heraus. Das sollte also das Problem lösen. Bei dem 0,1 stehe ich auf dem Schlauch. Lies doch nochmal den configfile ein und zeige mir bei verbose 5, was dann im Logfile steht.
ich glaube wir sind da an 2 verschiedenen Dingen dran ...
a) Das mit den Timings klappt doch mit meinen o.g. Parametern Im Gegenteil, nehme ich das 2. "gettimeofday()+" raus, wird gar nichts mehr eingelesen:
2018.12.11 18:27:35 5: Vitotronic: vcontrold opened
2018.12.11 18:27:35 5: Vitotronic: Requesting getTempWWist now
2018.12.11 18:27:35 3: Vitotronic: Received 45.4 for TempIst_Warmwasser
2018.12.11 18:27:35 5: Vitotronic: Requesting getTempA now
2018.12.11 18:27:37 5: Timeout: Was not able to receive a signal from homeserver:3002. Deleting command queue.
2018.12.11 18:27:37 5: Vitotronic: Closing vcontrold connection
2018.12.11 18:31:01 5: Vitotronic: execute get command Vitotronic ?
Das habe ich zurückgeändert auf den Ursprung.
b) Das 0,1_problem ist hingegen noch offen.
Im FHEM-Log steht bei Einlesen der Vclient.cfg folgendes:
2018.12.11 18:33:37 5: Vitotronic: opening command file FHEM/Vclient.cfg
2018.12.11 18:33:37 5: Vitotronic: reading command line getTempA Aussentemperatur
2018.12.11 18:33:37 5: Vitotronic: reading command line getTempKist TempIst_Kessel
2018.12.11 18:33:37 5: Vitotronic: reading command line getTempWWist TempIst_Warmwasser
2018.12.11 18:33:37 5: Vitotronic: reading command line getTempVListM2 TempIst_VorlaufM2 manually
2018.12.11 18:33:37 5: Vitotronic: reading command line getTempRListM2 TempIst_RuecklaufM2 manually
2018.12.11 18:33:37 5: Vitotronic: reading command line getBrennerStarts Brennerstarts
2018.12.11 18:33:37 5: Vitotronic: reading command line getBrennerStarts BrennerstartsBisGestern daily
2018.12.11 18:33:37 5: Vitotronic: reading command line getPumpeStatusM1 Status_Pumpe_Haus manually
2018.12.11 18:33:37 5: Vitotronic: reading command line getPumpeStatusM2 Status_Pumpe_Wellness manually
2018.12.11 18:33:37 5: Vitotronic: reading command line getPumpeStatusSp Status_Pumpe_Warmwasser manually
2018.12.11 18:33:37 5: Vitotronic: reading command line getPumpeStatusZirku Status_Pumpe_Zirku manually
2018.12.11 18:33:37 5: Vitotronic: reading command line getTempRaumNorSollM1 TempSoll_Haus daily
2018.12.11 18:33:37 5: Vitotronic: reading command line getTempRaumRedSollM1 TempSoll_Haus_Reduz daily
2018.12.11 18:33:37 5: Vitotronic: reading command line getTempRaumNorSollM2 TempSoll_Wellness daily
2018.12.11 18:33:37 5: Vitotronic: reading command line getTempRaumRedSollM2 TempSoll_Wellness_Reduz daily
2018.12.11 18:33:37 5: Vitotronic: reading command line getTempWWsoll TempSoll_Warmwasser daily
2018.12.11 18:33:37 5: Vitotronic: reading command line setTempRaumNorSollM1 TempSoll_Haus 22,21,20,19,12,8
2018.12.11 18:33:37 5: Vitotronic: reading command line setTempRaumRedSollM1 TempSoll_Haus_Reduz 22,21,20,19,12,8
2018.12.11 18:33:37 5: Vitotronic: reading command line setTempRaumNorSollM2 TempSoll_Welllness 22,21,20,19,12,8
2018.12.11 18:33:37 5: Vitotronic: reading command line setTempRaumRedSollM2 TempSoll_Wellness_Reduz 22,21,20,19,12,8
2018.12.11 18:33:37 5: Vitotronic: reading command line setTempWWsoll TempSoll_Warmwasser 50,60,15
2018.12.11 18:33:37 5: Vitotronic: reading command line getSystemTime Systemzeit_Heizung daily
2018.12.11 18:33:37 5: Vitotronic: reading command line getBetriebArtM1 Betriebsart_Haus daily
2018.12.11 18:33:37 5: Vitotronic: reading command line getBetriebArtM2 Betriebsart_Wellness daily
2018.12.11 18:33:37 5: Vitotronic: reading command line getBetriebSparM1 Betriebsart_SparM1
2018.12.11 18:33:37 5: Vitotronic: reading command line getBetriebSparM2 Betriebsart_SparM2
2018.12.11 18:33:37 5: Vitotronic: reading command line getBetriebPartyM1 Betriebsart_PartyM1 manually
2018.12.11 18:33:37 5: Vitotronic: reading command line getBetriebPartyM2 Betriebsart_PartyM2 manually
2018.12.11 18:33:37 5: Vitotronic: reading command line setBetriebSparM1 Betriebsart_SparM1 0,1
2018.12.11 18:33:37 5: Vitotronic: reading command line setBetriebSparM2 Betriebsart_SparM2 0,1
2018.12.11 18:33:37 5: Vitotronic: reading command line setBetriebPartyM1 Betriebsart_PartyM1 0,1
2018.12.11 18:33:37 5: Vitotronic: reading command line setBetriebPartyM2 Betriebsart_PartyM2 0,1
2018.12.11 18:33:37 5: Vitotronic: reading command line getTimerWWMo Warmwasser_1Montag manually
2018.12.11 18:33:37 5: Vitotronic: reading command line getTimerWWDi Warmwasser_2Dienstag manually
2018.12.11 18:33:37 5: Vitotronic: reading command line getTimerWWMi Warmwasser_3Mittwoch manually
2018.12.11 18:33:37 5: Vitotronic: reading command line getTimerWWDo Warmwasser_4Donnerstag manually
2018.12.11 18:33:37 5: Vitotronic: reading command line getTimerWWFr Warmwasser_5Freitag manually
2018.12.11 18:33:37 5: Vitotronic: reading command line getTimerWWSa Warmwasser_6Samstag manually
2018.12.11 18:33:37 5: Vitotronic: reading command line getTimerWWSo Warmwasser_7Sonntag manually
2018.12.11 18:33:37 5: Vitotronic: reading command line setTimerWWMo WW_1Mo_spaet 07:40-10:10|12:00-12:30|15:30-16:00|19:00-20:30
2018.12.11 18:33:37 5: Vitotronic: reading command line setTimerWWDi WW_2Di_spaet 08:00-10:00|12:00-12:30|15:30-16:00|19:00-20:30
2018.12.11 18:33:37 5: Vitotronic: reading command line setTimerWWMi WW_3Mi_spaet 06:10-10:00|12:00-12:30|15:30-16:00|19:00-20:30
2018.12.11 18:33:37 5: Vitotronic: reading command line setTimerWWDo WW_4Do_spaet 08:00-10:00|12:00-12:30|15:30-16:00|19:00-20:30
2018.12.11 18:33:37 5: Vitotronic: reading command line setTimerWWFr WW_5Fr_spaet 08:10-10:00|12:00-12:30|15:30-16:00|19:00-20:40
2018.12.11 18:33:37 5: Vitotronic: reading command line setTimerWWSa WW_6Sa_spaet 08:00-11:00|14:00-15:00|17:00-20:30|
2018.12.11 18:33:37 5: Vitotronic: reading command line setTimerWWSo WW_7So_spaet 08:00-13:10|16:00-17:00|18:50-20:30|
2018.12.11 18:33:37 5: Vitotronic: command file 'FHEM/Vclient.cfg' closed (211 lines read)
Dort werden die Zeilen mit z.B. Betriebsart_SparM2 0,1 korrekt eingelesen lt. Log. (es sind TAB's zur Übersicht in der VClient.cfg, OK?).
Und die Dropdown-Auswahl sieht auch OK aus.
Beim Setzen von 0 wird lt. Log statt 0 ein 0,1 abgesetzt:
2018.12.11 18:41:47 5: Vitotronic: Requesting setBetriebSparM1 0,1 now
2018.12.11 18:41:47 1: DEBUG>Vitotronic: buf ERR: Fehler Unit Wandlung:Kein passendes Enum gefunden
Fehler beim ausfuehren von setBetriebSparM1 0,1
2018.12.11 18:41:47 3: Vitotronic: Received Vitotronic: Unkown buffer format for last_set_command
2018.12.11 18:41:47 5: Vitotronic: Closing vcontrold connection
Beim Setzen von 1 klappt es ja:
2018.12.11 18:43:07 5: Vitotronic: vcontrold opened
2018.12.11 18:43:07 5: Vitotronic: Requesting setBetriebSparM2 1 now
2018.12.11 18:43:09 3: Vitotronic: Received OK for last_set_command
2018.12.11 18:43:09 5: Vitotronic: Closing vcontrold connection
Es liegt an der 0 , denn wenn man zum testen mal setBetriebSparM2 Betriebsart_SparM2 2,1 ins config schreibt,
wird die 2 auch korrekt genommen (nur 'halt nicht vom vcontrold akzeptiert):
2018.12.11 18:45:13 5: Vitotronic: Requesting setBetriebSparM2 2 now
2018.12.11 18:45:13 1: DEBUG>Vitotronic: buf ERR: Fehler Unit Wandlung:Kein passendes Enum gefunden
Fehler beim ausfuehren von setBetriebSparM2 2
2018.12.11 18:45:13 3: Vitotronic: Received Vitotronic: Unkown buffer format for last_set_command
Wenn man in der config 1,0 umgekerht schreibt (setBetriebSparM2 Betriebsart_SparM2 1,0) springt das Dropdown sofort von 1 auf 0 um, obwohl 1 vorne steht.
Und leider klappt das Auswählen der 0 dann auch nicht:
2018.12.11 18:49:35 5: Vitotronic: vcontrold opened
2018.12.11 18:49:35 5: Vitotronic: Requesting setBetriebSparM2 1,0 now
2018.12.11 18:49:35 1: DEBUG>Vitotronic: buf ERR: Fehler Unit Wandlung:Kein passendes Enum gefunden
Fehler beim ausfuehren von setBetriebSparM2 1,0
2018.12.11 18:49:35 3: Vitotronic: Received Vitotronic: Unkown buffer format for last_set_command
2018.12.11 18:49:36 5: Vitotronic: Closing vcontrold connection
Ich hoffe diese Tests helfen, da ich das 0,1 Problem im Code auch nicht erkennen kann. Muß heute leider weg.
Gruß Phantom
Ja, das sind zwei verschiedene Dinge.
Zum ersten, mit dem timeout. Bisher steht da
my $this_timeout = gettimeofday()+AttrVal( $name, 'timeout', '1'); #default value is 1 second
InternalTimer(gettimeofday()+$this_timeout, "VCLIENT_Timeout", $hash);
und so, wie das steht, würde man einen Zeitpunkt $this_timeout definieren, der von diesem Moment an genau so lange weg ist wie der Wert (in Sekunden), der im Attribut timeout steht. Gibt es das nicht, nimmt er eine Sekunde.
In der nächsten Zeile aber werden dann zu diesem Zeitpunkt nochmal so viel Sekunden hinzugezählt, wie seit 1.1.70 vergangen sind - das kann nicht sein und das würde in meinen Augen die Abstürze erklären. (Danach wird der Timer gesetzt und VCLIENT dann nach $this_timeout aufgerufen.)
Zum zweiten Problem, da denke ich laut: Intern läuft das so, dass die Befehle beim Einlesen der config-Datei in ein array (hash) geschrieben werden. Insgesamt sind das zwei hash:
my %set_hash; #set commands with values that should appear in FHEM-dropdown
my %dropdown_hash; #contains the values for every set command
Wenn die falsch eingelesen werden, war's das - das wird dann falsch ausgeführt. Eingelesen wird in der sub VCLIENT_Read_Config($). Die set-Kommandos werden ab dieser Zeile erkannt
} elsif (substr($vcontrold_command, 0, 3) eq "set") {
Die 0,1 stehen nun in
my $options = $cfgarray[2];
Da das kein timer ist, bleibt my $msg in der nächsten Zeile leer. Und damit wird
$set_hash{$FHEM_set_command} = [$vcontrold_command, $options] ;
abgearbeitet. Also die Optionen werden neben dem Kommando $vcontrold_command als Optionen in den Hash geschrieben. Ich kapier's nicht.
Ändert sich etwas, wenn Du statt 0,1 einfach mal 1,0 schreibst?
hast du timeout verändert? das waren bei dir nämlich nur zwei sekunden.
Gesendet von iPad mit Tapatalk Pro
Das sind jetzt alles so Gedanken vor dem Einschlafen. Vielleicht nimmt er 0,1 als boolsche Variable und nicht als String an. Das könnte man auffangen, indem man daraus eindeutig einen String macht. Vielleicht so
my $options = $cfgarray[2]." ";
Wenn das keine Nebenwirkungen hat...
Hi andies,
zum 0,1 Problem steht in meinem letzen Posting, was passiert wenn man 1,0 in die Vclient.cfg schreibt und (testhalber) auch mal 2,1.
Es klappt bei allen Zahlen, außer bei der Null 0. (siehe Fehler beim ausfuehren von setBetriebSparM2 1,0 in obigen Beispiel)
Nur der 0-Wert führt dazu, daß der ganze String (1,0 oder 0,1) verarbeitet wird und nicht nur der gewünschte Teil.
Logs dazu s.o.
die Timing-Unklarheit muß ich heute Abend noch mal in Ruhe testen und ja, ich habe folgende Timings eingestellt mit denen es läuft:
Abfrageintervall in der Modul DEF: 300
attr timeout : 2
attr internal_update_interval : 0.2
OK, dann ändere mal in Zeile 547
my $options = $cfgarray[2]." ";
und schaue mal, ob das dann geht. Wegen des Timers: Mach mal timout 5, nicht zwei. Ist das Problem dann noch da?
So, der 0,1-Bug ist gefunden :D .
Ich habe die Abfrage in Zeile 635 von if (!$arg) auf if ( ($arg eq "0") && ($arg != 0) ) geändert, damit auch die Null als Zahl und nicht als Text wie bei Timern behandelt wird. Damit klappt das Setzen der binären Stati.
Dein Einwand mit dem doppelten gettimeofday() ist korrekt. Das zweite muss raus.
mit etwas verlängerten Timings läuft es stabiler und nun ohne shutdown's :D
attr timeout : 2
attr internal_update_interval : 0.2
dies scheint jedoch nur nötig, wenn auch andere den vcontrold ebenfalls mit vielen Werten abfragen
Dann habe ich noch minimale Anpassungen gemacht:
- bei reload_command_file ohne Filename, den Default $filename aus DEF nehmen. (Zeile 610-613)
- und die hardcodierte Änderung für die Betriebsarten u. Stati ist durch eine Abfrage auf Temperaturwerte ersetzt
damit werden Temperaturen auf eine Nachkommastelle und sonstige Stati ohne Nachkommastelle ausgegeben
das sollte besser sein, wie beim Integritätscheck der Temperaturen (s. Zeile 401-408)
- flexbilerer Status-Check in Zeile 326
Alle genannten Zeilennummern beziehen sich auf die modifizierte, angehängte Version.
Darin sind die o.g. Fehlerbehebungen und kl. Anpassungen schon drin. (vergleichs mal mit deiner letzten Version)
Gruß Phantom
Super, danke - jetzt machst Du meine Arbeit...
Übernehme ich alles und werde das in dem ersten Post anpinnen.
Hi Andi,
alles gut, dafür ist die Community da ;-)
Ich habe das Modul VCLIENT.pm nun seit einigen Tage problemlos in Betrieb. Wenn man recht viele Werte (z.B. alle Stati und Timer) aus abrufen will, klappt es zuverlässiger, wenn man der Viessmann-Steuerung "etwas Zeit gibt". (s. vorheriges Posting).
Evtl. könntest du das Modul auch ins allgemeine Repository einchecken. Dann finden es andere interessierte leichter ;)
Gruß Phantom
Zitat von: phantom am 17 Dezember 2018, 18:58:39
Evtl. könntest du das Modul auch ins allgemeine Repository einchecken. Dann finden es andere interessierte leichter ;)
Gruß Phantom
An wen muss ich mich wenden? und was müsste da noch getan werden?
Das Modul benötigt auf jeden Fall eine Commandref sofern noch nicht vorhanden. Du musst Schreibrechte für das SVN beantragen
https://svn.fhem.de/
Und Du suchst Dir einen erfahrenden Developer der sich Dein Modul einmal an schaut.
So, ich habe das Modul jetzt im offiziellen FHEM-Bereich. Daher schließe ich diesen Thread. Fehlermeldungen etc bitte hier:
https://forum.fhem.de/index.php/topic,94809.msg875808.html#msg875808
PS Phantom, du musst aufpassen. Ich habe vermutlich eine Deiner Änderungen nicht übernommen und daher musst Du VCLIENT beim update ausschließen, sonst wird das überschrieben:
attr global exclude_from_update 89_VCLIENT.pm
Zitat von: CoolTux am 18 Oktober 2017, 21:11:52
So kann man es machen.
CoolTux, ich brauche mal Deinen Rat. Das Modul läuft ja nun schon eine ganze Weile und ist auch ok, aber ab und an gibt es bei mir Timeouts, die dann dazu führen, dass das gesamte FHEM "steht". Nun habe ich einen Programmierfehler bei mir bemerkt und dachte: "Kein Wunder, aber jetzt läuft es" und das ist aber nicht der Fall. Vielleicht hast Du eine Idee, wo ich suchen kann?
Also, zum Programmablauf. Das Modul erhält zB den Befehl die readings zu aktualisieren. Dann wird der Prozess angestoßen und die von vcontrold durchzuführenden Befehle werden in einer command_queue notiert. Das aufbauen dieses hash geht sofort und nicht-blockierend. Danach gibt es einen hash mit Befehlen, die auszuführen sind.
Dann wird jeder Befehl einzeln an vcontrold geschickt, nur einmal und es wird gewartet, bis eine Rückmeldung läuft. Konkret, es wird gesetzt
sub VCLIENT_Set_New_Write_Interval($)
{
my ($hash) = @_;
my $name = $hash->{NAME} ;
#remove old timout
RemoveInternalTimer($hash);
#set up timer for writing next signal (fixed at $internal_update_interval seconds after opening connection)
my $my_internal_timer = AttrVal( $name, 'internal_update_interval', $internal_update_interval);
InternalTimer(gettimeofday()+ $my_internal_timer, "VCLIENT_Write", $hash);
}
und dann wird ein Flag notiert "reading_in_progress". Ist der 1, passiert nichts. Ist der 0, wird gesendet:
sub VCLIENT_Write($)
{
my ($hash) = @_;
my $name = $hash->{NAME}; #Name des devices
my $msg = "OK"; # Variable, um Rückgabe des Schreibvorgangs auszuwerten
#Ist es moeglich, die Verbindung zu oeffnen?
if (!$hash->{CD}){
$msg = VCLIENT_Open_Connection($hash); #gibt Error im Fehlerfall zurueck und bricht intern ab, sonst OK
}
if ($msg eq "OK"){
#wenn ein Befehl abgesendet wurde und noch keine Rueckgabe erfolgte, write nicht ausfuehren, sondern verzoegern (=erneut aufrufen)
if ($reading_in_progress){
VCLIENT_Set_New_Write_Interval($hash); # siehe oben, da wird einfach der time geloescht und ein neuer definiert; mehr nicht
return;
}
#jetzt wird das Kommando eingelesen, das gesendet werden soll
$last_cmd = shift @command_queue; #global variable, if this command was not recognized by vcontrold there must be an error message in VCLIENT_Read
if ($last_cmd){ # wenn es noch ein Kommando gibt, loslegen!
#send signal
Log3 $name, 5, "$name: Requesting ".$last_cmd." now";
$last_cmd .= "\r\n"; #Zeilenende hinzufuegen
#flag because we need to stop sending until next timeout / successful reading, do this BEFORE syswrite
$reading_in_progress = 1; #flag setzen
syswrite($hash->{CD}, $last_cmd); #der eigentliche sendebefehl
#and set timer for timeout
RemoveInternalTimer($hash); #alten timeout loeschen
my $this_timeout = AttrVal( $name, 'timeout', 5); #neuen timeout setzen, falls gar keine Rueckmeldung erfolgt, default value is 5 second
InternalTimer(gettimeofday()+$this_timeout, "VCLIENT_Timeout", $hash);
} else {
#last command already executed, set now timer for closing
RemoveInternalTimer($hash); #das naechste update-Intervall setzen
my $my_internal_timer = AttrVal( $name, 'internal_update_interval', $internal_update_interval);
InternalTimer(gettimeofday()+ $my_internal_timer, "VCLIENT_Close_Connection", $hash);
}
}
}
Es kommt nun vor, dass anscheinend die Verbindung zusammenbricht, wie der folgende Log zeigt:
2019.05.22 18:13:32 5: Viessmann: will now update readings
2019.05.22 18:13:36 5: Viessmann: Opening vcontrold connection to 192.168.2.105:3002
2019.05.22 18:13:36 5: Viessmann: vcontrold opened
2019.05.22 18:13:36 5: Viessmann: Requesting getBrennerStunden1 now
2019.05.22 18:13:47 3: Viessmann: Received 20472 for Stunden
2019.05.22 18:14:00 5: Viessmann: Requesting getTempKist now
2019.05.22 18:14:14 3: Viessmann: Received 53.3 for Kesseltemperatur
2019.05.22 18:14:34 5: Viessmann: Requesting getTempAbgas now
2019.05.22 18:14:39 3: Viessmann: Received 60.5 for Abgastemperatur
2019.05.22 18:14:49 5: Viessmann: Requesting getTempA now
2019.05.22 18:15:00 3: Viessmann: Received 13.6 for Aussentemperatur
2019.05.22 18:15:15 5: Viessmann: Requesting getBrennerStarts now
2019.05.22 18:15:29 3: Viessmann: Received 191232 for Starts
2019.05.22 18:15:46 5: Viessmann: Requesting getTempWWist now
2019.05.22 18:16:00 3: Viessmann: Received 58.7 for Warmwassertemperatur
2019.05.22 18:16:26 5: Viessmann: Closing vcontrold connection
2019.05.22 18:26:31 5: Viessmann: will now update readings
2019.05.22 18:26:34 5: Viessmann: Opening vcontrold connection to 192.168.2.105:3002
2019.05.22 18:26:34 5: Viessmann: vcontrold opened
2019.05.22 18:26:34 5: Viessmann: Requesting getBrennerStunden1 now
2019.05.22 18:26:46 3: Viessmann: Received 20472 for Stunden
2019.05.22 18:27:00 5: Viessmann: Requesting getTempKist now
2019.05.22 18:27:16 3: Viessmann: Received 50.5 for Kesseltemperatur
2019.05.22 18:27:23 5: Viessmann: Requesting getTempAbgas now
2019.05.22 18:27:34 1: Viessmann timeout: Was not able to receive a signal from 192.168.2.105:3002. Deleting command queue. <=== HIER
2019.05.22 18:27:34 5: Viessmann: Closing vcontrold connectionIch verstehe nun nicht, warum an der Stelle FHEM oder genauer perl auf 100% CPU hochläuft. Da blockiert doch nichts?! syswrite ist durch und die Schleife wartet nur, ob irgendwann etwas zum lesen hineinkommt. Wenn nichts hineinkommt, sollte das normale FHEM weiterlaufen und gut ist. Das ist aber nicht der Fall?!
Read sieht so aus:
sub VCLIENT_Read($){
my ($hash) = @_;
my $name = $hash->{NAME};
my $buf;
my $line = sysread($hash->{CD}, $buf, 1024);
if ( !defined($line) || !$line){
$reading_in_progress = 0; #enforce finish reading
Log3 $name, 5, "$name: connection closed unexpectedly"; #kann hier eigentlich nicht passieren
VCLIENT_Close_Connection($hash);
return;
}
unless (defined $buf){
Log3 $name, 5, "$name: no data received"; #continue reading
return;
}
## debug #######################
##Log3 $name, 1, $name." raw \$buf = ".$buf;
#remove prompt and trailing empty lines, auch https://forum.fhem.de/index.php?topic=100698
$buf =~ s/\r//g;
$buf =~ s/vctrld>//g;
$buf =~ s/\n$//;
if ($buf ne "") {
#erst hier kommen echte Daten an, die ins Reading geschrieben werden sollen - nur diese parsen
VCLIENT_ParseBuf_And_WriteReading($hash, $buf);
}
$reading_in_progress = 0; #reading successfully finished
}
und Timeout sieht so aus:
sub VCLIENT_Timeout($)
{
my ($hash) = @_;
my $name = $hash->{NAME};
my $host = $hash->{IP};
my $port = $hash->{PORT};
my $interval = $hash->{INTERVAL};
my $telnet = $hash->{CD};
Log3 $name, 1, $name." timeout: Was not able to receive a signal from $host:$port. Deleting command queue.";
@command_queue = ();
@reading_queue = ();
$reading_in_progress = 0;
if ($telnet){ #wenn Verbindung existent
if ($telnet->open($host)){ # und offen
VCLIENT_Close_Connection($hash);
}
}
readingsSingleUpdate($hash, "state", "timeout", 1);
#set new update interval
VCLIENT_Set_New_Update_Interval($hash);
}Also, lange Rede, kurze Frage: Hast Du eine Idee, wieso bei nichterreichen des fremden Hosts die CPU-Last auf 100% geht und FHEM faktisch blockiert ist?
PS Das Modul ist ja im svn eingecheckt...
sysread blockiert, wenn keine Daten kommen, soweit ich weiß.
use IO::Select;
my $select = IO::Select->new($hash->{CD});
if ($select->can_read(0.1))
{
sysread($hash->{CD}, $ret, 1024);
...
}
Hier mal exemplarisch wie man das umgehen könnte, wenn das die Ursache ist.
Aaah, das kann es sein. Danke! Schaue ich mir mal genauer an. Das passt.
Da die ReadFn nur aufgerufen wird wenn Daten zur Verfügung stehen sollte das mit sysread eigentlich unerheblich sein
Ich schaue nachher mal drüber.
Ich kann nicht wirklich was finden.
2 Möglichhkeiten
1. mumpitzstuff seine Variante funktioniert, dann lag es am sysread. Teste das bitte einmal. Ich tippe allerdings darauf das es das nicht ist.
2. Das syswrite hat Probleme seine Daten los zu werden. Daher springt Dein Timeout auch an. Würde ja Sinn machen wenn vcontrold die Verbindung kappt und FHEM das nicht mit bekommt.
Zitat von: CoolTux am 23 Mai 2019, 08:21:51
Das syswrite hat Probleme seine Daten los zu werden.
Das kann ich ja testen mit
ZitatThis function returns undef on error and Integer, number of bytes written on success.
Aber blockiert syswrite? Oder gibt es eine Möglichkeit analog oben, wo ich einen möglichen Schreibfehler abfangen kann?
Bin mir nicht sicher aber ich würde sagen das syswrite blockiert wenn der Socket nicht offen ist.
Bin mir gerade unsicher, aber du testest ja schon ob der Socket da ist, zu mindest mittels $hash->{CD}
Zitat von: CoolTux am 23 Mai 2019, 18:23:29
Bin mir nicht sicher aber ich würde sagen das syswrite blockiert wenn der Socket nicht offen ist.
Also, ich habe das mal über Nacht laufen lassen. Syswrite ist es anscheinend nicht. Hier der Code
Log3 $name, 1, "DEBUG will syswrite ".$last_cmd;
my $bytes_written=syswrite($hash->{CD}, $last_cmd);
Log3 $name, 1, "DEBUG syswrite bytes written ".$bytes_written;
und dazu der Logfile, wobei ich die Zeilenvorschübe nach dem Befehl entfernt und dafür andere Zeilenvorschübe der Übersichtlichkeit eingefügt habe. Man sieht, dass die abgeschickten Zeichen sofort gesendet werden:
2019.05.24 04:06:23 1: DEBUG will syswrite getBrennerStunden1
2019.05.24 04:06:23 1: DEBUG syswrite bytes written 20
2019.05.24 04:17:08 1: DEBUG will syswrite getTempWWist
2019.05.24 04:17:08 1: DEBUG syswrite bytes written 14
2019.05.24 04:17:31 1: DEBUG will syswrite getTempA
2019.05.24 04:17:31 1: DEBUG syswrite bytes written 10
2019.05.24 04:17:58 1: DEBUG will syswrite getBrennerStarts
2019.05.24 04:17:58 1: DEBUG syswrite bytes written 18
2019.05.24 04:18:18 1: Viessmann timeout: Was not able to receive a signal from 192.168.2.105:3002. Deleting command queue.
2019.05.24 04:28:51 1: DEBUG will syswrite getTempWWist
2019.05.24 04:28:51 1: DEBUG syswrite bytes written 14
2019.05.24 04:29:03 1: DEBUG will syswrite getTempA
2019.05.24 04:29:03 1: DEBUG syswrite bytes written 10
2019.05.24 04:29:14 1: DEBUG will syswrite getBrennerStarts
2019.05.24 04:29:14 1: DEBUG syswrite bytes written 18
Dann bleibt doch erstmal nur noch die Vermutung von mumpitzstuff? Die werde ich jetzt mal umsetzen.
Zitat von: mumpitzstuff am 23 Mai 2019, 03:07:48
sysread blockiert, wenn keine Daten kommen, soweit ich weiß.
Bist Du Dir sicher, dass fehlende Daten mein Problem sind? Ich habe ein wenig gelesen und mir nochmal meine empfangenen Daten angeschaut (ich kenne mich mit IO::Select nicht aus), und ich vermute, dass (nur) das Zeilenende \n nicht empfangen wird und Perl\FHEM dann darauf wartet und blockiert. Das würde jedenfalls zu meinen Fehlerbildern passen.
Wenn das das Problem sein sollte, muss ich aber anders vorgehen als in Deinem Code: Ich müsste lesen, was zu lesen ist und dann, wenn kein \n kommt, beenden.
Hast Du einen Link, wo ich dazu was finde? Die Perl-Doc ist etwas zu rudimentär für mich.
https://www.perlmonks.org/bare/?node_id=451914 (http://https://www.perlmonks.org/bare/?node_id=451914)
https://docstore.mik.ua/orelly/perl4/cook/ch07_21.htm (http://https://docstore.mik.ua/orelly/perl4/cook/ch07_21.htm)
Es gibt auch noch andere Wege das zu umgehen, falls das wirklich die Ursache für dein Problem ist. Und blockieren tut es nur, wenn absolut gar keine Daten gelesen werden können. Sobald irgendein Zeichen gelesen werden kann, kommt die Funktion umgehend zurück.
ich habe die Leseroutine jetzt so umgeschrieben, mal sehen, was passiert:
sub VCLIENT_Read($){
my ($hash) = @_;
my $buf = '';
my $select = IO::Select->new($hash->{CD}); # see forum, blocking call with empty sysread
if ($select->can_read(0.1)) #timeout 0.1 Sekunden
{
sysread($hash->{CD}, $buf, 1024);
}
if (!$buf){
VCLIENT_Close_Connection($hash);
return;
}
#remove prompt and trailing empty lines
$buf =~ s/\r//g;
$buf =~ s/vctrld>//g;
$buf =~ s/\n$//;
if ($buf ne "") {
VCLIENT_ParseBuf_And_WriteReading($hash, $buf);
}
}
Also, das hat jetzt geklappt. Ich hatte nachts wieder eine Fehlermeldung der Form
2019.05.25 00:00:33 1: [YAAHM_updater] <was auch immer>
2019.05.25 02:11:19 1: Viessmann timeout: Was not able to receive a signal from 192.168.2.105:3002. Deleting command queue.
2019.05.25 04:58:03 1: IPCAM <was auch immer>
und diesmal ging die CPU nicht auf 100% hoch. Vielen Dank, mumpitzstuff, Problem eigentlich gelöst. Aber ich kapiere dennoch etwas nicht. Der Code sieht bei mir nämlich so aus:
if ($select->can_read(0.1)) #timeout 0.1 Sekunden, FHEM blockiert sonst!
{
sysread($hash->{CD}, $buf, 1024);
}
if (!$buf){
Log3 $name, 1, "$name: connection closed unexpectedly"; #kann hier eigentlich nicht passieren
VCLIENT_Close_Connection($hash);
return;
}
und wenn $buf leer gewesen wäre (weil nicht von sysread gefüllt und vorher gerade erst definiert), hätte ich doch einen weiteren Eintrag im Logfile haben müssen?!
Mir ist noch etwas aufgefallen. Ich lese mir das ja alles an und habe viel Copy-and-paste gemacht. Bis vor wenige Tagen stand unter dem Code noch folgende Zeile:
sysread($hash->{CD}, $buf, 1024);
...
unless (defined $buf){
Log3 $name, 5, "$name: no data received"; #continue reading
return;
}
Das habe ich auch gelöscht. Könnte das für die Blockade verantwortlich gewesen sein? Allerdings habe ich diese Zeile nie in meinem Logfile gefunden. (Irgendwie ist das rätselhaft.)
my $buf = '';
Dein $buf ist ja nicht leer. Weil '' nunmal auch ein Zeichen ist.
Teste mal mit einem my $buf;.
Was ich aber nicht verstehe ist das ja eigentlich die Read Funktion nur aufgerufen werden sollte wenn Daten am Socket zum lesen anliegen.
Grüße
Zu früh gefreut:
load average: 0,87, 0,94, 0,91
Also das Problem ist noch da. Allerdings sehe ich diesmal weder ein timeout noch ein telnet-Zugriffsproblem. Kann es sein, dass das am Ende was völlig anderes ist?
Es gab doch mal Meldungen darüber, dass FHEM blockiert und keiner wusste, woran es lag.
Ich denke eher Du meinst den stetigen Speicheranstieg. Oder?
Ja, genau den. Stimmt, das ist nicht 100% CPU...
nachdem ich nachts eine Ausfall und dennoch keine 100%-cpu hatte, betrachte ich den fall als gelöst und lade die neue Version dann mal hoch.
Gesendet von iPad mit Tapatalk Pro
Wie sieht Deine Lösung nun aus? Das was Du oben geschrieben hast oder mit Zusatz?
Genau wie oben geschrieben. Ich hatte noch X-Zeilem mit debug eingefügt und mir alles mögliche ausgeben lassen, dort aber nichts festgestellt. Senden funktioniert sofort; ich konnte nicht wirklich sehen, wieso sysread einen Fehler erzeugt. Entweder war vorher im Code was falsch oder eine Geisterhand ist im Spiel, jedenfalls geht es jetzt.
Moin, wie im anderen VCONTROL300 Thread schon angemerkt, nutze ich jetzt auch VClient. Und ich muss sagen, ich verstehe nicht, warum so viele VCONTROL(300) nutzen und (laut diesem Thread) kaum jemand VClient.
Chapeau, andies. Danke für dieses Modul. Es macht zwar auch nicht "mehr" als VCONTROL, aber dafür läuft es halt wenigstens stabil. Bei Vcontrol hatte ich immer meine Probleme und mal bekam ich bei manchen IDs was zurück und mal nicht.
Ich freue mich auf diesen Winter und vermutlich ein mehr an Erkenntnissen über meine Heizung.
Ich habe beim virtuellen Stammtisch mal berichtet, wie ich damit einen sehr einfachen hydraulischen Abgleich gemacht habe: https://youtu.be/kLzmfkQ1u28 (https://youtu.be/kLzmfkQ1u28)
Nabend,
mir brennen schon die Augen von allem was vor Vclient passiert ist (raspi einrichten, vcontrold einrichten,...,)
1000 Schrauben gedreht bis endlich Werte ausgespuckt wurden. An der Config von vcontrold muss ich vielleicht
auch nochmal ran. Habe passende oder halbwegs passende XML's gefunden. Danach habe ich nun die Vclient.cfg angelegt.
########################################################
#
# This file is used by the modul 89_VCLIENT.pm in FHEM
#
########################################################
## Command file for vcontrold and VCLIENT-modul in FHEM. Use the following syntax:
## vcontrold-comand FHEM-reading [daily|timer]
##
## For example the line
#
#getTempA TemperaturAuslauf
#
## will map the result of the vcontrold-Command getTempA
## to the reading TemperaturAuslauf in the VCLIENT-device.
##
## If you are dealing with timers add the word timer at the end.
## If you want to run the command only once a day add the word daily at the end.
##
########################################################
getTempA: Ermittle die Aussentemeratur in Grad C
getTempWWist: Ermittle die Warmwassertemperatur in Grad C
getTempWWsoll: Ermittle die Warmwassersolltemperatur in Grad C
setTempWWsoll: Setze die Warmwassersolltemperatur in Grad C
getTempKist: Ermittle die Kesseltemperatur in Grad C
getTempKsoll: Ermittle die Kesselsolltemperatur in Grad C
getTempVListM2: Ermittle die Vorlauftemperatur M2 in Grad C
getTempVLsollM1: Ermittle die Vorlaufsolltemperatur M1 in Grad C
getTempVLsollM2: Ermittle die Vorlaufsolltemperatur M2 in Grad C
getTempRaumNorSollM1: Ermittle die Raumsolltemperatur normal M1 in Grad C
setTempRaumNorSollM1: Setze die Raumsolltemperatur normal M1 in Grad C
getTempRaumRedSollM1: Ermittle die Raumsolltemperatur reduziert M1 in Grad C
setTempRaumRedSollM1: Setze die Raumsolltemperatur reduziert M1 in Grad C
getBrennerStatus: Ermittle den Brennerstatus
getBrennerStunden1: Ermittle die Brennerstunden Stufe 1
getPumpeStatusM1: Ermittle den Status der Pumpe M1
getPumpeStatusZirku: Ermittle den Status der Zirkulationspumpe
getBetriebArtM1: Betriebsart M1
setBetriebArtM1: Setze Betriebsart M1
getError0: Ermittle Fehlerhistory Eintrag 1
getNeigungM1: Ermittle Neigung Heizkennlinie M1
setNeigungM1: Setze Neigung Heizkennlinie M1
getNeigungM2: Ermittle Neigung Heizkennlinie M2
setNeigungM2: Setze Neigung Heizkennlinie M2
getNiveauM1: Ermittle Niveau Heizkennlinie M1
setNiveauM1: Setze Niveau Heizkennlinie M1
getNiveauM2: Ermittle Niveau Heizkennlinie M2
setNiveauM2: Setze Niveau Heizkennlinie M2
getDevType: Ermittle Device Typ der Anlage
init: Inintialisierung
get: Testabfrage, Adresse eingeben
vget: Testabfrage, Virtuelle Adresse eingeben
bget: Testabfrage, Bedienteil Adresse eingeben
pget: Testabfrage, Port Adresse eingeben
eget: Testabfrage, EEProm Adresse eingeben
xget: Testabfrage, XRAM Adresse eingeben
kmget: Testabfrage, KM-Bus EEProm Adresse eingeben
getExtBA: Ermittle Zustand der externen Betriebsartenumschaltung
getPumpeSollM1: Ermittle Solldrehzahl Pumpe M1
getVentilStatus: Ermittle Zustand Umschaltventil WW/Heizen
getHKPTyp: Ermittle Typ der Heizkreispumpe
getTempRueck: Ermittle die Ruecklauftemepratur
getTempRaumAktSoll: Ermittlen der aktuell verwendeten Raumsolltemperatur
setTempRaumAktSoll: Setzen der aktuell verwendeten Raumssolltemperatur
getPartyStatus: Ermittle Zustand Partybetrieb
getSparStatus: Ermittle Zustand Sparbetrieb
getFerienStatus: Ermittle Zustand Ferienbetrieb
getPSFByte: Ermittle Party, Spar und Ferien Statusbyte
setPSFByte: Setze Party, Spar und Ferien Statusbyte
########################################################
#getTempA Aussentemperatur
#getTempWWist Warmwassertemperatur
#getTempKist Kesseltemperatur
#getBrennerStarts Brennerstarts
#getBrennerStarts BrennerstartsBisGestern daily
#getTempRaumNorSollM1 RaumsollHaus daily
#getTempRaumRedSollM1 RaumsollHausReduz daily
#getTempRaumNorSollM2 RaumsollWohnz daily
#getTempRaumRedSollM2 RaumsollWohnzReduz daily
#getTempWWsoll WarmwasserSoll daily
#getBetriebArtM1 BetriebHaus daily
#getBetriebArtM2 BetriebWohnz daily
##Die Zahlen bei den readings sorgen fuer eine sinnvolle Anordnung der timer
#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
#setTempRaumNorSollM1 Tempsoll_Haus 22,21,20,19,12,8
#setTempRaumRedSollM1 Tempsoll_Haus_Reduz 22,21,20,19,12,8
#setTempRaumNorSollM2 Tempsoll_Wohnz 22,21,20,19,12,8
#setTempRaumRedSollM2 Tempsoll_Wohnz_Reduz 22,21,20,19,12,8
#setTempWWsoll Tempsoll_Warmwasser 60,15
#setTimerWWMo WW_1Mo_spaet 07:40-10:10|12:00-12:30|15:30-16:00|19:00-20:30
#setTimerWWDi WW_2Di_spaet 08:00-10:00|12:00-12:30|15:30-16:00|19:00-20:30
#setTimerWWMi WW_3Mi_spaet 06:10-10:00|12:00-12:30|15:30-16:00|19:00-20:30
#setTimerWWDo WW_4Do_spaet 08:00-10:00|12:00-12:30|15:30-16:00|19:00-20:30
#setTimerWWFr WW_5Fr_spaet 08:10-10:00|12:00-12:30|15:30-16:00|19:00-20:40
#setTimerWWSa WW_6Sa_spaet 08:00-11:00|14:00-15:00|17:00-20:30|
#setTimerWWSo WW_7So_spaet 08:00-13:10|16:00-17:00|18:50-20:30|
########################################################
#
# all available commands from my vcontrold
#
########################################################
##getTempAbgas: Ermittle die Abgastemperatur in Grad C
##getNeigungM1: Ermittle Neigung Heizkennlinie M1
##getNeigungM2: Ermittle Neigung Heizkennlinie M2
##getNiveauM1: Ermittle Niveau Heizkennlinie M1
##getNiveauM2: Ermittle Niveau Heizkennlinie M2
##setNeigungM1: Setze Neigung Heizkennlinie M1
##setNeigungM2: Setze Neigung Heizkennlinie M2
##setNiveauM1: Setze Niveau Heizkennlinie M1
##setNiveauM2: Setze Niveau Heizkennlinie M2
##getTempVListM1: Ermittle die Vorlauftemperatur M1 in Grad C
##
##getTempVListM2: Ermittle die Vorlauftemperatur M2 in Grad C
##
##getStatusStoerung: Status Sammelstoerung
##getTempA: Ermittle die Aussentemperatur in Grad C
##getTempWWist: Ermittle die Warmwassertemperatur in Grad C
##
##getTempWWsoll: Ermittle die Warmwassersolltemperatur in Grad C
##
##setTempWWsoll: Setze die Warmwassersolltemperatur in Grad C
##
##getTempStp2: Ermittle die WW Auslauftemperatur in Grad C (Tiefpass)
##
##getTempKist: Ermittle die Kesseltemperatur in Grad C
##getBetriebszeitStandby: Ermittle die NRF_BetriebszeitStandby
##getBrennerStarts: Ermittle die Brennerstarts
##getBrennerStunden1: Ermittle die Brennerstunden Stufe 1
##getTempVLsollM1: Ermittle die Vorlaufsolltemperatur M1 in Grad C
##
##getTempVLsollM2: Ermittle die Vorlaufsolltemperatur M2 in Grad C
##
##getTempRaumNorSollM1: Ermittle die Raumsolltemperatur normal M1 in Grad C
##
##setTempRaumNorSollM1: Setze die Raumsolltemperatur normal M1 in Grad C
##
##getTempRaumNorSollM2: Ermittle die Raumsolltemperatur normal M2 in Grad C
##
##setTempRaumNorSollM2: Setze die Raumsolltemperatur normal M2 in Grad C
##
##getTempRaumRedSollM1: Ermittle die Raumsolltemperatur reduziert M1 in Grad C
##
##setTempRaumRedSollM1: Setze die Raumsolltemperatur reduziert M1 in Grad C
##
##getTempRaumRedSollM2: Ermittle die Raumsolltemperatur reduziert M2 in Grad C
##
##setTempRaumRedSollM2: Setze die Raumsolltemperatur reduziert M2 in Grad C
##
##getTimerM1Mo: Schaltzeit Montag M1
##getTimerM1Di: Schaltzeit Dienstag M1
##getTimerM1Mi: Schaltzeit MIttwoch M1
##getTimerM1Do: Schaltzeit Donnerstag M1
##getTimerM1Fr: Schaltzeit Freitag M1
##getTimerM1Sa: Schaltzeit Samstag M1
##getTimerM1So: Schaltzeit Sonntag M1
##getTimerM2Mo: Schaltzeit Montag M2
##getTimerM2Di: Schaltzeit Dienstag M2
##getTimerM2Mi: Schaltzeit Mittwoch M2
##getTimerM2Do: Schaltzeit Donnerstag M2
##getTimerM2Fr: Schaltzeit Freitag M2
##getTimerM2Sa: Schaltzeit Samstag M2
##getTimerM2So: Schaltzeit Sonntag M2
##getTimerWWMo: Schaltzeit Montag Warmwasser
##getTimerWWDi: Schaltzeit Dienstag Warmwasser
##getTimerWWMi: Schaltzeit Mittwoch Warmwasser
##getTimerWWDo: Schaltzeit Donnerstag Warmwasser
##getTimerWWFr: Schaltzeit Freitag Warmwasser
##getTimerWWSa: Schaltzeit Samstag Warmwasser
##getTimerWWSo: Schaltzeit Sonntag Warmwasser
##getTimerZirkuMo: Schaltzeit Montag Zirku
##getTimerZirkuDi: Schaltzeit Dienstag Zirku
##getTimerZirkuMi: Schaltzeit Mittwoch Zirku
##getTimerZirkuDo: Schaltzeit Donnerstag Zirku
##getTimerZirkuFr: Schaltzeit Freitag Zirku
##getTimerZirkuSa: Schaltzeit Samstag Zirku
##getTimerZirkuSo: Schaltzeit Sonntag Zirku
##getBetriebArtM1: Betriebsart M1
##getBetriebArt: Betriebsart
##getBetriebArtM2: Betriebsart M2
##getBetriebSparM1: Betriebsart Spar M1
##getBetriebSparM2: Betriebsart Spar M2
##getBetriebPartyM1: Betriebsart Party M1
##getBetriebPartyM2: Betriebsart Party M2
##getTempPartyM1: Solltemperatur Partybetrieb M1
##setTempPartyM1: Setze die Warmwassersolltemperatur Party M1 in Grad C
##
##getTempPartyM2: Solltemperatur Partybetrieb M2
##setTempPartyM2: Setze die Warmwassersolltemperatur Party M2 in Grad C
##
##setBetriebPartyM1: Setze Betriebsart Party M1
##setBetriebPartyM2: Setze Betriebsart Party M2
##getStatusFrostM1: Status Frostwarnung M1
##getStatusFrostM2: Status Frostwarnung M2
##getError0: Ermittle Fehlerhistory Eintrag 1
##getError1: Ermittle Fehlerhistory Eintrag 2
##getSystemTime: Ermittle Systemzeit
##setSystemTime: Setze Systemzeit
##setTimerM1Mo: Schaltzeit Montag M1
##setTimerM1Di: Schaltzeit Dienstag M1
##setTimerM1Mi: Schaltzeit Mittwoch M1
##setTimerM1Do: Schaltzeit Donnerstag M1
##setTimerM1Fr: Schaltzeit Freitag M1
##setTimerM1Sa: Schaltzeit Samstag M1
##setTimerM1So: Schaltzeit Sonntag M1
##setTimerM2Mo: Schaltzeit Montag M2
##setTimerM2Di: Schaltzeit Dienstag M2
##setTimerM2Mi: Schaltzeit Mittwoch M2
##setTimerM2Do: Schaltzeit Donnerstag M2
##setTimerM2Fr: Schaltzeit Freitag M2
##setTimerM2Sa: Schaltzeit Samstag M2
##setTimerM2So: Schaltzeit Sonntag M2
##setTimerWWMo: Schaltzeit Montag Warmwasser
##setTimerWWDi: Schaltzeit Dienstag Warmwasser
##setTimerWWMi: Schaltzeit Mittwoch Warmwasser
##setTimerWWDo: Schaltzeit Donnerstag Warmwasser
##setTimerWWFr: Schaltzeit Freitag Warmwasser
##setTimerWWSa: Schaltzeit Samstag Warmwasser
##setTimerWWSo: Schaltzeit Sonntag Warmwasser
##setTimerZirkuMo: Schaltzeit Montag Zirku
##setTimerZirkuDi: Schaltzeit Dienstag Zirku
##setTimerZirkuMi: Schaltzeit Mittwoch Zirku
##setTimerZirkuDo: Schaltzeit Donnerstag Zirku
##setTimerZirkuFr: Schaltzeit Freitag Zirku
##setTimerZirkuSa: Schaltzeit Samstag Zirku
##setTimerZirkuSo: Schaltzeit Sonntag Zirku
##getDevType: Ermittle Device Typ der Anlage / SystemIdent_SX
Diese habe ich nach /opt/fhem/vcontrol/Vclient.cfg geschoben
Rechte für den Ordner sowie Cfg auf 644. Besitzer fhem. Gruppe dialout.
Vclient habe ich so angelegt
define vitodens222 VCLIENT 192.168.178.54 3002 /opt/fhem/vcontrol/Vclient.cfg 120
Danach geht der State nur auf closed.
Per Terminal auf meinen Fhem Pi zum Heizungs Pi klappt Telnet. Was fhelt mir jetzt noch?
Moin.
Deine cfg sieht spannend (falsch) aus.
Fang doch erstmal klein an und lösch alles und starte mit einer zeile.
getTempA getTempA
Das Format ist immer name aus der xml und anschließend name des gewünschten fhem readings. Steht aber auch im wiki und auch ein wenig im Kommentar deiner angehangegen cfg.
Gruss
Maui
Ahhhh, danke. Bei den ganzen Configs habe ich übersehen das ich die nicht 1 zu 1 übernehmen muss.
Sonder Readings zuordnen muss ;D
Läuft, super
Internals:
CFGFN
DEF 192.168.178.54 3002 /opt/fhem/vcontrol/Vclient.cfg 320
FILE /opt/fhem/vcontrol/Vclient.cfg
FUUID 5f822a37-f33f-86cf-88ff-2c54bb9704f19890
INTERVAL 320
IP 192.168.178.54
NAME vitodens222
NR 393
PORT 3002
STATE closed
TYPE VCLIENT
READINGS:
2020-10-10 23:57:22 Aussentemperatur 8.0
2020-10-10 23:57:18 Kesselsolltemperatur 34.0
2020-10-10 23:57:23 Kesseltemperatur 21.5
2020-10-10 23:57:20 Warmwassersolltemperatur 50.0
2020-10-10 23:57:19 Warmwassertemperatur 45.0
2020-10-10 23:57:23 state closed
Attributes:
room 01.Heizung_UG
Am Ende haperts dann bei so Kleinigkeiten...
Danke für das Modul @andies und @CoolTux :)
Harald (Xaneu) hat den Vorschlag, das Modul systematischer zu gestalten. Auch wenn das momentan nicht unbedingt notwendig erscheint, ist mir das langfristig lieber - denn ein systematisches Modul überlebt möglicher Maintainer-Wechsel, weil sich neue Leute leichter einarbeiten können. Kern der Änderung besteht darin, dass das Modul keine inhaltlichen Veränderungen an den rückgemeldeten Daten mehr vornimmt, sondern dies in FHEM selbst geschieht. Bekanntermaßen gibt ja vcontrold sowohl Terminreihen, Temperaturen, Fehlercodes und andere Dinge zurück und das im Modul selbst zu handhaben ist ungeschickt, weil das Modul eigentlich nur für die Kommunikation mit vcontrold zuständig sein soll.
Wir diskutieren gerade in diesem Thread mögliche Veränderungen: https://forum.fhem.de/index.php/topic,130793.msg1259092.html#msg1259092 (https://forum.fhem.de/index.php/topic,130793.msg1259092.html#msg1259092). Wenn jemand damit partout nicht einverstanden ist, sollte er den update-Prozess besser jetzt ausschalten
attr global exclude_from_update 89_VCLIENT
Wir würden uns natürlich auch über Rückmeldungen freuen, am besten in dem anderen Thread. Dann lassen wir den hier für mögliche Probleme offen.
In Bezug auf mein Post zwei vor deinem, würde ich eine Änderung für sinnvoll halten, das die Namen 1zu1 weitergeben werden.
Gruß schwatter
Kannst du mal ein oder zwei Beispiele machen? Also wie sähe die ideale Zuordnung aus?
Morgen,
die Namen werden doch final in der vito.xml festgelegt. Dort können die angepasst werden und diese sollte dann Fhem einlesen.
Gruß schwatter