Erweiterung Helios / Vallox Plugin

[Tom Bombadil]

Hallo Andreas,
zuerst einmal vielen Dank für die Bestätigung des Einschaltverhaltens. Nun ist also auch offiziell, was immer vermutet wurde.

Zum Script: Nutzt Du das Skript im Rahmen von smarthomeNG oder solo? Letzteres dürfte seit der Umstellung auf SmartPlugin recht tricky bzw. kaum noch möglich sein (ist eine Weile her, dass ich das getestet habe - müsste zu Hause nachsehen, was da genau damals los war, irgendwie kamen mir diverse Fehler um die Ohren geschossen).

/tom

[ballaballa1556]

Hallo zusammen,

ich habe eine Vallox ValloPlus 510 SE, die ich gerne an meine Hausautomation anbinden würde. Ich habe einen Raspberry Pi mit einem RS485-shield, an die ich die KWL angeschlossen habe (siehe auch hier). Mit Hilfe der __init__.py aus Toms Projekt funktioniert die Kommunikation auch grundsätzlich. Hier ein Beispiel:

python __init__.py -r fanspeed
Verwendeter Port: /dev/ttyAMA0
DEBUG:test:Helios: Connecting...
DEBUG:test:Helios: Reading value: fanspeed
DEBUG:test:Helios: Sending telegram '0x01 0x23 0x11 0x00 0x29 0x5E'
DEBUG:test:Telegram received '0x01 0x11 0x22 0x29 0x03 0x60'
DEBUG:test:Value for fanspeed (0x29) received: 0x03|00000011|3 --> converted = 2
fanspeed = 2
DEBUG:test:HeliosBase: Disconnecting...

Allerdings bin ich nicht in der Lage, Werte zu setzen. Setze ich z. B. folgenden Befehl ab:

python __init__.py -w fanspeed -v 3
Verwendeter Port: /dev/ttyAMA0
DEBUG:test:Helios: Connecting...
DEBUG:test:Helios: Sending telegram '0x01 0x23 0x20 0x29 0x07 0x74'
DEBUG:test:Helios: Sending telegram '0x01 0x23 0x10 0x29 0x07 0x64'
DEBUG:test:Helios: Sending telegram '0x01 0x23 0x11 0x29 0x07 0x65'
DEBUG:test:Helios: Sending telegram '0x65'
DEBUG:test:HeliosBase: Disconnecting...

und frage anschließend die Schnittstelle ab, bekomme ich dasselbe Ergebnis wie oben. Ich war bisher nicht in der Lage, irgendeine Einstellung der KWL auf diesem Weg zu ändern. Um auf dem Bus zu horchen, habe ich die __init__.py um eine Funktion erweitert, die eine vorgegebene Zeit lang alle Telegramme ausgibt, die mit 0x01 beginnen und an 5. Stelle eine zum Telegramm passende Checksumme haben. Dann habe ich die Lüfterstufe über das Bedienteil geändert. Die mitgeschnittenen Telegramme entsprechen exakt denen, die im Beispiel oben verschickt werden. Trotzdem ändert sich die Lüfterstufe nicht, wenn ich das ganze vom RasPi aus sende. Interessant an dem ersten Beispiel ist, dass ich als Sender '0x23' eingestellt habe, die Anlage aber mit '0x22' antwortet (Bei Absenderadresse 0x22 antwortet die Anlage mit 0x21). Könnte es sein, dass sich das shield erstemal irgendwie bei der Anlage anmelden muss? Es funktioniert übrigens auch nicht, wenn das Bedienteil mit der Adresse 0x22 aus ist und ich dann die Adresse des shields auf 0x22 setze...

Hat irgendjemand die gleiche Anlage wie ich und ist in der Lage, Werte zu setzen? Falls ja, wie? Oder hatte jemand mit einer anderen Anlage das gleiche Problem und es gelöst? Die Werte der Anlage auszulesen ist zwar ganz nett, aber ich wäre gerne in der Lage, die Anlage z. B. 2 Tage vor Rückkehr aus dem Urlaub auf 8 zu drehen... :-) Ich hoffe, Ihr seid noch aktiv, obwohl der letzte Kommentar fast 1 Jahr alt ist. Ich bin für jeden Hinweis dankbar!

Ich habe übrigens 2 Bedienteile. Hier kam schon mal die Frage auf, was passiert, wenn man nacheinander die beiden Bedienteile einschaltet. Ich hatte deswegen mal bei Vallox nachgefragt und die folgenden Abläufe beschrieben, wie sie tatsächlich sind:

• Die Anlage und beide Bedienteile sind aus.
• Bedienteil A wird eingeschaltet.
• Bedienteil B bleibt komplett aus (LED und Display).
• An Bedienteil A kann die Anlage nun beliebig eingestellt werden (z. B. auf Stufe 4), ohne dass Bedienteil B dadurch aktiviert wird.
• Bedienteil B wird eingeschaltet. Dadurch wird die Anlage automatisch auf Stufe 1 zurückgestellt. Bedienteil A übernimmt die Stufe 1 im Display.
• Wird nun an einem der beiden Bedienteile die Stufe verändert, übernimmt das andere Bedienteil die eingestellte Stufe.
• Wird die Anlage an einem der Bedienteile ausgeschaltet, schaltet sich das andere Bedienteil ebenfalls aus und der Ablauf beginnt von vorn.

• Die Anlage und beide Bedienteile sind aus.
• Bedienteil A wird eingeschaltet.
• Die Anlage wird mit Bedienteil A z. B. auf Stufe 3 gestellt.
• Die Anlage wird an Bedienteil A abgeschaltet.
• Bedienteil B wird eingeschaltet.
• Die Anlage startet auf der zuvor mit Bedienteil A eingestellten Stufe.

Als Antwort habe ich Folgendes erhalten: "Ihre Beschreibung entspricht dem was auch wir im Test bei uns auch festgestellt haben, somit liegt bei Ihnen kein Fehler vor." Ich habe dann nochmal nachgehakt und geschrieben, dass das Verhalten der beiden Bedienteile im Zusammenspiel ja so nicht korrekt sei und was sie gedenken, dagegen zu tun. Daraufhin erhielt ich folgende Antwort: "dieses Verhalten lässt sich leider nicht ändern, es ist Systembedingt". Falls immer noch Informationsbedarf besteht, ich probiere gerne alles nach Wunsch aus. Einfach schreiben, was ich ausprobieren soll...

Vielen Dank im Voraus und viele Grüße

Andreas

[Marcov]

Ja, ich habe auch bei Vallox nach der Dokumentation gefragt, bin aber nicht sicher, ob sie sie rausrücken. Da ich ja leider keine Fernbedienung mehr habe, kann ich es nur begrenzt mitlesen und daraus ableiten, ich glaube aber im FHEM Forum ist man da schon weiter, weil dort jemand mit Fernbedienung ist.

[Tom Bombadil]

Danke für die Rückmeldung - meine Überlegung ist, dann wie bei FHEM die Sache über einen Parameter in der plugin.conf zu steuern, so dass die Werte auf den dafür vorgesehenen Variablen landen. Sofern da keine Überlappungen sind (hab beim Überfliegen keine gesehen), braucht es vielleicht nicht einmal den Parameter, sondern nur ein paar case bzw if-Anweisungen ...
/tom

[Marcov]

Hi Tom,

ja habe ich gemacht und es so abgeändert (läuft so):

"outside_temp"    : {"varid" : 0x58, 'type': 'temperature',  'bitposition': -1, 'read': True, 'write': False },#working
"exhaust_temp"    : {"varid" : 0x5c, 'type': 'temperature',  'bitposition': -1, 'read': True, 'write': False },#working
"inside_temp"     : {"varid" : 0x5A, 'type': 'temperature',  'bitposition': -1, 'read': True, 'write': False },#working
"incoming_temp"   : {"varid" : 0x5B, 'type': 'temperature',  'bitposition': -1, 'read': True, 'write': False },#working 

Ich versuche noch mal die anderen Variabeln usw. herauszufinden und gebe dann Bescheid, dann könnte man in der Plugin.conf ggf. neben der Standardversion auch eine andere Version einstellen und so die alten Anlagen steuern / auslesen.

[Tom Bombadil]

Hast Du die Register 58...5C mal in der __init__.py des Plugins geändert (dort: 32...35)? Hinterher bitte __pycache__ löschen. Die Temperaturen sind ja eh read-only, kann also eigentlich nix kaputtgehen. A4 klingt auch nicht weiter wild, sind halt Temperatursprünge von 2.5°C ...
/tom

[Marcov]

hi, aus dem FHEM Forum habe ich folgende Infos:

"29" => "FanSpeed" - Passt

"A3" => "Select" - Sieht gut aus. Das Symbol für den "Wärmetauscher" sieht eher nach der Heizung im Gerät aus. Dazu würden die Readings HeatingState und HeatingIndicator (links die Taste und Rechts die LED) und das A4 passen. Was sagt das Handbuch der Fernbedienung denn genau?

"A4" => "HeatingSetPoint" - Hier hat man die Interpretation der Werte geändert. Das sind keine Temperaturen sondern Stufen wie beim FanSpeed:
01: 1 (10°)
03: 2
07: 3
0F: 4
1F: 5 (20°)
3F: 6
7F: 7
FF: 8 (27°)

folgende Werte sind dort noch unbekannt:

"49" => "Legacy49", # Unknown legacy Reading
"4A" => "Legacy4A", # Unknown legacy Reading
"4C" => "Legacy4C", # Unknown legacy Reading
"53" => "Legacy53", # Unknown legacy Reading
"54" => "Legacy54", # Unknown legacy Reading
"58" => "Legacy58", # Unknown legacy Reading
"5A" => "Legacy5A", # Unknown legacy Reading
"5B" => "Legacy5B", # Unknown legacy Reading
"5C" => "Legacy5C", # Unknown legacy Reading

dank Heißluftfön habe ich die Temperaturwerte identifizieren können:
58 -> Zuluft von Außen
5A -> Abluft Wohnung
5B -> Zuluft Wohnung
5C -> Außen Abluft

[Marcov]

hi Tom, danke, ich habe es auch nicht genau rausgefunden, frage dort aber mal nach

[Tom Bombadil]

Wenn ich den FHEM-Beitrag beim Querlesen richtig verstanden habe, gibt es bei einigen älteren Anlagen ein anderes Protokollverhalten.
Leider werden keine Details geliefert, was genau zu tun ist, um das Problem zu beheben.
Das muss ich erstmal sacken lassen - keine Ahnung, ob ich dafür kurzfristig eine Lösung finde (kann es halt hier nicht sniffen/testen) ...
/tom

[Marcov]

Hi Tom,
also es ist nichts angeschlossen außer der USB Schnittstelle, da ich über keinen Raumcontroller / Fernbedienung verfüge, ist dieser auch nicht angeschlossen.
Es ist eine Vallox 130D, hierfür finde ich so gut wie keine Dokumentation, die zum Serienumfang gehörende Fernbedienung ist die FBD 370 (die ist auch bei der digit SE dabei).
Im FHEM Forum gibt es hierzu auch eine Diskussion, das schient aber ein anderes Problem zu sein:
https://forum.fhem.de/index.php?topic=71325.0
Also die Werte im Backend sind konstant und bei jeder Abfrage falsch und zwar von allen Temperaturangaben.
_device_error ist 6 ("CO2-Alarm:CO2-Wert >5.000 ppm seit mehr als 3 Minuten:Ursache ermitteln oder ggf. Sensor überprüfen lassen.")

ggf. liegt es daran, dass er von der Fernbedienung keinen CO2 Wert erhält (bin aber nicht sicher, ob die FBD 370 überhaupt einen Co2 Sensor hat).
Ich kann folgende Dinge tun:
Anlage an/aus (_power_state)
Ventilationsstufen (_fanspeed)

[Tom Bombadil]

Am Kabel sollte es nicht liegen - ich hab A/B bei mir sogar eine Zeitlang problemlos über 1.5er NYM am Laufen gehabt.
ie Kommunikation scheint grundsätzlich zu laufen, sonst wären Errors im Logfile.
Ist alles richtig verkabelt? Evtl. Sensor defekt? Was sagen die Werte im Backend?
Und: Über welche Anlage reden wir hier überhaupt?

/tom

[Marcov]

hi tom - danke für Deine Antwort. Vom visualisieren bin ich noch etwas entfernt.
Ich erhalte unplausible Werte. Wenn ich es richtig verstehe, ist das hier die Abfrage für die Temperatur:

2017-12-09  17:45:22 DEBUG    Main         KNX[default]: 1.2.57 set 3/0/8 to 007575c4
2017-12-09  17:45:22 DEBUG    Helios       Helios: Sending telegram '0x01 0x2F 0x11 0x00 0x33 0x74' 

die Antwort darauf:

2017-12-09  17:45:22 DEBUG    Helios       Telegram received '0x01 0x11 0x2F 0x33 0x33 0xA7'
2017-12-09  17:45:22 DEBUG    Helios       Value for exhaust_temp (0x33) received: 0x33|00110011|51 --> converted = -18 

Ich habe nich nachgemessen, es ist aber in jedem Fall wärmer!
Das gleiche bei den anderen Temperaturwerten.

Ich habe kein Netzwerkkabel verwendet, daran sollte es aber meiner Meinung nach nicht liegen, ggf. verwendet meine Anlage ein anderes Protokoll? Ist so etwas bekannt?

[Tom Bombadil]

Hilfe für Troubleshooting erhältst Du ggf. auch im Wiki. Das Widget für die Visu ist nach wie vor noch Baustelle/unvollständig (insbesondere das Popup für die Einstellungen - die Hauptseite ist aber im Grunde fertig und funktioniert).
/tom

[Marcov]

so, ich habe noch ein bisschen rumprobieren festgestellt, dass keine Antworten über die Schnittstelle kommen. Hierzu gibt es nun verschiedene Erklärungen:
a) Meine Anlage hat überhaupt keinen RS485 Bus
b) Meine Anlage hat ein anderes Protokoll (da normalerweise die Fernbedienung FBD 370 angeschlossen ist, sollte dem nicht so sein)
c) Es liegt daran, dass kein Raumcontroller angeschlossen ist (der ist nicht mehr da)
d) irgendetwas ist nicht richtig angeschlossen, wieviel Volt müssten auf dem RS485 Bus anliegen? Bei mir sind es 0.25.

---
so nachdem ich nun die alle Kabel in der Verteilerbox durchverdrahtet habe, emfange ich auch Daten und kann die Lüfterstufe steuern, die zu lesenden Werte machen noch keinen Sinn, aber ich probiere noch mal rum.

[Marcov]

Hallo,

ich bekommen leider immer ein "Could not open /dev/ttyUSB_485" egal ob ich das skript direkt über die Console ausführe oder als Plugin. Ursache kann ja eigentlich nur am USB to Serial Converter liegen und nicht an der Verbindung vom Serial converter zur Anlage? Ich verwende einen "QinHeng Electronics HL-340 USB-Serial adapter" den ich auf über UDEV auf den entsprechenden port verlinkt habe.
Ich verwende noch 1.2.0 und habe entsprechend die Init.py aus dem Eingangspost verwendet.

cat /dev/ttyUSB_485 gibt:

▒#ub    '▒1     ▒▒  PuTTYPuTTYPuTTYroot@ibbgateway:~# PuTTYPuTTYPuTTY 

egal ob die Anlage angeschlossen ist oder nicht.
Zwischenzeitig hatte ich es mal geschafft zu verbinden, allerdings waren die Werte alle "none" (über die Konsole).

Ich habe es nun mal an einen Raspberry angeschlossen (war vorher an einem Beaglebone). Damit kann ich schon mal mit der Schnittstelle verbinden, allerdings erhalte ich keine richtigen Werte:

"

2017-12-09 11:27:12,097 - root - ERROR - Helios: No valid value for 'boost_remaining' from ventilation system received.
boost_remaining = None 

da ich eine 130D habe und auch nicht 100% sicher bin, ob ich diese richtig angeschlossen habe, frage ich mich, ob man sich die Rohdaten irgendwie ausgeben lassen kann.