vcontrold (Dämon für Viessmann Heizungssteuerungen) für EDOMI

[MichaP]

Hat jemand die Lösung mittlerweile auf einem externen RPi laufen?

Hast du es geschafft, über den Raspberry und den LBS Daten auszulesen?

Im Log findet sich dieser Eintrag "EXE19001530 [v1.10]: FEHLER vclient - Rückgabewert 1"

[stonie2oo4]

Das Problem hatte ich auch ... Die Lösung ist leider nicht so einfach: man muss vcontrold patchen und neu kompilieren

Das hab ich gestern Abend nach längerer Suche auch gefunden.
Danke, dass bestätigt wenigstens dass ich auf dem richtigen Weg war .

Mhh, könntest/würdest du vielleicht deinen vcontrold zu Verfügung stellen wenn du diesen schon erfolgreich gebaut hast?
Wobei ich seh grad du hast CentOS 7 im Einsatz, würde dies dann überhaupt mit CentOS 6.5 funktionieren?

Wenn es nicht geht, kann ich mir dann einfach CentOS 6.5 in der VirtualBox aufsetzen und vcontrold dort bauen und danach einfach zu Edomi kopieren?

[MrData]

Mhh, könntest/würdest du vielleicht deinen vcontrold zu Verfügung stellen wenn du diesen schon erfolgreich gebaut hast?
Wobei ich seh grad du hast CentOS 7 im Einsatz, würde dies dann überhaupt mit CentOS 6.5 funktionieren?

Wenn es nicht geht, kann ich mir dann einfach CentOS 6.5 in der VirtualBox aufsetzen und vcontrold dort bauen und danach einfach zu Edomi kopieren?

Ich bin jetzt nicht der große Linux-Experte, aber ich glaube das funktioniert so nicht. Durch das Kompilieren werden automatisch alle Besonderheiten der Umgebung berücksichtigt, es fängt schon damit an, dass der RPi auf ARM basiert und mein NUC eine Intel 64-Bit-Plattform ist

Aber keine Angst: das Kompilieren unter Linux ist wesentlich einfacher als man denkt, außerdem wird dadurch alles korrekt installiert

Wenn ich mich dunkel erinnere muss man
- gcc installieren
- die diff-Datei auf den Quellcode anwenden (diff oder patch hieß der Befehl)
- dann make-Befehl gemäß Anleitung (das steht bei vcontrold)

Sicherlich kann man das auch in VirtualBox machen ... Man hat aber wieder das gleiche Problem, dass sich die Zielplattform unterscheidet (das geht, wenn man für die Zielplattform kompiliert, das hab ich aber noch nie gemacht)

[stonie2oo4]

Naja, ganz so einfach scheint es doch nicht zu sein. Versuch mich schon den ganzen Nachmittag daran .
Bin im wesentlichen nach MrIcemanLE `s Anleitung vorgegangen:
https://knx-user-forum.de/forum/proj...46#post1044246
bzw. nach dieser hier, was ja im wesentlichen dass gleiche ist:
https://github.com/openv/openv/wiki/...t-Raspberry-Pi

Das Problem hierbei ist, das die Sourcen der verwendeten Anleitung dort "mittlerweile" Revision 107 und der Patch aber für Revision 106 ist.
Leider bringt er mir dann beim patchen einen Fehler.

Aber so wie es für mich aussieht, sind die Sourcen dort eh schon veraltet und die aktuellen liegen mitlerweile auf Github:
https://github.com/openv/vcontrold

Und wenn ich es richtig verstanden habe ist dort der Patch auch schon mit eingeflossen, seit v0.98.6.
Also hab ichs damit versucht, aber die INSTALL.md ist für so nen noob wie mich leider recht dürftig.

Hab zwar was probiert, aber hier bin ich daran gescheitert das meine cmake version angeblich zu gering ist.


Mal ne andere Frage, was ist beim compilieren eigentlich wichtig?
Eigentlich doch nur die Systemarchitektur, also ob z.B. x86 oder arm, oder liege ich hier falsch?

Weil hier auf Github gibt es auch schon einige fertig kompilierten Pakete:
https://github.com/openv/vcontrold/releases

Habs jetzt mal mit der amd64 Version von dort probiert, aber leider auch ohne Erfolg.
Bei mir läuft Centos 6.5 auf einer APU.
Bin her gegangen und hab einfach das amd64.zip runtergeladen und den vcontrold und vclient auf edomi ausgetauscht.
Neugestartet und in Edomi den LBS angeschmissen, aber dort rührt sich nichts. Log wird auch keins geschrieben.

murelli146
Hast du den vcontrold welcher bei deinem LBS dabei ist selber gebaut?
Wenn ja, hast du die Sourcen von Github verwendet, oder noch die anderen?

[MrData]

Ich weiß nicht, ob das mit der Zip-Datei so ohne weiters funktioniert. Man kann unter Linux nicht einfach eine Datei irgendwo hinpacken, man muss noch die Rechte einstellen mit chmod und chown ... 1. Als ausführbar markieren (x-Recht) und 2. Es muss für den Nutzer /Gruppe verfügbar sein. Vcontrold ist außerdem ein Hintergrunddienst ... Das muss mit systemctl richtig eingerichtet und gestartet sein.

Normalerweise macht man das alles über das yum-Programm und man muss sich um nichts mehr kümmern. Ich habe gesehen, dass es vcontrold noch als deb-Paket zum Download gibt ... CentOS benötigt aber rpm-Pakete. Es scheint wohl die Möglichkeit zu geben das umzuwandeln https://www.webhostinghero.com/how-t...s-using-alien/ ... Hab ich aber noch nie probiert


Nochmal zum kompilieren (ungetestet):

Erstmal benötigt man einen Compiler (falls es schon drauf ist einfach jeweils das gleiche mit sudo yum update ... versuchen)

sudo yum install gcc gcc-c++


cmake installieren

sudo yum install cmake


Dann noch die XML-Bibliothek

sudo yum install libxml2-dev


Dann weiter wie in der Anleitung:
Zip-Datei mit Quellcode runterladen

In das Quellcodeverzeichnis wechseln und tippen:

mkdir build
cd build
cmake ..
make
sudo make install


Wenn dort irgendwo eine Meldung kommt, dass etwas fehlt einfach sudo yum install <Name des fehlenden Teil> tippen (kann auch unvollständig sein, yum fragt dann wenn es mehr zur Auswahl gibt)

[stonie2oo4]

Man kann unter Linux nicht einfach eine Datei irgendwo hinpacken

Stimmt in diesem Fall glaub ich nicht so ganz. Da ja beim LBS auch der vcontrold und vclient als zip dabei sind, zum einfachen kopieren ins edomi.
Das mit den Rechten stimmt natürlich, aber wenn ich es richtig gesehen hab, kümmert sich hier sogar der LBS darum und setzt die richtigen Rechte.


Hab mich jetzt aber trotzdem nochmal dran versucht. Aber leicht ist anders....

Hab dass ganze unter Virtualbox gemacht. Dort die CentOS von gaert installiert und dann nach dieser Anleitung:
https://github.com/openv/openv/wiki/...ld-Kompilieren
und nach MrIcemanLE's Anleitung:
https://knx-user-forum.de/forum/proj...46#post1044246

den vcontrold und vclient kompiliert. Ging natürlich nicht auf Anhieb, weil wie oben erwähnt die cmake Version zu gering war. Also erstmal cmake kompiliert, dann kam der nächste Fehler, hat ne Weile gedauert bis ich dahinter kam, dann noch python-docutils installiert und dann liefs endlich durch .

Hab dann vcontrold und vclient auf mein edomi übertragen... Nix geht.
Aus reinem Zufall hab ich dann nur den alten vclient wieder drauf gemacht... Lüppt, YEAH


Jetzt mal die nächsten Tage beobachten ob noch irgendwelche Überraschungen auf mich lauern, oder obs endlich geht

Falls jemand testen will hier der vcontrold:
https://drive.google.com/file/d/15Tl...ew?usp=sharing

Und hier der vclient:
https://drive.google.com/file/d/1i7q...ew?usp=sharing


Vielleicht findet ja jemand die Ursache warum es mit diesem vclient nicht funktioniert. Würd mich doch noch brennend interessieren.
Denk mal dass es nicht ganz so optimal ist nen aktuellen vcontrold mit nem alten vclient zu betreiben, auch wenn momentan alles scheinbar geht...


Das ganze ist im übrigen nur notwendig wenn jemand dass Protokoll 300 verwendet, hier werden beim setzen von Werten mit der alten Version die Rückgabewerte falsch interpretiert, da dass Protokoll 300 noch eine Prüfsumme anhängt. Was in edomi dazu führt dass trotz erfolgreichem setzen von Werten, an A1 ein Fehler angezeigt wird.

Wäre aber auch cool, wenns mal jemand mit dem älteren KW Protokoll probieren würde und wenns damit auch lüppt und es sonst keine Probleme damit gibt, wäre es vielleicht überlegenswert die neuere Version dem LBS beizulegen .

[MichaP]

Hat jemand die Lösung mittlerweile auf einem externen RPi laufen? Mein Edomi steht nicht neben der Heizung, daher kann ich nicht direkt anschließen.
Also habe ich nun einen RPi in der Heizung, auf dem vcontrold läuft. Die .xml Dateien sind angepasst, ich kann mit Putty im LAN und WLAN vom Laptop aus über vctrld Werte auslesen, Kommunikation funktioniert problemlos.

Kann ich jetzt bei dem LBS irgendwie mit dem RPi kommunizieren, wenn ich dort die IP eintrage?
Auf Anhieb tut sich natürlich nichts... Hat das schon jemand so realisiert?

Die Lösung würde mich auch interessieren.

[MrIcemanLE]

Vielleicht findet ja jemand die Ursache warum es mit diesem vclient nicht funktioniert. Würd mich doch noch brennend interessieren.

[20904] Mon Mar 9 17:56:02 2020 : Error in getaddrinfo: 127.0.0.1:3002:Name or service not known

Habe jetzt mal deine kompilierten Programme ausprobiert. Gleiches Verhalten wie bei dir. Der vcontrold funktioniert und der "neue" vclient nicht. Mit dem alten scheint es zu laufen.

[stonie2oo4]

Echt komisch, wird ja zusammen kompiliert. Hab dass ganze jetzt so seit nem Monat laufen, bisher konnte ich keine Probleme feststellen.

Kann es sein, dass sich bei der Abfrage was geändert hat und der LBS das nicht unterstützt?
Glaub hab hier was gefunden, woran es liegen könnte:
https://github.com/openv/vcontrold/issues/58

Anscheinend geht es wenn man die Abfrage anstatt so

vclient -h 127.0.0.1:3002 -c getSystemTime -v

folgendermaßen schreibt

vclient -h 127.0.0.1 -p 3002 -c getSystemTime -v

hab es selber aber noch nicht getestet.

[MrIcemanLE]

Hab es mal kurz getestet. Es scheint so zu sein, wie Ben es beschrieben hat. Der "neue" vclient funktioniert, wenn man den Port separat übergibt.

Was jedoch etwas merkwürdig ist, ist dass der Issue am 7. Januar geschlossen wurde, weil der Fehler in der aktuellen Version behoben wurde. Also entweder hatte stonie2oo4 nicht den aktuellen Stand oder der Fehler ist nicht wirklich raus.

Vielleicht könnte murelli146 den LBS bei Gelegenheit mal anpassen. Damit wären wir mit dem LBS auf dem aktuellen Stand, was Dämon und Client angeht.

Habe auch schon mit der aktuellen Version erfolgreich eine WW-Bereitung gestartet.

[stonie2oo4]

Also kompiliert hab ich es ja am 06.02.2020, somit sollten es schon die aktuellen Sourcen sein. Warum es trotzdem nicht geht, geht leider über mein Verständnis hinaus.

Hab jetzt den LBS bei mir mal testweiße angepasst, somit funktioniert er mit der alten und neuen Version des vclient.
Jetzt läuft auch endlich der neue vclient bei mir .
Und ich muss jetzt nach einem Monat sagen dass P300 Protokoll läuft echt super. Fühlt sich wesentlich schneller an, und dass Fehlerhandling soll ja auch besser sein.
Danke dir Stefan, hättest du dass jetzt nicht probiert, wäre es wahrscheinlich noch in 2 Jahren mit dem alten vclient bei mir geloffen .
So gefällt mir dass natürlich wesentlich besser .


Wer möchte kann es ja mal gern bei sich ausprobieren.
Einfach folgende Zeilen ändern:

$command = $vc_pfad.'vclient -h ' . $ip . ':' . $port . ' -c '."'".$cmd_w."'".' 2>&1';

in:

$command = $vc_pfad.'vclient -h ' . $ip . ' -p' . $port . ' -c '."'".$cmd_w."'".' 2>&1';

und:

$command = $vc_pfad.'vclient -h '.$ip.':'.$port.' -f '.$pfad_commands.' -t '.$pfad_template.' -o '.$pfad_status.' 2>&1';

in:

$command = $vc_pfad.'vclient -h '.$ip.' -p'.$port.' -f '.$pfad_commands.' -t '.$pfad_template.' -o '.$pfad_status.' 2>&1';

murelli146 Wäre natürlich am besten, wenn du dass vielleicht in einer zukünftigen Version mit einfließen lassen könntest .

[Thisischris]

Hey 👋
Ich interessiere mich gerade auch für das Thema, habe aber vorab eine Frage, die (glaube ich) hier noch nicht behandelt wurde.

Ich habe ein Vitoconnect 100 und kann daher per WLAN und App über mein Smartphone die Heizungs- und Lüftungsanlage steuern.
Allerdings nur sehr eingeschränkt. Die interessanten Dinge auslesen (Ansaugtemperatur, Ablufttemperatur, usw.) und die interessanten Dinge steuern (Heizung runterfahren wenn morgen Sonne, oder ähnliches) gehen nicht. Das würde ich gerne über EDOMI lösen.

Der vcontrold funktioniert aber anscheinend nur, wenn ich das opto1 kabel jetzt an bspw. den EDOMI Rechner oder einen Raspberry-Pi anschließe, richtig? Ich will die Vitoconnect aber nicht trennen...

Kann ich die Steuerung auch über den Vitoconnect laufen lassen?

[MrIcemanLE]

Ich wüsste nicht, wie das funktionieren soll. Es kann über die Schnittstelle immer nur einer kommunizieren. Also selbst wenn man da eine optische Weiche an die LEDs hängt oder sich (wie auch immer) an mit an das Kabel der Vitoconnect hängt, bleibt das Problem, dass einer ggf. die Kommunikation des anderen stört.

Die einzige Option ist auf die Vitoconnect zu verzichten und auch diese Funktionen mit vcontrold und EDOMI abbilden. Es funktionieren ja auch Set-Befehle, sodass du auch Kennlinie, Raum-Soll-Temp, WW-Temp u. a. einstellen könntest.

Welchen Mehrwert durch die Vitoconnect hättest du dann noch?

[Thisischris]

Mein Heizungsinstallateur gibt mir 5 Jahre Garantie auf alles wenn er Zugriff hat. Dafür brauche ich zwingend die Vitoconnect.
Zitat Viessmann:

Online-Aufschaltung und Anlagen-Monitoring - Nach einer individuellen Servicefreigabe durch den Anlagenbetreiber hat der Heizungsfachbetrieb mittels Vitoguide die Anlage immer im Blick.

[gbglace]

Hängt die Vitoconnect denn an der optischen Schnittstelle und nicht irgendwo auf der Platine am LON-Bus?